SDK Fingerprinting

All events have a

fingerprintThe set of characteristics that define an event.
. Events with the same fingerprint are grouped together into an issue.

By default, Sentry will run one of our built-in grouping algorithms to generate a fingerprint based on information available within the event such as stacktrace, exception, and message. To extend the default grouping behavior or change it completely, you can use a combination of the following options:

  1. In your SDK, using SDK Fingerprinting, as documented below
  2. In your project, using Fingerprint Rules or Stack Trace Rules

In supported SDKs, you can override Sentry's default grouping that passes the fingerprint attribute as an array of strings. The length of a fingerprint's array is not restricted. This works similarly to the fingerprint rules functionality, which is always available and can achieve similar results.

Basic Example

In the most basic case, values are passed directly:

Copied
try {
    // Run code that possibly throws an exception
} catch (\Throwable $e) {
    \Sentry\withScope(function (\Sentry\State\Scope $scope) use ($e) {
        $scope->setFingerprint(['example-exception-group']);
        \Sentry\captureException($e);
    });
}

You can use variable substitution to fill dynamic values into the

fingerprintThe set of characteristics that define an event.
generally computed on the server. For instance, the value {{ default }} can be added to add the entire normally generated grouping hash into the fingerprint. These values are the same as for server-side fingerprinting. See Variables for more information.

Group Errors With Greater Granularity

Your application queries a Remote Procedure Call Model (RPC) interface or external Application Programming Interface (API) service, so the stack trace is generally the same (even if the outgoing request is very different).

The following example will split up the default group Sentry would create (represented by {{ default }}) further, taking some attributes on the error object into account:

Copied
class MyRpcException extends \Exception
{
    private string $functionName;
    private int    $statusCode;

    /**
     * For example the name of the RPC function that was called (e.g. "getAllBlogArticles").
     */
    public function getFunctionName(): string
    {
        return $this->functionName;
    }

    /**
     * For example a HTTP status code returned by the server.
     */
    public function getStatusCode(): int
    {
        return $this->statusCode;
    }
}

try {
    // Run code that for example throws a MyRpcException
} catch (MyRpcException $e) {
    \Sentry\withScope(function (\Sentry\State\Scope $scope) use ($e) {
        $scope->setFingerprint([
          '{{ default }}',
          $e->getFunctionName(),
          $e->getStatusCode(),
        ]);
        \Sentry\captureException($e);
    });
}

Group Errors More Aggressively

A generic error, such as a database connection error, has many different stack traces and never groups together.

The following example will completely overwrite Sentry's grouping by omitting {{ default }} from the array:

Copied
try {
    // Run code that for example throws a PDOException
} catch (\PDOException $e) {
    \Sentry\withScope(function (\Sentry\State\Scope $scope) use ($e) {
        $scope->setFingerprint(['database-connection-error']);
        \Sentry\captureException($e);
    });
}
Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").