This feature is available only if you're in the Early Adopter program. Features available to Early Adopters are still in-progress and may have bugs. We recognize the irony.
If you’re interested in being an Early Adopter, you can turn your organization’s Early Adopter status on/off in General Settings. This will affect all users in your organization and can be turned back off just as easily.
Following are the current known limitations and functionality specifics that can create challenges when you're creating server-side sampling rules.
The Dynamic Sampling feature is currently only available for the following SDK's:
- Python: 1.7.2 or later
- Apple: 7.23.0 or later
- Android: 6.2.1 or later
- React Native: 4.3.0 or later
- Dart and Flutter: 6.11.0 or later
If your application relies on any Sentry SDK that isn't specified above, then you won’t be able to use Sentry's Dynamic Sampling.
When sampling traces, the decision to keep or throw away a trace needs to be taken when the first transaction of the trace is seen. This, in turn, means that for transaction traces, only the attributes of the first transaction can participate in the sampling decision. For example, if you have a frontend and a backend in the trace, you can only sample the trace by the SDK context available in the frontend, not the backend data.
Related to the previously discussed issue about trace rules, setting the transaction, the release, or the environment in a transaction will have no influence on a trace sampling decision if the transaction is not the first transaction in the trace.
We're actively working on adding more conditions that you can sample by (for example, transaction name). However, feel free to provide suggestions by joining the channel #dynamic-sampling on our Discord Server.
Currently, rules containing more than one condition use a logical
and for each condition. Multiple values for a condition use a logical
or condition for matching.
The decision to implement it this way was based on the desire to keep the UI simple while still being able to cover all common scenarios.
Having multiple arguments within a single condition use the
or operator is what we typically want since an attribute generally has one value, and having an
and condition wouldn't make sense. For example, the environment attribute could be
dev, but it couldn't be
dev at the same time.