Controlling issue grouping in Sentry

When you use Sentry Show archive.org snapshot 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 Show archive.org snapshot is especially important when you try to silence certain errors.

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 Show archive.org snapshot was calculated.

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 Show archive.org snapshot .

Fingerprint rules have this syntax: 1 or more key:value conditions, followed by ->, followed by your custom fingerprint string. Read the docs Show archive.org snapshot for all details. Examples:

Copymessage:"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

Use * as a wildcard for n characters.

Overriding the fingerprint from within the application (with the raven gem)

You can also set a custom fingerprint from within the application:

CopyRaven.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

Copyclass MyError < StandardError
  def initialize(*)
    super
    Raven.annotate_exception(self, fingerprint: [self.class.name])
  end
end

Overriding the fingerprint from within the application (with the sentry-ruby gem)

You can also set a custom fingerprint from within the application:

Copyerror = MyError.new('Some message')
Sentry.capture_exception(error, fingerprint: [error.class.name])
raise(error)

See the SDK Fingerprinting docs Show archive.org snapshot for more generic approaches.

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.