# SDK Fingerprinting | Sentry for Elixir

All events have a fingerprint. 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](https://docs.sentry.io/concepts/data-management/event-grouping/fingerprint-rules.md) or [Stack Trace Rules](https://docs.sentry.io/concepts/data-management/event-grouping/stack-trace-rules.md)

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](https://docs.sentry.io/concepts/data-management/event-grouping/fingerprint-rules.md), which is always available and can achieve similar results.

## [Basic Example](https://docs.sentry.io/.md#basic-example)

In the most basic case, values are passed directly:

```elixir
try do
  # Some code...
rescue
  exception ->
    fingerprint = [inspect(__MODULE__), inspect(__ENV__.function)]
    Sentry.capture_exception(exception, stacktrace: __STACKTRACE__, fingerprint: fingerprint)
end
```

You can use variable substitution to fill dynamic values into the fingerprint 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](https://docs.sentry.io/concepts/data-management/event-grouping/fingerprint-rules.md#variables) for more information.

## [Group Errors With Greater Granularity](https://docs.sentry.io/.md#group-errors-with-greater-granularity)

In some scenarios, you'll want to group errors more granularly.

For example, if your application queries a Remote Procedure Call Model (RPC) interface or external Application Programming Interface (API) service, 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:

```elixir
# A custom exception that represents an error in a RPC.
defmodule RPCError do
  defexception [:code, :function_name]
end

defmodule SentryHook do
  def before_send(event) do
    case event.original_exception do
      %RPCError{code: code, function_name: function_name} ->
        put_in(event.fingerprint, ["{{ default }}", code, function_name])

      _other ->
        event
    end
  end
end

config :sentry,
  before_send: {SentryHook, :before_send}
```

## [Group Errors More Aggressively](https://docs.sentry.io/.md#group-errors-more-aggressively)

You can also overwrite Sentry's grouping entirely.

For example, if a generic error, such as a database connection error, has many different stack traces and never groups them together, you can overwrite Sentry's grouping by omitting `{{ default }}` from the array:

```elixir
defmodule SentryHook do
  def before_send(event) do
    case event.original_exception do
      %DBConnection.ConnectionError{} ->
        put_in(event.fingerprint, ["database_connection_error"])

      _other ->
        event
    end
  end
end

config :sentry,
  before_send: {SentryHook, :before_send}
```
