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.
Configure your SDK to filter error events by using the before_send
callback method and configuring, enabling, or disabling integrations.
All Sentry SDKs support the before_send
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. before_send
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.
Sentry.init do |config|
# ...
config.before_send = lambda do |event, hint|
# skip ZeroDivisionError exceptions
# note: hint[:exception] would be a String if you use async callback
if hint[:exception].is_a?(ZeroDivisionError)
nil
else
event
end
end
end
Note also that breadcrumbs can be filtered, as discussed in our Breadcrumbs documentation.
The before_send
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:
Sentry.init do |config|
# ...
config.before_send = lambda do |event, hint|
if hint[:exception].is_a?(ActiveRecord::ConnectionNotEstablished)
event.fingerprint = ["database-unavailable"]
end
event
end
end
For information about which hints are available see hints in Ruby.
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 (before_send
, before_breadcrumb
or the event processor system in the SDK).
Hints are available in two places:
before_send
/before_breadcrumb
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.
Sentry.init do |config|
# ...
config.before_send = lambda do |event, hint|
if hint[:exception].is_a?(ActiveRecord::ConnectionNotEstablished)
event.fingerprint = ["database-unavailable"]
end
event
end
end
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.
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.
To prevent certain transactions from being reported to Sentry, use the traces_sampler
or before_send_transaction
configuration option, which allows you to provide a function to evaluate the current transaction and drop it if it's not one you want.
Note: The traces_sampler
and traces_sample_rate
config options are mutually exclusive. If you define a traces_sampler
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:
Sentry.init do |config|
#...
config.traces_sampler = lambda do |sampling_context|
# transaction_context is the transaction object in hash form
# keep in mind that sampling happens right after the transaction is initialized
# for example, at the beginning of the request
transaction_context = sampling_context[:transaction_context]
# transaction_context helps you sample transactions with more sophistication
# for example, you can provide different sample rates based on the operation or name
op = transaction_context[:op]
transaction_name = transaction_context[:name]
case op
when /http/
case transaction_name
when /health_check/
0.0 # ignore health_check requests
else
0.1
end
else
0.0 # ignore all other transactions
end
end
end
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 traces_sampler
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.
Sentry.init do |config|
# ...
config.before_send_transaction = lambda do |event, _hint|
# skip unimportant transactions
if event.transaction == "/unimportant/healthcheck/route"
# don't send the event to Sentry
nil
else
# filter out SQL queries from spans with sensitive data
event.spans.each do |span|
span[:description] = '<FILTERED>' if span[:op].start_with?('db')
end
event
end
end
end
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").
- Package:
- gem:sentry-ruby
- Version:
- 5.17.3
- Repository:
- https://github.com/getsentry/sentry-ruby