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

This is a small cleanup of the fingerprinting rules docs, pulled out of an upcoming PR in order to make it easier to review.

- Update GH link to fingerprinting grammar.
- Alphabetize non-utility fingerprinting variables.
- Add introductory sentence identifying utility matchers.

Author: lobsterkatie

docs/concepts/data-management/event-grouping/fingerprint-rules.mdx

@@ -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.
 
@@ -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,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`:
@@ -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
@@ -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 }}`
@@ -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 }}`
@@ -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 }}`
@@ -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.
@@ -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>