Skip to content

ref(grouping): Small tweaks to fingerprint rules doc #14176

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 1, 2025
Merged

ref(grouping): Small tweaks to fingerprint rules doc #14176

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1bc844d
remove stray "also"
lobsterkatie Jun 24, 2025
6c163e3
update link to grammar
lobsterkatie Jun 24, 2025
011875a
add sentence for utility matchers
lobsterkatie Jun 24, 2025
becc164
alphabetize variables
lobsterkatie Jun 24, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
122 changes: 62 additions & 60 deletions docs/concepts/data-management/event-grouping/fingerprint-rules.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,14 +6,14 @@ description: "Learn about fingerprint rules, matchers for fingerprinting, how to

<Include name="only-error-issues-note.mdx" />

Fingerprint rules (previously known as _server-side fingerprinting_) are also configured with a config similar to [stack trace rules](../stack-trace-rules/), but the syntax is slightly different. The matchers are the same, but instead of flipping flags, a fingerprint is assigned and it overrides the default grouping entirely. Assigning a fingerprint can also refine the default grouping rather than overriding it, if the fingerprint includes the value `{{ default }}`.
Fingerprint rules (previously known as _server-side fingerprinting_) are configured with a config similar to [stack trace rules](../stack-trace-rules/), but the syntax is slightly different. The matchers are the same, but instead of flipping flags, a fingerprint is assigned and it overrides the default grouping entirely. Assigning a fingerprint can also refine the default grouping rather than overriding it, if the fingerprint includes the value `{{ default }}`.

These rules can be configured on a per-project basis in **[Project] > Settings > Issue Grouping > Fingerprint Rules**. This setting has input fields where you can write custom fingerprinting rules. To update a rule:

1. Identify the match logic for grouping issues together.
1. Set the match logic and the fingerprint for it.

The syntax for fingerprint rules is similar to syntax in [**Discover** queries](/concepts/search/#syntax). To negate a match, add an exclamation mark (`!`) at the beginning of the expression. See the full grammar [here](https://github.com/getsentry/sentry/blob/c5b84a393365a833348dd7fd9378d34c353ca6ca/src/sentry/grouping/fingerprinting.py#L17-L55).
The syntax for fingerprint rules is similar to syntax in [**Discover** queries](/concepts/search/#syntax). To negate a match, add an exclamation mark (`!`) at the beginning of the expression. See the full grammar [here](https://github.com/getsentry/sentry/blob/90f5cdfa9ebaf0bfdea63852812a6efc90f13691/src/sentry/grouping/fingerprinting/__init__.py#L36-L73).

Sentry attempts to match against all values that are configured in the fingerprint. In the case of stack traces, all frames are considered. If the event data matches all the values in a line for a matcher and expression, then the fingerprint is applied. When there are multiple rules that match the event, the first matching rule in the list is applied.

Expand Down Expand Up @@ -67,12 +67,12 @@ error.value:"connection error (code: *)" -> connection-error
error.value:"could not connect (*)" -> connection-error
```

### `message`
### `level`

Matches on a log message. It will also automatically check for the additional exception value as they can be hard to keep apart. The matching is case insensitive.
Matches on the log level. The match is case insensitive.

```bash {tabTitle:Fingerprinting Config}
message:"system encountered a fatal problem: *" -> fatal-log
logger:"com.myapp.FooLogger" level:"error" -> mylogger-error
```

### `logger`
Expand All @@ -83,20 +83,12 @@ Matches on the name of the logger, which is useful to combine all messages of a
logger:"com.myapp.mypackage.*" -> mypackage-logger
```

### `level`

Matches on the log level. The match is case insensitive.

```bash {tabTitle:Fingerprinting Config}
logger:"com.myapp.FooLogger" level:"error" -> mylogger-error
```

### `tags.tag_name`
### `message`

Matches on the value of the tag `tag_name`. This can be useful to filter down certain types of events. For instance, you can separate events caused by a specific server:
Matches on a log message. It will also automatically check for the additional exception value as they can be hard to keep apart. The matching is case insensitive.

```bash {tabTitle:Fingerprinting Config}
tags.server_name:"canary-*.mycompany.internal" -> canary-events
message:"system encountered a fatal problem: *" -> fatal-log
```

### `stack.abs_path`
Expand All @@ -109,24 +101,24 @@ Matches on the path of an event and is case insensitive. It uses path globbing s
stack.abs_path:"**/my-utils/*.js" -> my-utils, {{ error.type }}
```

### `stack.module`
### `stack.function`

alias: `module`
alias: `function`

Similar to `stack.abs_path` but matches on the module name instead. The match is case-sensitive and regular globbing rules apply (`*` also matches slashes).
Checks if any of the functions in the stack trace match the glob. The match is case-sensitive:

```bash {tabTitle:Fingerprinting Config}
stack.module:"*/my-utils/*" -> my-utils, {{ error.type }}
stack.function:"my_assertion_failed" -> my-assertion-failed
```

### `stack.function`
### `stack.module`

alias: `function`
alias: `module`

Checks if any of the functions in the stack trace match the glob. The match is case-sensitive:
Similar to `stack.abs_path` but matches on the module name instead. The match is case-sensitive and regular globbing rules apply (`*` also matches slashes).

```bash {tabTitle:Fingerprinting Config}
stack.function:"my_assertion_failed" -> my-assertion-failed
stack.module:"*/my-utils/*" -> my-utils, {{ error.type }}
```

### `stack.package`
Expand All @@ -140,14 +132,16 @@ stack.package:"**/libcurl.dylib" -> libcurl
stack.package:"**/libcurl.so" -> libcurl
```

### `family`
### `tags.tag_name`

Used to "scope" down the matcher. The following families exist: `javascript` for any type of JavaScript event, `native` for any type of Native event. Any other platform is called `other`.
Matches on the value of the tag `tag_name`. This can be useful to filter down certain types of events. For instance, you can separate events caused by a specific server:

```bash {tabTitle:Fingerprinting Config}
family:native !stack.module:"myproject::*" -> not-from-my-project
tags.server_name:"canary-*.mycompany.internal" -> canary-events
```

Additionally, the folowing utility matchers are available:

### `app`

Checks if the frame is in-app or not. It is particularly useful when combined with another matcher. Possible values are `yes` and `no`:
Expand All @@ -156,6 +150,14 @@ Checks if the frame is in-app or not. It is particularly useful when combined wi
app:yes stack.function:"assert" -> assert
```

### `family`

Used to "scope" down the matcher. The following families exist: `javascript` for any type of JavaScript event, `native` for any type of Native event. Any other platform is called `other`.

```bash {tabTitle:Fingerprinting Config}
family:native !stack.module:"myproject::*" -> not-from-my-project
```

</DefinitionList>

## Combining Matchers
Expand Down Expand Up @@ -186,14 +188,6 @@ This fills in the default fingerprint that would be produced by the normal group
stack.function:"query_database" -> {{ default }}, {{ transaction }}
```

### `{{ transaction }}`

This fills in the name of the transaction into the fingerprint. It will force the creation of a group per transaction:

```bash {tabTitle:Fingerprinting Config}
error.type:"ApiError" -> api-error, {{ transaction }}
```

### `{{ error.type }}`

alias: `{{ type }}`
Expand All @@ -214,14 +208,30 @@ This fills in the stringified value of the error that occurred. When chained exc
error.type:"ScriptError" -> script-evaluation, {{ error.value }}
```

### `{{ stack.function }}`
### `{{ level }}`

alias: `{{ function }}`
This fills in the name of the log level that was used to create an event.

This fills in the function name of the "crashing frame," also known as the application code's topmost frame.
```bash {tabTitle:Fingerprinting Config}
message:"connection error*" -> connection-error, {{ logger }}, {{ level }}
```

### `{{ logger }}`

This fills in the name of the logger that caused an event.

```bash {tabTitle:Fingerprinting Config}
error.type:"ScriptError" -> script-evaluation, {{ stack.function }}
message:"critical connection error*" -> connection-error, {{ logger }}
```

### `{{ message }}`

This fills in the message of the event (similar to `error.value` but for
captured messages). Note that this can produce groups with poor data quality if
messages are changing frequently:

```bash {tabTitle:Fingerprinting Config}
logger:"com.foo.auditlogger.*" -> audit-log, {{ message }}
```

### `{{ stack.abs_path }}`
Expand All @@ -242,6 +252,16 @@ This is like `stack.abs_path` but will only fill in the relative file name:
error.type:"ScriptError" -> script-evaluation, {{ stack.filename }}
```

### `{{ stack.function }}`

alias: `{{ function }}`

This fills in the function name of the "crashing frame," also known as the application code's topmost frame.

```bash {tabTitle:Fingerprinting Config}
error.type:"ScriptError" -> script-evaluation, {{ stack.function }}
```

### `{{ stack.module }}`

alias: `{{ module }}`
Expand All @@ -262,22 +282,6 @@ This fills in the package name (object file) of the "crashing frame," also known
stack.function:"assert" -> assertion, {{ stack.package }}
```

### `{{ logger }}`

This fills in the name of the logger that caused an event.

```bash {tabTitle:Fingerprinting Config}
message:"critical connection error*" -> connection-error, {{ logger }}
```

### `{{ level }}`

This fills in the name of the log level that was used to create an event.

```bash {tabTitle:Fingerprinting Config}
message:"connection error*" -> connection-error, {{ logger }}, {{ level }}
```

### `{{ tags.tag_name }}`

This fills in the value of a tag into the fingerprint, which can, for instance, be used to split events by server name or something similar.
Expand All @@ -286,14 +290,12 @@ This fills in the value of a tag into the fingerprint, which can, for instance,
message:"connection error*" -> connection-error, {{ tags.server_name }}
```

### `{{ message }}`
### `{{ transaction }}`

This fills in the message of the event (similar to `error.value` but for
captured messages). Note that this can produce groups with poor data quality if
messages are changing frequently:
This fills in the name of the transaction into the fingerprint. It will force the creation of a group per transaction:

```bash {tabTitle:Fingerprinting Config}
logger:"com.foo.auditlogger.*" -> audit-log, {{ message }}
error.type:"ApiError" -> api-error, {{ transaction }}
```

</DefinitionList>
Expand Down