I, like many of you no doubt reading this, am an engineer with very strong opinions on how software should work. I am not interested in moving fast and breaking things; I am not interested in changing the world. I am interested in building pleasant, ergonomic software and charging money for it. My company, Buttondown, was born from that ethos.
A Sentaur who uses Sentry to build Sentry wanted to know where a specific service associated with an issue was being hosted in our cloud environment. This prompted us to create a new cloud data gathering feature for our Python SDK, which is available to everyone now, and not just Sentaurs.
At Sentry, we practice continuous delivery, which means that code can be released as soon as it’s merged into the main branch. This allows us to iterate quickly on our product, making new features, bug fixes, configuration changes, and experiments available in production as frequently as possible. We merge over 700 pull requests a month.
As an open source company that grew out of a side project in 2008 to an application and performance monitoring platform (APM) used by over 3.5 million developers, Sentry is committed to open source and the community of developers maintaining and building in the open. Similarly, we take a public approach to building our software, which is why it’s a natural extension of our values to announce our support for OpenTelemetry (or OTel), the leading open standard for observability.
Third-party JavaScript libraries provide developers with the tools they need to build modern web experiences, and a bit of cheatcode at times to not have to start from scratch. I mean, you don’t want to build an entire monitoring solution, so we help with Sentry’s Next.js SDK that only requires a couple of lines of code.
You know that annoying bug? The one that doesn’t show up locally? And no matter how many times you try to recreate the environment you can’t reproduce it? You’ve gone through the breadcrumbs, read through the stack trace, and are now playing detective to piece together support tickets to make sure it’s real. To get to the root cause faster - without rolling your head on your keyboard - we built Session Replay, now generally available for all web-based platforms.
A couple months ago, we launched Profiling in alpha for users on Python and Node.js SDKs — today, we’re moving Profiling for Python and Node.js to beta. Profiling is free to use while in beta — more updates to come when we near GA. Profiling is a critical tool for helping catch performance bottlenecks in your code. Sentry’s profiler gets you down to the exact file/line number in your code that is causing a slow-running query.
The performance of your app matters. From ensuring a good user experience to retaining users, performance makes a difference in your app’s success. Using the right tools can make it easier to ensure your code is meeting your performance goals, before you have to switch to a bigger EC2 instance or users start complaining. One of the best tools in a developer’s toolbox for ensuring good performance is profiling.
This is part 2 of a 3-part series on profiling. If you’re not yet familiar with the what profiling is, check out the first part in our series. By this point, you’re probably already convinced that good performance is important for your app’s success. There are many tools available for performance, but profiling in production with a modern profiling tool is one of the easiest and most effective ways to get a full understanding of your app’s performance.
Stack traces show us exactly where an exception occurred, but you can still be left wondering: What arguments or state caused the exception to occur? If you can reproduce the issue locally with a debugger attached you’ll have access to these local variables, but with Sentry you can identify the exception location without needing to reproduce the issue locally. By including local variables with stack traces, Sentry events become much closer to the full debugging experience.
