Explain purpose of Traceflags in Log Data Model

[tigrannajaryan]

The Log Data Model says that Traceflags are part of the Log Record.

There is no explanation about how the Traceflags are set in the Log Record and how they can be used.

One explanation I have heard in the past is that the following:

• Log Records that are generated in the context of a Span will have that Span's Traceflags recorded.
• The recorded Traceflags will in particular contain the Sampled flag (the only flag that exists today).
• The Log Record will be delivered to the log backend.
• The Span (and the Trace) will be delivered to the trace backend.
• The Sampled flag in the Log Record can be used by the backend to know that the trace was sampled.
• This knowledge can be used to know that that a navigation link (a correlation) may be established between the Log Record stored in the log backend and the Trace stored in the trace backend (obviously with the additional help of TraceId/SpanId fields). Without the Sampled flag the link cannot be established with certainty since the trace may not exist.

I am not sure I understand the reasoning. From what I understand the Sampled flag is set to 0 by default, which means that the trace may or may not be sampled. The fact that the Sampled flag's value in the Log Record is set to 0 is not an indication that the corresponding trace does not exist. It is merely an indication that the corresponding trace may or may not exist. If the Sampled flag is set to 1 then it is a certain indication that the trace should exist.

Assuming the above paragraph is correct, I am failing to see the value of the Sample flag. How is it helpful to know that trace may or may not exists? What capabilities does this enable?

If my understanding of the Traceflags and Sampled flag are incorrect someone please help me understand it.

[tigrannajaryan]

@open-telemetry/specs-approvers and experts in W3C tracestate and sampling, can you help?

[jmacd]

I've discovered that W3C is ambiguous on the meaning of the sampled flag when there may be more than one tracing "tenant" active in a trace. The word "tenant" has been used in the W3C specification in ways that are not well specified but does imply sampled is just a hint.

#2047 is trying to establish tracestate fields that would supersede sampled and potentially support multi-tenancy, but in working through this I came to an answer to your question.

If W3C adds any new flags with the remaining 7 bits that have relevance for logging, it would be nice to already be recording those flags. In the logs data model this is already true, but it is not true for spans. So I'll turn this question around: why do we not record the trace flags in the span?

[tigrannajaryan]

Discussed this extensively in the Spec SIG meeting. Here is the summary:

Log records may be emitted while there is an ongoing operation represented by a span. The trace sampler in Otel SDK may have already decided to drop that particular trace (using head sampling). So, that particular trace will never leave the Otel SDK and will not be available in the backend.

However, the log record may still be emitted. Log emitter does not consult the trace sampler to decide if the log record is going to be emitted from the Otel SDK or no (and even if we had a log sampler that did consult the trace sampler it may still have an override so that for example all high severity log records are still emitted).

In this situation in the backend we will have a log record with a traceid/spanid values defined, but which do not correspond to a trace/span which exists in the backend. So the backend UI can visualize this fact and tell the user that the corresponding trace/span is not present because it was dropped by the sampler.

Note that the Otel SDK's trace sampler always sets the "sampled=1" flag for all traces that are not dropped. Otel SDK never emits a trace with "sampled=0". So, a presence of a log record with "sampled=0" flag is a sufficient condition to know that the trace that corresponds to the log record is known for certain cannot exist in the backend.

Because of this the Traceflags field in log data model is valuable and needs to stay.

@jsuereth @bogdandrutu @jmacd can you please confirm that this is a correct summary and a correct understanding?

[tigrannajaryan]

@jsuereth @bogdandrutu @jmacd I need your help to confirm the above summary is correct.

[djaglowski]

The Log SIG reviewed this issue today as part of our effort to stabilize the log data model. Consensus is that we'd appreciate validation of Tigran's summary from any of @jsuereth @bogdandrutu @jmacd before closing the issue.

[djaglowski]

This was discussed in Log SIG again today. Consensus was that there seems to be no objection to the interpretation described by Tigran above, and that the issue can be closed.