---
title: "Filtering"
description: "Learn more about how to configure your SDK to filter events reported to Sentry."
url: https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering/
---

# Filtering | Sentry for Iris

When you add Sentry to your app, you get a lot of valuable information about errors and performance. And lots of information is good -- as long as it's the right information, at a reasonable volume.

The Sentry SDKs have several configuration options to help you filter out events.

We also offer [Inbound Filters](https://docs.sentry.io/concepts/data-management/filtering.md) to filter events in sentry.io. We recommend filtering at the client level though, because it removes the overhead of sending events you don't actually want. Learn more about the [fields available in an event](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/).

## [Filtering Error Events](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#filtering-error-events)

Configure your SDK to filter error events by using the `BeforeSend` callback method and configuring, enabling, or disabling integrations.

### [Using `BeforeSend`](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#using-before-send)

All Sentry SDKs support the `BeforeSend` callback method. Because it's called immediately before the event is sent to the server, this is your last chance to decide not to send data or to edit it. `BeforeSend` receives the event object as a parameter, which you can use to either modify the event’s data or drop it completely by returning `null`, based on custom logic and the data available on the event.

In Go, a function can be used to modify the event or return a completely new one. If you return `nil`, the SDK will discard the event.

```go
sentry.Init(sentry.ClientOptions{
	// ...
	BeforeSend: func(event *sentry.Event, hint *sentry.EventHint) *sentry.Event {
		// Modify the event here
		event.User.Email = "" // Don't send user's email address
		return event
	},
})
```

Note also that breadcrumbs can be filtered, as discussed in [our Breadcrumbs documentation](https://docs.sentry.io/product/error-monitoring/breadcrumbs.md).

#### [Event Hints](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#event-hints)

The `BeforeSend` callback is passed both the `event` and a second argument, `hint`, that holds one or more hints.

Typically, a `hint` holds the original exception so that additional data can be extracted or grouping is affected. In this example, the fingerprint is forced to a common value if an exception of a certain type has been caught:

```go
sentry.Init(sentry.ClientOptions{
	// ...
	BeforeSend: func(event *sentry.Event, hint *sentry.EventHint) *sentry.Event {
		if ex, ok := hint.OriginalException.(DatabaseConnectionError); ok {
			event.Fingerprint = []string{"database-connection-error"}
		}

		return event
	},
})
```

For information about which hints are available see [`EventHint` implementation](https://github.com/getsentry/sentry-go/blob/master/interfaces.go).

When the SDK creates an event or breadcrumb for transmission, that transmission is typically created from some sort of source object. For instance, an error event is typically created from a log record or error instance. For better customization, the SDK sends these objects to certain callbacks (`BeforeSend`, `BeforeBreadcrumb` and event processors).

### [Using Hints](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#using-hints)

Hints are available in two places:

1. `BeforeSend` / `BeforeBreadcrumb`
2. `eventProcessors`

Event and breadcrumb `hints` are objects containing various information used to put together an event or a breadcrumb. Typically `hints` hold the original exception so that additional data can be extracted or grouping can be affected.

For events, hints contain properties such as `event_id`, `originalException`, `syntheticException` (used internally to generate cleaner stack trace), and any other arbitrary `data` that you attach.

For breadcrumbs, the use of `hints` depends on the type of breadcrumb.

#### [Hints for Events](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#hints-for-events)

`originalException`

The original exception that caused the Sentry SDK to create the event. This is useful for changing how the Sentry SDK groups events or to extract additional information.

`syntheticException`

When a string or a non-error object is raised, Sentry creates a synthetic exception so you can get a basic stack trace. This exception is stored here for further data extraction.

#### [Hints for Breadcrumbs](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#hints-for-breadcrumbs)

`event`

For breadcrumbs created from browser events, the Sentry SDK often supplies the event to the breadcrumb as a hint. This can be used to extract data from the target DOM element into a breadcrumb, for example.

`level` / `input`

For breadcrumbs created from console log interceptions. This holds the original console log level and the original input data to the log function.

`response` / `input`

For breadcrumbs created from HTTP requests. This holds the response object (from the fetch API) and the input parameters to the fetch function.

`request` / `response` / `event`

For breadcrumbs created from HTTP requests. This holds the request and response object (from the node HTTP API) as well as the node event (`response` or `error`).

`xhr`

For breadcrumbs created from HTTP requests made using the legacy `XMLHttpRequest` API. This holds the original `xhr` object.

### [Using `IgnoreErrors`](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#using-ignore-errors)

You can use the `IgnoreErrors` option to filter out errors that match a certain pattern. This option receives a list of strings and regular expressions to match against the error message. When using strings, partial matches will be filtered out, so if you need to filter by exact match, use regex patterns instead.

```go
sentry.Init(sentry.ClientOptions{
	// ...
    IgnoreErrors: []string{"my-error", "error-*"},
})
```

## [Filtering Transaction Events](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#filtering-transaction-events)

To prevent certain transactions from being reported to Sentry, use the `TracesSampler` or `BeforeSendTransaction` configuration option, which allows you to provide a function to evaluate the current transaction and drop it if it's not one you want.

### [Using `TracesSampler`](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#using-traces-sampler)

**Note:** The `TracesSampler` and `TracesSampleRate` config options are mutually exclusive. If you define a `TracesSampler` to filter out certain transactions, you must also handle the case of non-filtered transactions by returning the rate at which you'd like them sampled.

In its simplest form, used just for filtering the transaction, it looks like this:

```go
sentry.Init(sentry.ClientOptions{
	// ...
	TracesSampler: sentry.TracesSampler(func(ctx sentry.SamplingContext) float64 {
		if condition {
			return 0.0
		}
		return 1.0
	}),
})
```

It also allows you to sample different transactions at different rates.

If the transaction currently being processed has a parent transaction (from an upstream service calling this service), the parent (upstream) sampling decision will always be included in the sampling context data, so that your `TracesSampler` can choose whether and when to inherit that decision. In most cases, inheritance is the right choice, to avoid breaking distributed traces. A broken trace will not include all your services. See [Inheriting the parent sampling decision](https://docs.sentry.io/platforms/go/guides/iris/configuration/sampling.md#inheritance) to learn more.

Learn more about [configuring the sample rate](https://docs.sentry.io/platforms/go/guides/iris/configuration/sampling.md).

### [Using `BeforeSendTransaction`](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#using-before-send-transaction)

The `BeforeSendTransaction` hook is a function that can be passed to `sentry.Init` via the corresponding configuration option. In this function you can either update the transaction event before it's sent to Sentry, or drop it by returning `nil`, for example:

```go
sentry.Init(sentry.ClientOptions{
	// ...
	BeforeSendTransaction: func(event *sentry.Event, hint *sentry.EventHint) *sentry.Event {
		if event.Message == "test-transaction" {
			// Don't send the transaction to Sentry
			return nil
		}
		// Update the message for every sent transaction
		event.Message += " [example]"
		return event
	},
})
```

### [Using `IgnoreTransactions`](https://docs.sentry.io/platforms/go/guides/iris/configuration/filtering.md#using-ignore-transactions)

You can use the `IgnoreTransactions` option to filter out transactions that match a certain pattern. This option receives a list of strings and regular expressions to match against the transaction name. When using strings, partial matches will be filtered out, so if you need to filter by exact match, use regex patterns instead.

```go
sentry.Init(sentry.ClientOptions{
	// ...
    IgnoreTransactions: []string{"/home", "/check-*"},
})
```