Updated: Controlling issue grouping in Sentry

Posted . Visible to the public. Auto-destruct in 9 days

Added that usage of * wildcards might be necessary in custom fingerprinting rules.

Changes

  • 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 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.
  • 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>.
  • 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:"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
  • ```
  • +Use `*` as a wildcard for n characters.
  • +
  • ## 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'])
  • ```
  • 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 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.
Dominik Schöler
License
Source code in this card is licensed under the MIT License.
Posted by Dominik Schöler to makandra dev (2024-09-16 05:54)