Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limitation of distributed tracing extension #1324

Open
devjeff opened this issue Jan 16, 2025 · 1 comment
Open

Limitation of distributed tracing extension #1324

devjeff opened this issue Jan 16, 2025 · 1 comment

Comments

@devjeff
Copy link

devjeff commented Jan 16, 2025

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.

@devjeff
Copy link
Author

devjeff commented Jan 17, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant