You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried to understand the use of the Distributed Tracing Extension and I think it has an unnecessary limitation for tracing analysis:
According to the specification, the parent span ID (in the ce-traceparent header) typically represents the span from the originating service rather than being updated at each hop.
If I understand the goal of the extension correctly, it provides means to carry the tracing context, so that it can be extracted on receiver side and be applied as the parent context for new tracing spans.
Consequences:
Flat Traces: If the parent span ID remains static, the resulting trace will show a flat structure where all spans appear to be direct children of the initial span, losing the hierarchical relationships.
Loss of Context: Without updating the parent span ID, the trace cannot correctly reflect the actual sequence of events and their dependencies across multiple services.
Solution:
Remove the restriction that the extension "MUST NOT carry trace information of each individual hop".
Maybe I misunderstand the use case for this extension. If the transported trace data is not meant to be extracted and used by the OpenTelemetry libraries, then the actual use of the extension should be better clarified in the spec.
The text was updated successfully, but these errors were encountered:
I have also found this issue or discussion. It has some interesting points, which I really miss in the spcification itself. It would be really helpful for other people that read the spec, if it contained the description of use cases, which the extension was designed for.
As of my current understanding I see the following logic that is required on the receiver side of an event transmission:
if 'traceparent' header is present
extract the OpenTelemetry context and use it as the parent
else
create a new root span (with a new trace-id)
// this if is independent from the above, as we can have both - a parent and a link
if received payload contains a cloud event (or ce-traceparent header is present)
extract trace context from 'ce-traceparent'
add a link to it from the newly created span
I tried to understand the use of the Distributed Tracing Extension and I think it has an unnecessary limitation for tracing analysis:
According to the specification, the parent span ID (in the ce-traceparent header) typically represents the span from the originating service rather than being updated at each hop.
If I understand the goal of the extension correctly, it provides means to carry the tracing context, so that it can be extracted on receiver side and be applied as the parent context for new tracing spans.
Consequences:
Flat Traces: If the parent span ID remains static, the resulting trace will show a flat structure where all spans appear to be direct children of the initial span, losing the hierarchical relationships.
Loss of Context: Without updating the parent span ID, the trace cannot correctly reflect the actual sequence of events and their dependencies across multiple services.
Solution:
Remove the restriction that the extension "MUST NOT carry trace information of each individual hop".
Maybe I misunderstand the use case for this extension. If the transported trace data is not meant to be extracted and used by the OpenTelemetry libraries, then the actual use of the extension should be better clarified in the spec.
The text was updated successfully, but these errors were encountered: