Sentry
By Nick Belzer, Martijn Comans, Philippe Lammerts and Daan Oudejans
A simple error can cause a lot of headaches, chaos and even financial loss. Sentry helps mitigating these problems by enabling developers to quickly triage, analyze and resolve errors and bugs. Sentry works for nearly every stack, and has a lot of useful features like distributed tracing across different stacks, extensive context descriptions and breadcrumbs. Every day Sentry processes billions of exceptions for more than 50,000 customers, including companies like Microsoft, Uber, Airbnb and PayPal. Thanks to Sentry, developers can create better and more reliable software.
This chapter gives an overview of the work that we have done towards analyzing the software architecture of Sentry. First, we will describe Sentry in a broader context. Then, a deeper analysis will be discussed, which takes a look at Sentry’s implementation and underlying architecture.
Contributions
Putting Sentry into Context
Imagine you created a nice application for other people to use. Your product is gaining traction, new users start flowing in and you start earning some money. Life is great and you decide to roll out a big update you have been working on. But after a few days of the release, engagement rates and sales seem to drop and you are not sure why: all of your automated tests pass and you have extensively tried your app on your machine. A little panicked, you start investigating. You are still very lost when an email comes in: a kind user took the effort to submit a bug report! The bug report is very vague, but at least you have a sense of what is happening. You finally find the culprit after another day of work: three lines of code in the backend that caused unexpected behavior in the frontend. Almost a week later, you fixed the issue and users are slowly returning to your app.
The Architecture Powering Sentry
In the last essay we gave an overview of Sentry and its context. We discussed topics like Sentry’s key capabilities, stakeholders and relationships with its environment. But that essay also serves as a stepping stone to the topic of this essay: the architecture behind Sentry. Architecture of software can be viewed from multiple perspectives, as has for example been described by Rozanski and Woods. Guess what? The last essay already covered two architectural viewpoints, namely the contextual and functional viewpoints! In this essay, we will take a Snuba dive into some more technical architectural viewpoints: development, deployment and runtime.
Monitoring Sentry’s Software Quality
Thousands of customers use Sentry for creating better software, but how is the software quality of Sentry itself? In this essay, we will analyze how the quality of Sentry’s underlying code and architecture is safeguarded. The architecture powering Sentry has already been discussed in the last essay (“The Architecture Powering Sentry”), so we recommend you to read that first. Having an understanding of Sentry’s core software architecture, we can take a look at the architecture from yet another perspective by addressing topics like software quality assessment, code quality, and technical debt. This perspective is inspired by the Quality Scenarios and Risks & Technical Debt aspects from the arc42 framework.
Supporting Every Language: Sentry’s SDKs
No programming language is the same. Different syntaxes, static/dynamic typing, and varying build processes are just a few examples of differences that make it difficult to write a single piece of code that can report errors back to Sentry for all runtimes. Previously we have introduced Sentry, discussed it’s architecture, and its development process. Now we broaden our scope to the ecosystem of SDKs supported by Sentry. We will show how Sentry is able to support many different runtimes and we will take a look at these SDKs that report back to Sentry to see how they work.