Filtering and Sampling Events
Adding Sentry to your app gives you a great deal of very valuable information about errors and performance you wouldn't otherwise get. 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 control this, allowing you to both filter out events you don't want and to take a representative sample of those you do.
Note:: The Sentry UI also offers methods to filter events, by using Inbound Filters. We recommend filtering at the client level though, because it removes the overhead of sending events you don't actually want.
Configure your SDK to filter error events by using the
beforeSend callback method and configuring, enabling, or disabling integrations.
All Sentry SDKs support the
beforeSend callback method.
beforeSend is called immediately before the event is sent to the server, so it’s the final place where you can edit its data. It receives the event object as a parameter, so you can use that to modify the event’s data or drop it completely (by returning
null) based on custom logic and the data available on the event.
Sentry.init do |config| config.before_send = lambda do |event, hint| event[:key] = value event end end
Note also that breadcrumbs can be filtered, as discussed in our Breadcrumbs documentation.
before-send callback is passed both the
event and a second argument,
hint, that holds one or more hints.
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:
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 (
beforeBreadcrumb or the event processor system in the SDK).
Hints are available in two places:
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, such as
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.
In this example, the fingerprint is forced to a common value if an exception of a certain type has been caught:
- 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.
- 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.
- For breadcrumbs created from browser events, the Sentry SDK often supplies the event to the breadcrumb as a hint. This, for instance, can be used to extract data from the target DOM element into a breadcrumb.
- For breadcrumbs created from console log interceptions. This holds the original console log level and the original input data to the log function.
- For breadcrumbs created from HTTP requests. This holds the response object (from the fetch API) and the input parameters to the fetch function.
- For breadcrumbs created from HTTP requests. This holds the request and response object (from the node HTTP API) as well as the node event (
- For breadcrumbs created from HTTP requests done via the legacy
XMLHttpRequestAPI. This holds the original xhr object.
To send a representative sample of your errors to Sentry, set the
sample_rate option in your SDK configuration to a number between
0 (0% of errors sent) and
1 (100% of errors sent). This is a static rate, which will apply equally to all errors. For example, to sample 25% of your errors:
Note: The error sample rate is not dynamic; changing it requires re-deployment. In addition, setting an SDK sample rate limits visibility into the source of events. Setting a rate limit for your project (which only drops events when volume is high) may better suit your needs.