Sampling

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.

Sampling Error Events

To send a representative sample of your errors to Sentry, call the sample_rate builder on your ClientOptions with 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:

let _guard = sentry::init(sentry::ClientOptions::new().sample_rate(1.0));

let _guard = sentry::init(sentry::ClientOptions::new().sample_rate(1.0));

The error sample rate defaults to 1, meaning all errors are sent to Sentry.

Sampling Transaction Events

We recommend sampling your transactions for two reasons:

1. Capturing a single trace involves minimal overhead, but capturing traces for every page load or every API request may add an undesirable load to your system.
2. Enabling sampling allows you to better manage the number of events sent to Sentry, so you can tailor your volume to your organization's needs.

Choose a sampling rate with the goal of finding a balance between performance and volume concerns with data accuracy. You don't want to collect too much data, but you want to collect sufficient data from which to draw meaningful conclusions. If you’re not sure what rate to choose, start with a low value and gradually increase it as you learn more about your traffic patterns and volume.

Configuring the Transaction Sample Rate

The Rust SDK stores a single traces sampling strategy. Configure it with one of these builders:

1. Uniform sample rate (traces_sample_rate):

   • Selects TracesSamplingStrategy::FixedRate
   • Provides an even cross-section of transactions, no matter where in your app or under what circumstances they occur
   • Uses default inheritance and precedence behavior for the fixed-rate strategy

2. Sampling function (traces_sampler) which:

   • Selects TracesSamplingStrategy::Function
   • Samples different transactions at different rates
   • Filters out some transactions entirely
   • Decides through the callback instead of the fixed-rate inheritance path

These builders are mutually exclusive. Each call replaces the previous strategy, so the last sampling builder called wins.

By default, the strategy is TracesSamplingStrategy::Disabled, meaning tracing is off and transactions are not sent. You must call either .traces_sample_rate(...) or .traces_sampler(...) to enable a non-disabled strategy. Calling .traces_sample_rate(0.0) is an explicit fixed-rate strategy and is not equivalent to leaving tracing disabled; see inheritance.

Setting a Uniform Sample Rate

To do this, call traces_sample_rate on your ClientOptions builder with a number between 0 and 1. With this option set, every transaction created will have that percentage chance of being sent to Sentry. For example, if you set traces_sample_rate to 0.2, approximately 20% of your transactions will be recorded and sent. That looks like this:

let _guard = sentry::init(
    sentry::ClientOptions::new()
        .dsn("___PUBLIC_DSN___")
        .maybe_release(sentry::release_name!())
        .traces_sample_rate(1.0),
);

let _guard = sentry::init(
    sentry::ClientOptions::new()
        .dsn("___PUBLIC_DSN___")
        .maybe_release(sentry::release_name!())
        .traces_sample_rate(1.0),
);

Tracing is disabled by default (TracesSamplingStrategy::Disabled). Calling .traces_sample_rate(0.0) is not the same as leaving tracing disabled: an explicit fixed rate of 0.0 can still honor an inherited parent sampling decision, while the default disabled strategy rejects the transaction even when a parent or explicit decision is positive.

Inheritance

Whatever a transaction's sampling decision, that decision will be passed to its child spans and from there to any transactions they subsequently cause in other services.

(See Distributed Tracing for more about how that propagation is done.)

If the transaction currently being created is one of those subsequent transactions (in other words, if it has a parent transaction), the upstream (parent) sampling decision is available on the transaction context as ctx.sampled(). Behavior depends on the configured strategy:

• TracesSamplingStrategy::Disabled (default): the transaction is not sent, even when a parent decision is positive.
• TracesSamplingStrategy::FixedRate (from .traces_sample_rate(...)): an inherited parent decision is honored. When there is no parent decision, the configured fixed rate is used. This remains true for an explicit rate of 0.0.
• TracesSamplingStrategy::Function (from .traces_sampler(...)): the callback receives the transaction context, including any parent decision, and returns the sample rate. Inherit the parent decision in the callback when you want to keep distributed traces intact.

In most cases, inheriting a parent decision is the right choice, to avoid breaking distributed traces. A broken trace will not include all your services.

Precedence

There are multiple ways for a transaction to end up with a sampling decision.

• The default disabled traces sampling strategy
• Random sampling according to a static sample rate set with traces_sample_rate
• Random sampling according to a sample function rate returned by traces_sampler
• Absolute decision (100% chance or 0% chance) returned by traces_sampler
• If the transaction has a parent, inheriting its parent's sampling decision
• Explicit decision set on the transaction context, for example with ctx.set_sampled(true) before start_transaction

Because only one traces sampling strategy is active at a time, strategy selection is last-builder-call-wins when both .traces_sample_rate(...) and .traces_sampler(...) appear in configuration. Once a strategy is selected, the following rules apply:

1. If the strategy is Disabled, the transaction is not sampled.
2. If the strategy is Function, the callback's returned rate is used. The callback may read or ignore a parent decision on the transaction context.
3. If the strategy is FixedRate and the transaction context carries an explicit sampling decision (from a parent or from set_sampled), that decision is used.
4. If the strategy is FixedRate and there is no explicit decision, the configured fixed rate is used.