Randomness requirements following W3C Trace Context level 2 #4162
Conversation
jmacd
changed the title
jmacd
changed the title
jmacd
force-pushed
the
jmacd/sampling_new
branch
from
fa9ec4c
to
71750cd
Compare
…ication into jmacd/sampling_new
Thanks Co-authored-by: Robert Pająk <pellared@hotmail.com> Co-authored-by: Kent Quirk <kentquirk@gmail.com>
…pecification into jmacd/sampling_new
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
…ication into jmacd/sampling_new
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
…ication into jmacd/sampling_new
jmacd
force-pushed
the
jmacd/sampling_new
branch
from
f0c68a3
to
140492b
Compare
jmacd
dismissed
tsloughter’s stale review
Please take another look, this should be fixed :-)
…ication into jmacd/sampling_new
| hexdigit = DIGIT ; a-f | ||
| ``` | ||
|
|
||
| The explicit randomness value is meant to be used instead of extracting randomness from TraceIDs, therefore it contains the same number of bits as a W3C Trace Context Level 2 recommends for TraceIDs. |
There was a problem hiding this comment.
| The explicit randomness value is meant to be used instead of extracting randomness from TraceIDs, therefore it contains the same number of bits as a W3C Trace Context Level 2 recommends for TraceIDs. | |
| The explicit randomness value is meant to be used instead of extracting randomness from TraceIDs, therefore it contains the same number of bits as W3C Trace Context Level 2 recommends for TraceIDs. |
|
|
||
| #### Explicit trace randomness | ||
|
|
||
| For root span contexts, the when the SDK generates a TraceID that does not meet the [W3C Trace Context Level 2 randomness requirements][W3CCONTEXTTRACEID], and when the initial `TraceState` does not already define the [`rv` sub-key of the OpenTelemetry TraceState][OTELRVALUE], the SDK SHOULD insert an explicit trace randomness value into the OpenTelemetry TraceState value containing 56 random bits. |
There was a problem hiding this comment.
| For root span contexts, the when the SDK generates a TraceID that does not meet the [W3C Trace Context Level 2 randomness requirements][W3CCONTEXTTRACEID], and when the initial `TraceState` does not already define the [`rv` sub-key of the OpenTelemetry TraceState][OTELRVALUE], the SDK SHOULD insert an explicit trace randomness value into the OpenTelemetry TraceState value containing 56 random bits. | |
| For root span contexts, when the SDK generates a TraceID that does not meet the [W3C Trace Context Level 2 randomness requirements][W3CCONTEXTTRACEID], and when the initial `TraceState` does not already define the [`rv` sub-key of the OpenTelemetry TraceState][OTELRVALUE], the SDK SHOULD insert an explicit trace randomness value into the OpenTelemetry TraceState value containing 56 random bits. |
|
|
||
| The OTLP representation for Span and Span Link includes a 32-bit field declared as Span Flags. | ||
|
|
||
| Bits 0-7 of the Span Flags field are reserved for the 8 bits of Trace Context flags, |
There was a problem hiding this comment.
| Bits 0-7 of the Span Flags field are reserved for the 8 bits of Trace Context flags, | |
| Bits 0-7 (8 least significant bits) of the Span Flags field are reserved for the 8 bits of Trace Context flags, |
| ### Sampling Requirements | ||
|
|
There was a problem hiding this comment.
this doc is marked "stable except where otherwise specified", is this section intentionally going straight to stable?
| @@ -530,6 +592,13 @@ public interface IdGenerator { | |||
| } | |||
| ``` | |||
|
|
|||
| Custom implementations of the `IdGenerator` SHOULD support setting the | |||
There was a problem hiding this comment.
nit:
SHOULD support setting
it seems the SDK would be responsible to set the random flag based on some IdGenerator property, and the IdGenerator would only expose some information about itself.
|
|
||
| #### Explicit trace randomness | ||
|
|
||
| For root span contexts, the when the SDK generates a TraceID that does not meet the [W3C Trace Context Level 2 randomness requirements][W3CCONTEXTTRACEID], and when the initial `TraceState` does not already define the [`rv` sub-key of the OpenTelemetry TraceState][OTELRVALUE], the SDK SHOULD insert an explicit trace randomness value into the OpenTelemetry TraceState value containing 56 random bits. |
There was a problem hiding this comment.
the SDK SHOULD insert an explicit trace randomness value into the OpenTelemetry TraceState
should it be an SDK responsibility? I assume that all OTel SDKs would (if not already) generate random trace-ids and rv would only be needed when custom id generator is used.
The distro/application that uses custom generator can be responsible for setting rv if they use non-random trace-ids and only if they need consistent sampling.
If we ask SDKs to do it, the concern is that at least initially, while most of systems don't support W3C Trace-Context level 2 and random flag, updated OTel SDKs will start generating rv (and start widely using tracestate).
|
Overall LGTM (once some of the latest feedback comments have been addressed). |
Changes
Updates Trace SDK and Propagator specifications with
Part of #1413.
Part of #3602.
Product of the Sampling SIG members @kentquirk @kalyanaj @oertl @PeterF778 and myself.
CHANGELOG.mdspec-compliance-matrix.md