Filtering

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 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.

Filtering Error Events

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

Using beforeSend

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.

import io.sentry.android.core.SentryAndroid;

SentryAndroid.init(this, options -> {
  // Add a callback that will be used before the event is sent to Sentry.
  // With this callback, you can modify the event or, when returning null, also discard the event.
  options.setBeforeSend((event, hint) -> {
    String environment = event.getEnvironment();
    if (environment == null || environment.equals("TEST")) {
      return null;
    } else {
      return event;
    }
  });
});

Note also that breadcrumbs can be filtered, as discussed in our Breadcrumbs documentation.

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:

A BiFunction<SentryEvent, Object, SentryEvent> can be used to mutate, discard (return null), or return a completely new event.

import io.sentry.android.core.SentryAndroid;

SentryAndroid.init(this, options -> {
  options.setBeforeSend((event, hint) -> {
    if (hint instanceof MyHint) {
      return null;
    } else {
      return event;
    }
  });
});

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 exception instance. For better customization, SDKs send these objects to certain callbacks (beforeSend, beforeBreadcrumb or the event processor system in the SDK).

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 is implementation dependent. For XHR requests, the hint contains the xhr object itself; for user interactions the hint contains the DOM element and event name and so forth.

import io.sentry.android.core.SentryAndroid;
import android.database.sqlite.SQLiteException;
import java.util.Arrays;

SentryAndroid.init(this, options -> {
  options.setBeforeSend((event, hint) -> {
    if (event.getThrowable() instanceof SQLiteException) {
      event.setFingerprints(Arrays.asList("database-connection-error"));
    }
    return event;
  });
});

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

event

对于从浏览器事件创建的面包屑，Sentry SDK 通常会将事件作为提示提供给面包屑。这可以用于从目标 DOM 元素中提取数据到面包屑中，例如。

level / input

对于从控制台日志拦截创建的面包屑。这包含原始的控制台日志级别和传递给日志函数的原始输入数据。

response / input

对于从 HTTP 请求创建的面包屑。这包含响应对象（来自 fetch API）和传递给 fetch 函数的输入参数。

request / response / event

对于从 HTTP 请求创建的面包屑。这包含请求和响应对象（来自 Node.js HTTP API）以及 Node.js 事件（response 或 error）。

xhr

对于使用旧版 XMLHttpRequest API 创建的 HTTP 请求面包屑。这包含原始的 xhr 对象。

Decluttering Sentry

When used together with one of the logging framework integrations, the Android SDK captures all error logs as events. If you see a particular kind of error very often that has a logger tag, you can ignore that particular logger entirely. For more information see our Timber integration.

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

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:

import io.sentry.android.core.SentryAndroid;

SentryAndroid.init(this, options -> {
  options.setTracesSampler(context -> {
    if (/* make a decision based on `samplingContext` */) {
      // Drop this transaction, by setting its sample rate to 0%
      return 0.0;
    } else if (/* ... */) {
      // Override sample rate for other cases (replaces `options.TracesSampleRate`)
      return 0.1;
    }
    // Can return `null` to fallback to the rate configured by `options.tracesSampleRate`
    return null;
  });
});

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 to learn more.

Learn more about configuring the sample rate.

Using beforeSendTransaction

import io.sentry.android.core.SentryAndroid;

SentryAndroid.init(this, options -> {
  options.setBeforeSendTransaction((transaction, hint) -> {
    // Modify or drop the transaction here:
    if ("/unimportant/route".equals(transaction.getTransaction())) {
      // Don't send the transaction to Sentry
      return null;
    } else {
      return transaction;
    }
  });
});