Add incubator implementation of composite sampling spec#7626
Add incubator implementation of composite sampling spec#7626jkwatson merged 6 commits intoopen-telemetry:mainfrom
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #7626 +/- ##
============================================
+ Coverage 89.99% 90.07% +0.08%
- Complexity 7079 7172 +93
============================================
Files 803 812 +9
Lines 21412 21653 +241
Branches 2086 2123 +37
============================================
+ Hits 19269 19504 +235
- Misses 1479 1480 +1
- Partials 664 669 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
cc @PeterF778 @oertl |
| Attributes attributes, | ||
| List<LinkData> parentLinks) { | ||
| TraceState traceState = Span.fromContext(parentContext).getSpanContext().getTraceState(); | ||
| OtelTraceState otTraceState = OtelTraceState.parse(traceState); |
There was a problem hiding this comment.
teency nit: rename to otelTraceState so as to not confuse my poor brain between this and openTracing.
There was a problem hiding this comment.
I thought by now we may have been past that but guess not ;)
| otTraceState.getRandomValue(), INVALID_THRESHOLD, otTraceState.getRest()); | ||
| } | ||
|
|
||
| String ot = otTraceState.serialize(); |
There was a problem hiding this comment.
maybe rename to "seralizedState"?
|
Seems like this would be an excellent target for some property-based tests. I can't remember if we have any in here already, but it might be a good opportunity, since we can very clearly define the invariants, and generate random inputs, verifying the outputs match the expectations. |
|
Thanks - we have fuzz tests already which I think are basically what you're getting at. Sounds good will add some |
Fuzz testing is slightly different, in that the goal is usually just to make sure that things don't break, rather than testing invariants, but if you can use the same framework to accomplish property testing, that would be awesome. |
| boolean sampled = false; | ||
| if (isValidThreshold(intent.getThreshold())) { | ||
| thresholdReliable = intent.isThresholdReliable(); | ||
| long randomValue; |
There was a problem hiding this comment.
If the threshold is not reliable, the sampler must not use the random value from the trace state or from the trace-id. This is because we cannot guarantee that these "random" values have the required uniform distribution over the (MIN_THRESHOLD, MAX_THRESHOLD) interval.
There was a problem hiding this comment.
I can't find anything in the spec on this. I noticed the caveat to deal with rate limiting sampler but since that's also not in the spec went with the simpler implementation. Is this something to change now or can we follow up after spec clarification?
There was a problem hiding this comment.
The spec changes are pending, but you can see how this case is handled in https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/consistent-sampling/src/main/java/io/opentelemetry/contrib/sampler/consistent56/ConsistentSampler.java
There was a problem hiding this comment.
Ok went ahead and switched to generating a random when unreliable
| boolean sampled = false; | ||
| if (isValidThreshold(intent.getThreshold())) { | ||
| thresholdReliable = intent.isThresholdReliable(); | ||
| long randomValue; |
There was a problem hiding this comment.
Ok went ahead and switched to generating a random when unreliable
| Attributes attributes, | ||
| List<LinkData> parentLinks) { | ||
| TraceState traceState = Span.fromContext(parentContext).getSpanContext().getTraceState(); | ||
| OtelTraceState otTraceState = OtelTraceState.parse(traceState); |
There was a problem hiding this comment.
I thought by now we may have been past that but guess not ;)
| assertState(output, rv, th); | ||
| } | ||
|
|
||
| private static void assertState(OtelTraceState state, long rv, long th) { |
There was a problem hiding this comment.
@jkwatson This is what I came up with for testing properties based on fuzz. What do you think?
There was a problem hiding this comment.
I can't say I grok all the assertions, but this looks good! Thanks!
|
@jkwatson Think we can proceed with this PR, or anything I should look at? Thanks |
If @PeterF778 can give it a 👍🏽 then I think we're good to go. |
PeterF778
left a comment
There was a problem hiding this comment.
Looks nice and clean, thanks!
Fixes #7615
This implements composite samplers as in the development spec
https://opentelemetry.io/docs/specs/otel/trace/sdk/#built-in-composablesamplers
https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/
The implementation is quite similar to the contrib one that was used to drive the OTEP, though the naming is updated to match what made it to the spec
https://github.com/open-telemetry/opentelemetry-java-contrib/tree/fc6507e5e24473fc4a131e3bda1d4b1156fe18c9/consistent-sampling/src/main/java/io/opentelemetry/contrib/sampler/consistent56
For reference, implementations for JS and Python
open-telemetry/opentelemetry-js#5839
open-telemetry/opentelemetry-python#4714