Sentry Product Overview#
Sentry is a platform for monitoring and tracking errors in software applications. By default, it handles and reports any uncaught errors (those not encapsulated in a try/catch block), while also allowing collecting the handled errors. Capturing the errors is just the first step: Sentry also does most of the dirty work in classifying, grouping, and visualizing errors to make them legible and easy to take action on.
Let’s break down some of the core Sentry concepts before getting into the nitty gritty.
Sentry SDK#
In order for Sentry to report errors, it needs access to the application runtime (that is, the environment where the code is actually running) . They provide a suite of SDKs for more popular web languages, which developers can simply wrap around their code. Each Sentry project also comes with a Data Source Name (DSN, basically an ID to associate a codebase with a project).
Here’s a sample React configuration:
Essentially, this is just some boilerplate code to get the project up and running, and allow the ability to point Sentry at any web pages you want to start tracking.
Issues#
The issues page displays information about the errors and performance problems in your application. Most of the developers’ time will likely be spent here, triaging events and inspecting error details for diagnosis.
Sample Issues Page
While applications can emit a large volume of events, Sentry groups them based on __fingerprints, __or __set of characteristics that define an event. __This allows for easy filtering of events based on properties like browser, device, and the impacted users.
Before we inspect a sample issue, a quick primer on the top-level classifications of Sentry issues:
Error Issues:
Error issues refer to events where your application code encounters uncaught exceptions or unhandled rejections. This would include issues like Javascript exceptions, network errors, and application crashes.
Performance Issues
Performance issues relate to problems with performance and responsiveness of an application. Sentry allows teams to set up performance monitoring to track metrics like latency and throughput for common transactions (say, a common call to an API). When performance slows for a specific transaction, Sentry can help gain insight into the source and impact.
From the docs:
Sentry detects performance issues by scanning incoming transaction events. First we check various properties of the transaction (span durations, span arrangement, span types, and so on) to detect likely problems.
Issue Details: the Main Entree#
Making issues more accessible is Sentry’s bread and butter. Developers will likely spend most of their time in this area, triaging events to understand areas of concern.
Sample Issue Details Page
Sentry collects detailed information on errors and exceptions, making the issue details page a bit overwhelming! Let’s break down the individual sections:
In the world of software errors, the term stack trace will come up frequently. A stack trace is like when you lose something, and someone says "well where's the last place you saw it?" – you're essentially working your way back through all of the different things your code did, trying to find what went wrong. The trail includes names of functions that were executed, what order they were in, and the file names and line numbers where the functions are defined. Stack traces are indispensable tools for developers, as they help pinpoint the exact location and sequence of operations that led to an error, making debugging and diagnosing issues much more efficient. There’s a great example of the layers of a stack trace here.
- Suspect Commits: __Stack traces include references to functions defined in the code, and Sentry will show the most recent commit (or change submission to the codebase). This will include files observed in the stack trace, files included in the stack trace, and authors of those commits.
- Tags: Key/Value pairs with metadata on the event, like browser and device type, environment, and user id. Developers can also customize their own tags.
- Screenshot (only certain SDKs): For certain applications with a frontend, screenshots at the time of exception can be attached
- Exception (Stack Trace): Line of code that event errored on.
- Breadcrumbs: Trail of events that occured leading to an exception.
- Trace Details: Additional details on the issue, like user information + app/device context
Additional Features#
Issues and Projects only make up two of the many sidebar tabs on the Sentry dashboard. Sentry does a lot more than aggregate and expose issues. They’ve continued to expand the platform to fully diagnose an application, including performance monitoring,
The performance tab runs the performance monitoring described above: In this case, it creates a waterfall to break down each of the steps in
Profiling takes performance one step further by providing specific details on the execution (running) of a program. It allows developers to ‘zoom in’ on specific actions within an app and get a better understanding of individual transactions - this may include a specific page load, API call, or navigation to a specified page. It can drill down into the exact code that was executed during those transactions, allowing for closer inspection of the potential problem.
Session replays show a video-like reproduction of the user sessions to inspect what happened before, during, and after an error occurred. While not an exact video recording, it mimics the behavior based on events taken on the DOM (basically, a structured map of the web page)
Monitoring of the uptime and performance of any scheduled, recurring job in Sentry.
Alerts provide visibility into problems with code and impact on users. Sentry allows for custom alerting rules, which will be triggered when conditions are met.
The best way to get familiar with a product is to plat with it yourself. Fortunately, Sentry provides a complete Sandbox project, full of sample issues, projects and a showcase of other features in action.
How Important is this, Really?#
Well, by value, just north of $3 Billion.
Why? Software errors are costly. Users have come to expect speed and reliability, so even the slightest of delays or menial of errors can induct lasting downstream effects on the businesses (at the scale of $90 million in lost revenues for a corporation like Facebook). In a world where ‘everything is software driven’, the needs for application related developer tooling are not going anywhere.
