Clarify legacy logs format trace context flags and tracestate #3923
Conversation
Co-authored-by: Robert Pająk <pellared@hotmail.com>
…cification into jmacd/log_legacy
…ication into jmacd/log_legacy
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
@pellared maybe re-review this? Or still blocked? |
| Description: Trace flags as defined in [W3C Trace Context Level | ||
| 2](https://www.w3.org/TR/trace-context-2/#trace-flags) | ||
| specification. At the time of writing the specification defines two | ||
| flags - the SAMPLED flag and the RANDOM flag. This field is logical-OR | ||
| combined into the least-significant 8-bits of the `Flags` field. This | ||
| field is optional. |
There was a problem hiding this comment.
See ^^^ 4 lines up it says we have a field named TraceFlags. I'm clarifying that it's not real. It's conceptual, and it's actually encoded in the (undocumented here) field named Flags.
There was a problem hiding this comment.
I'm clarifying that it's not real.
I am not sure I agree with that. It seems pretty real from data model perspective. In the data model we do have a TraceFlags field, as real as it gets in data models. The fact that OTLP uses a Flags field to encode this information is not important from the perspective of this document.
It seems we are bringing the implementation details of OTLP into the data model doc and I don't understand why.
There was a problem hiding this comment.
My intention here was to clarify what may be internal confusion of mine -- I was recently surprised to learn how the W3C Trace Context defines propagation of unknown flags. Specifically, participants MUST zero the flags they do not recognize. I bring this up because the link on "as defined in W3C Trace Context" links to an overview section, whereas if you read https://www.w3.org/TR/trace-context/#other-flags you may question what it means to be "as defined in". It looks to me that if any flag besides the two we know about (Sampled, 0x1 and Random, 0x2) makes an invalid trace flags value, and perhaps the data model should say something about this.
However, my only intention was to be very clear that if TraceFlags arrives as a string like "ffff" we do not consider it valid TraceFlags, because it is too wide. I think we mean "syntactically defined as trace flags are defined" but that we are not forbidding legacy logs formats from creating logs data with unrecognized flags set as I speculated about above.
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Part of #3303.
Changes
Clarifies how the trace flags are represented when placing trace context in log records.
Clarifies that
tracestateis not encoded when placing trace context in log records.CHANGELOG.mdfile updated for non-trivial changesspec-compliance-matrix.mdupdated if necessary