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

It should be possible to propagate context without creating a new span #4271

Open
lmolkova opened this issue Oct 22, 2024 · 2 comments
Open
Assignees
Labels
spec:trace Related to the specification/trace directory triage:accepted:ready-with-sponsor Ready to be implemented and has a specification sponsor assigned

Comments

@lmolkova
Copy link
Contributor

lmolkova commented Oct 22, 2024

There are multiple cases when passive context propagation (without modification) is desirable:

  • proxy/load-balancer/service-mesh that just passes context around. While it may be implemented with explicit context propagation, it'd be hard to do especially when the component produces some logs or events that should be correlated.
  • Tracing without SDK - it could be a reasonable default for a service to just propagate context when tracing is disabled. It was also considered as possible API default at some point - Specify the behavior of the Tracer APIs in the absence of an SDK #689
  • similar cases when application wants to hide its implementation details from the users. E.g. Azure Functions host handles request and invokes a worker running in a different process. Tracing calls between host and worker is a bit verbose and should be opt-in, so the desire is to create one span on the host and use it as a parent for the telemetry on the worker
  • Inside the process context propagation without modification is useful when suppressing spans without breaking correlation.

Some languages (Java, Go) allow it all with a code like

// extract span context
SpanContext remote = SpanContext.createFromRemoteParent("<traceId>", "<spanId>", ...);

// create parent Context from SpanContext
Context parent = Context.root().with(Span.wrap(remote));

// now we can make it current and it'll become a parent to any spans created in its scope
Scope scope = parent.makeCurrent();
Span child = tracer.spanBuilder("child").startSpan();

child.end();
scope.close();

but some other languages (.NET) don't implement it since spec does not tell anything about it - open-telemetry/opentelemetry-dotnet#5286

Indeed, https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#context-interaction defines interactions between Span and Context and tells nothing about SpanContext or ability to represent existing SpanContext with a Span


The solutions I would like:

  1. Add a language that allows to associate a SpanContext with the current Context.
  2. It implies the ability to have a Span-like representation of a SpanContext that'd be returned by Tracer.getCurrentSpan().
  3. Such span would be non-recording and would just wrap the SpanContext it was created in. See PropagatedSpan implementation in Java [UPDATE]: Or nonRecordingSpan in go (thanks @dmathieu for the pointers).
@lmolkova lmolkova added the spec:trace Related to the specification/trace directory label Oct 22, 2024
@dmathieu
Copy link
Member

For the record, Go allows doing this with the trace.ContextWithSpanContext and trace.ContextWithRemoteSpanContext methods, which allows injecting a span context into the context.

@mtwo mtwo added the triage:deciding:tc-inbox Needs attention from the TC in order to move forward label Oct 29, 2024
@lmolkova lmolkova self-assigned this Oct 30, 2024
@lmolkova lmolkova added [label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR triage:accepted:ready-with-sponsor Ready to be implemented and has a specification sponsor assigned and removed triage:deciding:tc-inbox Needs attention from the TC in order to move forward labels Oct 30, 2024
@lmolkova lmolkova removed the [label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR label Oct 30, 2024
@tsloughter
Copy link
Member

I think I'm missing something. In the example code given isn't Span.wrap(remote) actually creating a new span? Following the API spec for wrapping, https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#wrapping-a-spancontext-in-a-span

Which is how the propagation api is supported, it extracts the span context and attaches it as the current span so it is used as the parent.

We actually do this different in Erlang/Elixir and don't require a new Span, but I'm not sure that is needed or changes to the spec to support what I understand the examples to be?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:trace Related to the specification/trace directory triage:accepted:ready-with-sponsor Ready to be implemented and has a specification sponsor assigned
Projects
Status: Spec - Accepted
Development

No branches or pull requests

4 participants