Monitoring and Release tracking with Sentry

Before we deep dive into the topic let’s focus on why we need this tool and why we need this feature in our toolbox. In the world of errors and bugs, we will find many errors to debug and keep our system stable. So many applications need monitoring to analyze the performance of running application but what if:

• we are not getting 100% analysis
• only got the handled error exceptions
• our applications have some anonymous errors which weren’t tracked in our system status error code and that continuously increased the load or downtime, and many more.

Will you actually debug that kind of error? How difficult is it to identify what caused Application Crash? Some organizations have set custom status codes for similar or multiple look-alike error strings but what if they are actually not similar, and you would be like “ignore, that’s our handled one we are throwing that status code”.

Yes, I know you all are thinking that there are many monitoring tools that will tell you the exact problem but what if they don’t provide you with a stack trace? You will be confused, right. Many applications have the power of analysing the bugs in depth but you will have to put more and more effort into doing this.

No more mindlessly pasting errors on the internet. That’s why Sentry comes in a picture that is simple to use and the issues come directly from the code end.

Sentry Introduction

Sentry is an open-source, cross-platform error tracking tool that helps developers to monitor, and fix crashes in real-time. Its major features help in boosting efficiency and improve the user experience like tracking and detecting every possible exception from its SDK; whether it is handled by you or the code block. It has support for almost all programming languages.

It is extremely easy to set up as it gives SDK to integrate into your code and every exception that lies under that SDK will occur on the sentry.io dashboard. It’s vital as it helps in avoiding errors that our application might pass on silently. It detects and tells you in which backend file you have the issue. With that, it covers the overall details of every new exception, old exceptions, their occurrences, and many more. Also, you have the admin power to assign anyone on that issue to keep the records who will solve that. It does also help us in keeping our application stable and optimized.

Sentry is available as a self-hosted version or a paid, cloud-hosted option, which makes it really versatile for various types of businesses.

So, here is one of the features of the sentry which is very powerful and help organizations track their deployments on a daily, monthly, and yearly basis.

So, I’m talking about the release tracking feature in which you will find your:

So in release tracking, the release is a version of your code deployed to an environment in that time you have to notify Sentry about a release which helps the developer to identify new issues and regressions, determine whether an issue is resolved in the next release, and apply source maps or other mapping files. The Releases page provides a visualization of your releases. It presents the adoption of releases from the past 24 hours and provides a high-level view of:

Notifying Sentry of a release enables auto-discovery of which commits to associate with a release and identifies the most recent release when searching in sentry.io

Each release links to one or more projects. If a release has multiple projects, Sentry will duplicate the release data in relation to each one.

Also, releases offer significant additional features when fully configured:

We can determine the issues and regressions introduced in a new release which do the following,

• Predict which commit caused an issue and who is likely responsible
• Resolve issues by including the issue number in your commit message
• Receive email notifications when your code gets deployed

We recommend notifying Sentry about a new release before deploying it. But if you don’t, Sentry will automatically create a release entity in the system the first time it sees an event with that release identifier.

Apply Source Maps or Other Debug Files

Sentry supports demangling of transpiled, minified, and bundled JavaScript using source maps, which are JSON files that contain information about how to map your deployed code back to its original source so that you can view source code context obtained from stack traces in its original form. Releases are required to apply source maps or other debug files to follow the same. This is useful for debugging files that are processed, ie.. bundled, minified, transpiled, compiled, or otherwise obfuscated by tools like Webpack, Terser, or the C++ compiler — from a higher-level language.

Enable Suspect Commits

You can identify suspect commits in the release track, which helps you to detect or analyze which author’s commit caused an issue. Sentry uses commit metadata from your source code repositories to identify the suspect commits.

This all can be viewed under the Issue Details page to view suspect commits as well as the list of authors of those commits. We can also assign or alert the issue owner, based on your organization’s ownership rules.

Track Release Health

Release health shows and provides insights into the impact of crashes and errors as it relates to your user’s experience and changes trends with each new issue.

We can monitor release health by,

• observing user adoption
• usage of the application
• percentage of crashes
• session data.

You can also explore the health of a release more closely on the Release Details page.

Release Details

The Release Details page focuses on an individual release. Elements of the release are displayed, such as visualized trends for crashes and sessions, specifics regarding each issue, adoption graphs, and commit author breakdowns.

Also, you can find the no.of deploys of each release and see the issues related to that deploy id, which helps you identify which release has a major problem.

The graph at the top provides insights into the health of your release by allowing you to choose which metric it displays. The metrics that can be shown totally depend on the amount of data metric you want. Like in the above picture I’ve only enabled these metrics for release tracking.

But if all metrics are enabled then select the time range that you want to review and choose from these metrics in the table below the graph:

• Crash Free Session Rate
• Healthy, Abnormal, Errored session rate
• Crash Free User Rate
• Crashed Session Rate
• Crashed User Rate
• Failure Rate
• Session Duration p50
• Session Count
• Error Count
• Transaction Count

If you want to know which errors are from which production release name associated, you can easily find this

For release track setup in 4 simple steps please reach out to this
link: https://docs.sentry.io/product/releases/setup/

And for more information regarding this tool, you can access this
link: https://docs.sentry.io/product/releases/

Conclusion

The purpose of this blog was to dig a little deeper into monitoring concepts of this tool and its wonderful features which helps to enhance the application system. It’s not just the monitoring but the exceptions tracking tool. Here I’ve explained how we would get the exact cause of that bug in less time. In release tracking, it’s very helpful for both developers and DevOps to identify the exact cause of the incoming issues in new releases. They can find out from which files and commits it happened and who’s the main culprit of that bug in different releases. It is easy for developers to view every record of deployment release.

Next time we will meet with some new tool concepts.

Blog Pundits: Naveen Verma and Sandeep Rawat

Opstree is an End to End DevOps solution provider.

Connect with Us

• LinkedIn
• YouTube
• GitHub
• Facebook
• Medium