Refactor the built-in Samplers for probability sampling #2179
Labels
area:sampling
Related to trace sampling
area:sdk
Related to the SDK
spec:trace
Related to the specification/trace directory
What are you trying to achieve?
For the probability sampling specification, a review comment in #2047 points to a potential for inconsistency stemming from the
ParentBased
Sampler API, which permits configuring different samplers based on the parent context'ssampled
flag.The comment #2047 (comment) thread points out that
ParentBased
which is configured with up to 5 Samplers can be replaced by two primitives,DelegatingSampler
(configured with up to 3 Samplers) andFlagSampler
(with zero parameters, only used for non-roots).What would we like to see?
As we introduce probability sampling and wish to avoid inconsistencies resulting from improper Sampler configuration, the ideal state seems to be the following set of built-in samplers:
ConsistentParentProbabilitySampler
(0 parameters) that validates the OpenTelemetry tracestate fields in #2047 and otherwise does what the hypotheticalFlagSampler
described above would do.ConsistentProbabilitySampler
(1 parameter: probability) that implements the sampling logic in #2047 and records OpenTelemetry tracestateDelegatingSampler
(1 required parameter: root Sampler, 2 optional parameters: localParent, remoteParent Samplers): implements the formerParentBased
style of delegation and enforces consistent adjusted counts when delegating for non-root spanswith two built-in aliases:
AlwaysOn
(0 parameters) equivalent toConsistentProbabilitySampler(1)
AlwaysOff
(0 parameters) equivalent toConsistentProbabilitySampler(0)
The text was updated successfully, but these errors were encountered: