From 1bc844d18207a25ade48e41ef7ea0e836a1a74ff Mon Sep 17 00:00:00 2001 From: Katie Byers Date: Tue, 24 Jun 2025 16:12:05 -0700 Subject: [PATCH 1/4] remove stray "also" --- .../data-management/event-grouping/fingerprint-rules.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx b/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx index 0f94859da5b57..10a04296d4372 100644 --- a/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx +++ b/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx @@ -6,7 +6,7 @@ description: "Learn about fingerprint rules, matchers for fingerprinting, how to -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: From 6c163e30c6c62a47a3ea61796a44876d17a6fc9e Mon Sep 17 00:00:00 2001 From: Katie Byers Date: Tue, 24 Jun 2025 16:14:31 -0700 Subject: [PATCH 2/4] update link to grammar --- .../data-management/event-grouping/fingerprint-rules.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx b/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx index 10a04296d4372..98fba8b75f452 100644 --- a/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx +++ b/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx @@ -13,7 +13,7 @@ These rules can be configured on a per-project basis in **[Project] > Settings > 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. From 011875a2a3be6acc10ed212e2d44433c71eb88a8 Mon Sep 17 00:00:00 2001 From: Katie Byers Date: Tue, 24 Jun 2025 16:15:06 -0700 Subject: [PATCH 3/4] add sentence for utility matchers --- .../data-management/event-grouping/fingerprint-rules.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx b/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx index 98fba8b75f452..a487963d62fbc 100644 --- a/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx +++ b/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx @@ -148,6 +148,8 @@ Used to "scope" down the matcher. The following families exist: `javascript` for family:native !stack.module:"myproject::*" -> not-from-my-project ``` +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`: From becc164c9238f2ff6a1730371dc58bc086dd6754 Mon Sep 17 00:00:00 2001 From: Katie Byers Date: Tue, 24 Jun 2025 16:15:43 -0700 Subject: [PATCH 4/4] alphabetize variables --- .../event-grouping/fingerprint-rules.mdx | 116 +++++++++--------- 1 file changed, 58 insertions(+), 58 deletions(-) diff --git a/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx b/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx index a487963d62fbc..951651103f128 100644 --- a/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx +++ b/docs/concepts/data-management/event-grouping/fingerprint-rules.mdx @@ -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` @@ -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` @@ -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` @@ -140,12 +132,12 @@ 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: @@ -158,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 +``` + ## Combining Matchers @@ -188,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 }}` @@ -216,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 }}` @@ -244,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 }}` @@ -264,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. @@ -288,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 }} ```