open-telemetry
Composable sampler naming conventions
What are you trying to achieve?
The prototype for Java consistent probability sampling package, https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/consistent-sampling, has names that conflict with the new specification.
Discussed in Slack, written by @trentm
New implementations of the composite samplers should bias to the class/interface naming in the spec (ComposableAlwaysOn, ComposableTraceIDRatioBased, et al) over the naming in the OTEP and Java impl (ConsistentAlwaysOn, ConsistentFixedThreshold), right?
Hi. I'm reviewing a PR to add support for (a subset) of the sampling support documented at https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/ (i.e. OTEP 250) for OTel JS: https://github.com/open-telemetry/opentelemetry-js/pull/5839 and I have some general questions on the spec/OTEPs and guidance for implementations. (This PR for OTel JS is related to a similar one adding support to OTel Python: https://github.com/open-telemetry/opentelemetry-python/pull/4714) Currently these implementations were based on the Java implementation at https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/consistent-sampling/src/main/java/io/opentelemetry/contrib/sampler/consistent56 From reading the OTEPs and the spec text, I notice that there are differences in the naming used for classes: OTEP 250 and the Java impl: ConsistentAlwaysOff, ConsistentRuleBased, ConsistentParentBased, etc. The spec: ComposableAlwaysOn, ComposableTraceIDRatioBased, ComposableParentThreshold, etc. I didn't see anywhere in the spec PR where the name differences were discussed. I gather that new implementations should prefer the naming in the spec, right? Looking at the jmacd's Go and Rust implementations, I see that they tend towards the spec naming.
What did you expect to see?
I @jmacd do not strongly believe that all SDKs need the same exact names. "Composable" and "Consistent" are both acceptable, IMO.
cc/ @trentm
So I did a quick review and indeed, names have slightly changed. So the short answer is that the Specification names should be used.
The long answer is that OTEPs are:
documents of intent. They become requirements only after their contents have been integrated into the actual Specification.
On the names themselves, these new set of samplers are still in development, and we can still change their names if needed. I agree with @jmacd on
do not strongly believe that all SDKs need the same exact names. "Composable" and "Consistent" are both acceptable
But we can discuss that if needed. Wdyt @trentm ?
do not strongly believe that all SDKs need the same exact names.
Sounds good to me. It is helpful to have this mentioned here for reference. Thanks.
I would guess that eventual integration of these newer samplers into the OTel configuration data model schema would enshrine one set of names.