Updated: Controlling issue grouping in Sentry

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:"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
+## Overriding the fingerprint from within the application (with the raven gem)
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
```
+## Overriding the fingerprint from within the application (with the sentry-ruby gem)
+
+You can also set a custom fingerprint from within the application: 
+
+```ruby
+error = MyError.new('Some message')
+Sentry.capture_exception(error, fingerprint: [error.class.name])
+raise(error)
+```
+
+See the [SDK Fingerprinting docs](https://docs.sentry.io/platforms/ruby/guides/rack/usage/sdk-fingerprinting/#group-errors-with-greater-granularity) 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.