-
Notifications
You must be signed in to change notification settings - Fork 947
feat(sampler-composite): add experimental implementation of composite sampling spec #5839
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 3 commits
33485d3
0a967ac
1fbc1dc
0f1d33e
b41131b
38ecc13
acc3070
63c6c06
3119308
a6df902
2b5e7c5
7ced0a5
7f7afdc
47c3fd4
61656b5
861ac86
6592630
98e5cd8
b7a34e6
fd5c24a
af4bc3e
00a00f9
02c8bce
04809a3
ffc9bc4
21ad9dc
535292e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -32,12 +32,10 @@ export type OtelTraceState = { | |||||||||||||||||||||||
| rest?: string[]; | ||||||||||||||||||||||||
| }; | ||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
| export function invalidTraceState(): OtelTraceState { | ||||||||||||||||||||||||
| return { | ||||||||||||||||||||||||
| randomValue: INVALID_RANDOM_VALUE, | ||||||||||||||||||||||||
| threshold: INVALID_THRESHOLD, | ||||||||||||||||||||||||
| }; | ||||||||||||||||||||||||
| } | ||||||||||||||||||||||||
| export const INVALID_TRACE_STATE: OtelTraceState = { | ||||||||||||||||||||||||
| randomValue: INVALID_RANDOM_VALUE, | ||||||||||||||||||||||||
| threshold: INVALID_THRESHOLD, | ||||||||||||||||||||||||
| }; | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
| export const INVALID_TRACE_STATE: OtelTraceState = { | |
| randomValue: INVALID_RANDOM_VALUE, | |
| threshold: INVALID_THRESHOLD, | |
| }; | |
| export const INVALID_TRACE_STATE: OtelTraceState = Object.freeze({ | |
| randomValue: INVALID_RANDOM_VALUE, | |
| threshold: INVALID_THRESHOLD, | |
| }); |
IIUC, using Object.freeze here should help prevent accidental mutation of this re-used object.
There is one current usage in opentelemetry-js.git:
Lines 115 to 117 in f2b0d2a
| const DEFAULT_AGGREGATION = Object.freeze({ | |
| type: AggregationType.DEFAULT, | |
| }); |
I only went looking because I don't have a lot of personal experience using Object.freeze.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, makes sense!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[This is a general question. I'm commenting here for lack of a good place to mention it.]
My head is spinning from the inconsistent (har har) use of
CompositeorComposableorConsistentusage in class and interface names in the spec, OTEP, and implementations. And also, a little less so, in some class name changes, e.g.ConsistentFixedThresholdin the OTEP vs.ComposableTraceIDRatioBasedin the spec. I haven't read through this PR yet, but I'm guessing other API diffs between OTEP and spec will show up, e.g.threshold_reliablein the spec vs.IsAdjustedCountReliablein the OTEP.While I don't know that the names used in the spec need to be the same names as in the implementation APIs, approaching the same names is likely desired. Are we implementing the spec here, or the Java
consistent56implementation, which seems to follow the OTEP naming (which makes sense as it was probably developed before the spec renamings)?I'm happy to go asking about this in the OTel channels.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - I will read the spec and align with it as much as possible, sorry for missing it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious what Java (and the Rust/Go implementations that are linked to from open-telemetry/opentelemetry-specification#4466) will do. I.e. will they change their implementations to use the class names in the spec? Or change the spec to use
Consistent-prefix?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the rust and go implementations (esp. the go implementation README: https://github.com/jmacd/go-sampler) I'm pretty certain
CompositeSamplerandComposable*Samplernaming is the intent.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked for clarification in #otel-sampling: https://cloud-native.slack.com/archives/C027DS6GZD3/p1755299016130699
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue/answer on the naming: open-telemetry/opentelemetry-specification#4640
Basically: "So the short answer is that the Specification names should be used.", but "do not strongly believe that all SDKs need the same exact names".
So, whatever names are used by a particular SDK is fine.
(Note that I would expect the OTel schema for its configuration data model would use the spec names for these samplers, when these new samplers are added to the schema. At that point there is some value to users and maintainers if the configuration names match the implementation names.)