Stabilize trace context in non-OTLP formats and define casing

[dashpole]

Closes #3303

Changes

From @tigrannajaryan in #3303 (comment):

I think the conclusion in #3518 was that we keep the names. It has been a while and there is no new evidence that we need to do something else so I suggest that we submit a PR that declares https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/logging_trace_context.md "Stable" and closes this issue.

This marks the specification for using trace_id, span_id, and trace_flags in non-OTLP logging formats stable.

@jack-berg

[tigrannajaryan]

Let's keep this open for a while to ensure visibility.

[dashpole]

@jmacd raised one potential concern: We want to add some OpenTracing fields (sampling priority?) to this specification, which have dots in them. This would potentially leave us with some fields with dots, and others with underscores. Josh, if there are related issues/PRs, feel free to add them here.

[tigrannajaryan]

@jmacd raised one potential concern: We want to add some OpenTracing fields (sampling priority?) to this specification, which have dots in them. This would potentially leave us with some fields with dots, and others with underscores. Josh, if there are related issues/PRs, feel free to add them here.

Can you clarify which OpenTracing fields? Dots are totally fine at namespace separators. We use underscores as word separators.

[jmacd]

I have a couple of concern about the absence of an explicit statement about tracestate, which is usually mentioned in the list of W3C trace context fields. In this case, I think it's OK to explicitly state that tracestate is not for recording in logs. We should, instead (IMO),define semantic conventions in case there are any useful fields in the tracestate that make sense for logs.

Here's what that looks like, for example: open-telemetry/semantic-conventions#793

In this case, I have work-in-progress to perform trace sampling based on OTEP 235 (https://github.com/open-telemetry/oteps/blob/main/text/trace/0235-sampling-threshold-in-trace-state.md) inside the collector-contrib probabilistic sampler processor, which applies to both spans and logs. What this means is that the sampler for logs will not try to encode sampling probability using an equivalent to tracestate in the log record, it will do that using attributes for randomness and threshold instead.

I propose this change before stabilizing: #3923

[jmacd]

Related: #3924

[carlosalberto]

@jmacd will #3924 will solve your concern? Can we go ahead and merge this PR or should we wait a little longer?

[jmacd]

@carlos I thought we should merge #3923 before merging this one. #3924 is related but not a prereq

[jmacd]

@carlosalberto please see #3923 (comment), thanks!

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[pellared]

@open-telemetry/technical-committee, is this blocked by anything?

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[carlosalberto]

Ping @jsuereth @arminru @bogdandrutu @tigrannajaryan @jack-berg @pellared (who has previously approved this PR).

[carlosalberto]

@dashpole It seems only minor edits are needed before we can (finally) merge this ;)