- Updated card title
- Added a section about controlling issue grouping in the Sentry UI (i.e. without modifying the application)
Changes
-When you use [Sentry](https://sentry.io/) to monitor exceptions, an important feature is Sentry's error grouping mechanism. This will aggregate similar error "events" into one issue, so you can track and monitor it more easily. [Grouping](https://develop.sentry.dev/grouping/) is especially important [when you try to silence certain errors](/makandra/481969).- +When you use [Sentry](https://sentry.io/) to monitor exceptions, an important feature is Sentry's error grouping mechanism. It will aggregate similar error "events" into one issue, so you can track and monitor it more easily. [Grouping](https://develop.sentry.dev/grouping/) is especially important [when you try to silence certain errors](/makandra/481969).
- It is worth understanding how Sentry's grouping mechanism works.
-# The default grouping mechanism- +
- +## The default grouping mechanism
- The exact algorithm has changed over time, and Sentry will keep using the algorithm that was active when you created the project. You can upgrade the grouping strategy in the projects general settings.
- For exceptions, Sentry will by default group by backtrace and exception class. For the backtrace, Sentry looks at the *code* of all lines in an exceptions backtrace, and computes a "fingerprint" from that code.
- At the bottom of each sentry issue, you can see exactly how the [fingerprint](https://docs.sentry.io/product/data-management-settings/event-grouping/fingerprint-rules/) was calculated.
- ![Image](/makandra/484983/attachments/26240)
- As you can see, the actual code ("context-line") of each line of the backtrace was considered, but not, for example, its line number.
-# Overriding the fingerprint- +Sometimes the default grouping does not work well. For example, if your application talks to an external API that is known to occasionally time out, it makes sense to group all those timeout errors together, regardless of which code path was used to trigger them. Read on to find how to customize this.
- +
- +
- +## Modifying issue grouping in Sentry's project settings
- +
- +Sentry offers a UI to define custom fingerprint and stack trace rules at <https://sentry.io/settings/projects/$project-id/issue-grouping>.
-Sometimes this grouping is not very helpful. For example, if your application talks to an external API that is known to occasionally time out, it makes sense to group all those timeout errors together, regardless of which code path was used to trigger them.- +Fingerprint rules have this syntax: 1 or more `key:value` conditions, followed by `->`, followed by your custom fingerprint string. [Read the docs](https://docs.sentry.io/concepts/data-management/event-grouping/fingerprint-rules/) for all details. Examples:
- +```
- +message:"PG::ConnectionBad: " -> database-unavailable
- +error.type:"ActiveRecord::ConnectionNotEstablished" -> database-unavailable
- +error.type:"ActionView::Template::Error" message:"unexpected token at" -> hack-unexpected-token
- +error.type:"ArgumentError" message:"invalid byte sequence in UTF-8" -> invalid-byte-sequence
- +error.type:"RedisClient::CannotConnectError" -> redis-cannot-connect
- +```
-In this case, you can use- +## Overriding the fingerprint from within the application
- +
- +You can also set a custom fingerprint from within the application:
- ```ruby
- Raven.annotate_exception(exception, fingerprint: ['data used for grouping', 'more data used for grouping'])
- ```
-to override the automatic grouping. Now all exceptions with that same fingerprint will be grouped, regardless of their backtraces.- +All issues with this fingerprint will be merged, regardless of their backtraces.
- For example, to always group all exceptions of a specific type together, you could use
- ```ruby
- class MyError < StandardError
- def initialize(*)
- super
- Raven.annotate_exception(self, fingerprint: [self.class.name])
- end
- end
- ```
-# Merging errors- +
- +## Merging errors manually
- Another approach is to tell Sentry to merge events with different fingerprints into one issue. To do this, simply select issues you want to group, and press the "Merge" button above the issue list. From then on, all errors with any of the merged fingerprints will appear under the same issue.
- You can have a look at the "merge" tab of an issue to see which different fingerprints are grouped under that issue. There is also "experimental" support for unmerging later.
Posted by Dominik Schöler to makandra dev (2024-09-10 09:05)