Read more

How does Sentry group exceptions?

Tobias Kraze
September 01, 2020Software engineer at makandra GmbH

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

Illustration online protection

Rails Long Term Support

Rails LTS provides security patches for old versions of Ruby on Rails (2.3, 3.2, 4.2 and 5.2)

  • Prevents you from data breaches and liability risks
  • Upgrade at your own pace
  • Works with modern Rubies
Read more Show archive.org snapshot

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.

Image

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

In this case, you can use

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.

For example, to always group all exceptions of a specific type together, you could use

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

Merging errors

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 Tobias Kraze to makandra dev (2020-09-01 12:18)