We should provide a way for users to sample consistently positively or negatively based on the previous/initial trace (i.e. the one we link since #14992). Concretely, we propose to add an option to browserTracingIntegration:
Sentry.init({integrations: [browserTracingIntegration({linkPreviousTrace: 'in-memory',// other values 'session-storage' | 'off'sampleLikePreviousTrace: true,// does nothing if linkPreviousTrace === 'off'})]})This option is opt-in, meaning by default, the SDK continues to sample independently between traces.
Specifically, if sampleLikePreviousTrace is true
- force a positive sampling decision if previous trace was sampled positively
- ensure that sample rand and rate from initial trace is applied and propagated in new trace
- force negative sampling decision if previous trace was sampled negatively
- fall back to user-defined sampling mechanism (
tracesSampleRate or tracesSampler) if no previous trace available (e.g. because first trace in chain or linkPreviousTrace === 'off') - injected meta tags on pageload have precedence over previous trace sampling decision (if session-storage is opted into)
Otherwise, fall back to fall back to user-defined sampling mechanism (tracesSampleRate or tracesSampler) => independent sampling.
As for implementation: We probably can reuse the beforeSampling client hook to keep the logic in browserTracingIntegration. But we need to make sure that the hook emits in sampleSpan (or prior to calling it) within the Core SDK. Also we need to update or set the propagation context accordingly.
In other words, the only way how consistent sampling across traces can work is by pretending it is continuing a sampling decision within a distributed trace. Which is a fundamental limitation of the tracing and metrics model we're building at Sentry. This really shows that tracesSampler still permits a lot of possibilities for users to influence extrapolation in unexpected ways.
Naming
Naming is hard and I don't have a great name yet for this option. Some suggestions:
The initial proposal was reworked b/c it would have significantly skewed span metric extrapolation. I'm leaving this here for some context as to what we could have had.
Initial Proposal (for context)
Description
We should provide a way for users to make a sampling decision for a trace based on the sampling decision of the previous trace (i.e. the one we link since #14992). Concretely, we propose to add an option to tracesSampler:
Sentry.init({dsn: '...',tracesSampler(({previousTraceSampled})=>{if(previousTraceSampled){return1.0;// could also just increase the rate, e.g. to 0.5}elseif(previousTraceSampled===false){return0;}return0.05;})})where previousTraceSampled is typed as boolean | undefined. The semantics for all values:
true - previous trace was positively sampled and sent to Sentry (this makes no guarantees that this trace in fact was stored; it can still be dropped by Relay)false - previous trace was negatively sampled and not Sent to Sentryundefined - multiple implications
- the current trace is the first one
- previous trace collection is disabled by users
- previous trace collection is not available (e.g. server SDK)
This allows users to ensure that a trace chain is longer or in general more complete.
Important notes:
- By default the SDK will not continue a positive sampling decision based on the previous trace. This must be a concious user decision to opt into.
- The potential quota increase must be mentioned in JSDoc and docs
We should provide a way for users to sample consistently positively or negatively based on the previous/initial trace (i.e. the one we link since #14992). Concretely, we propose to add an option to
browserTracingIntegration:This option is opt-in, meaning by default, the SDK continues to sample independently between traces.
Specifically, if
sampleLikePreviousTraceistruetracesSampleRateortracesSampler) if no previous trace available (e.g. because first trace in chain orlinkPreviousTrace === 'off')Otherwise, fall back to fall back to user-defined sampling mechanism (
tracesSampleRateortracesSampler) => independent sampling.As for implementation: We probably can reuse the
beforeSamplingclient hook to keep the logic inbrowserTracingIntegration. But we need to make sure that the hook emits insampleSpan(or prior to calling it) within the Core SDK. Also we need to update or set the propagation context accordingly.In other words, the only way how consistent sampling across traces can work is by pretending it is continuing a sampling decision within a distributed trace. Which is a fundamental limitation of the tracing and metrics model we're building at Sentry. This really shows that
tracesSamplerstill permits a lot of possibilities for users to influence extrapolation in unexpected ways.Naming
Naming is hard and I don't have a great name yet for this option. Some suggestions:
sampleLikePreviousTracesampleLinkedTraces(Consistently|Uniformly)forwardSamplingToLinkedTracesforwardSamplingToNextTracesampleTracesConsistentlyconsistentTraceSampling<-- this is what we went with in feat(browser): Add option to sample linked traces consistently #16037The initial proposal was reworked b/c it would have significantly skewed span metric extrapolation. I'm leaving this here for some context as to what we could have had.
Initial Proposal (for context)
Description
We should provide a way for users to make a sampling decision for a trace based on the sampling decision of the previous trace (i.e. the one we link since #14992). Concretely, we propose to add an option to
tracesSampler:where
previousTraceSampledis typed asboolean | undefined. The semantics for all values:true- previous trace was positively sampled and sent to Sentry (this makes no guarantees that this trace in fact was stored; it can still be dropped by Relay)false- previous trace was negatively sampled and not Sent to Sentryundefined- multiple implicationsThis allows users to ensure that a trace chain is longer or in general more complete.
Important notes: