Automate, Group, and Get Alerted: A Best Practices Guide to Monitoring your Code - Part 1
*Missed part two? Check out the full guide here
As companies grow, so do their products, teams, and the number of external tools. For engineers, that can mean code sprawl, data silos, notification fatigue, and some “what the…?” moments along the way as they try to make sense of it all.
To help combat the chaos, Sentry provides several ways to manage the volume, noise, and potential team disconnects that come with launching and scaling projects so you can see the issues that actually matter and solve them faster – without the expletives.
Automatically provision and deprovision users and teams directly in SAML2 identity providers like Okta and Azure AD using SCIM. Whether employees change roles, leave the company, or teams experience structural changes, you can programmatically add or remove team members, update team attributes such as name, or replace an entire member set - without leaving your identity provider.
Events in Sentry tend to grow proportional to the organization – with more customers, more products, and more lines of code you’re likely to also see more events.
To help manage events, Sentry’s grouping strategy provides a built-in grouping algorithm to join related errors into a single issue, so you don’t receive a deluge of issue notifications.
Grouping works because all events have a fingerprint. Events with the same fingerprint are grouped based on information available within the event, such as stacktrace, exception, and message. Effective issue management sometimes involves looking across the constellation of these events to fine-tune the signal from the noise with custom grouping.
When customizing fingerprinting rules, it can be helpful to use Discover to explore the projects that create the most Sentry issues relative to absolute error volume. Teams can then combine patterns from event data alongside intimate knowledge of their codebase to inform custom fingerprinting or stack trace rules. These rules are all configured on a per-project basis.
Once you have grouped events, you can also filter events with custom filter rules using a similar approach above. You can apply filter rules at both the SDK level and via inbound filters within Sentry.
To help you see the issues you care most about, Review List provides a centralized view of a sub-set of all your unresolved issues. By default, Review List filters to display issues assigned to you or suggested for you. This view offers a more manageable collection of events that team members can review and triage daily.
Understanding your events can also inform sampling decisions. For example, if a project has many unique issues, using rate limiting to control quota could bias your data toward noisier events, whereas sampling at the SDK level may provide a more representative sample of your errors. Our user guide is also a good starting point for exploring available options for sampling events across your Sentry projects.
Whether a Developer, Team Lead, or Product Owner, Sentry is continually working to help optimize your team’s workflow so you can reduce time spent on troubleshooting issues and focus on more important things like building products that customers want.