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

[OpenTracing Bridge] Support returning non-nil bridgeSpanContext in Extract when traceId and SpanId are not present in OTel SpanContext #3952

Open
ChenX1993 opened this issue Mar 31, 2023 · 2 comments · May be fixed by #3998
Labels
enhancement New feature or request

Comments

@ChenX1993
Copy link
Contributor

ChenX1993 commented Mar 31, 2023

Problem Statement

Hi, really appreciate anyone who contributed to the OpenTracing Bridge.

The request is to make func (t *BridgeTracer) Extract(format interface{}, carrier interface{}) (ot.SpanContext, error) method able to conditionally return non-nil bridgeSpanContext when traceId and SpanId are not present OTel SpanContext.

Currently it returns nil when OTel SpanContext is invalid - no valid traceId and SpanId:

if !bridgeSC.otelSpanContext.IsValid() {
return nil, ot.ErrSpanContextNotFound
}
return bridgeSC, nil

The reason is to support jaeger-debug-id use case in OTel when we are migrating from deprecated jaeger-client-go.

To quickly explain what jaeger-debug-id does: it allows users to send a inbound request with such jaeger-debug-id header present to enforce sampling without a parent span.
Screenshot 2023-03-31 at 6 32 57 AM

I can implement a custom propagator to extract the header in maybe TraceState in OTel SpanContext, and implement a custom sampler to detect if it is present in the TraceState to sample the span and to set the attribute.

The only blocker right now is the OpenTracing Bridge Extract method: it only returns a non-nil bridge Span Context when there OTel SpanContext is valid - traceId and SpanId are valid, so there is not way to pass the jaeger-debug-id info to the OTel tracer.Start().

Proposed Solution

Since the jaeger-debug-id is very specific to jaeger, and not general to OpenTracing. I am thinking about more generic way to solve it.

One approach I can think of is to make such change:

if !bridgeSC.otelSpanContext.IsValid() && !bridgeSC.otelSpanContext.isSampled {
	return nil, ot.ErrSpanContextNotFound
}

Then in my custom propagator, I can set the traceFlags to sampled when extracting jaeger-debug-id header.

Or

if !bridgeSC.otelSpanContext.IsValid() && bridgeSC.otelSpanContext.TraceState.Get("force.passthrough") == "" {
	return nil, ot.ErrSpanContextNotFound
}

Hope this request make sense. Thanks!

@ChenX1993 ChenX1993 added the enhancement New feature or request label Mar 31, 2023
@Kaushal28
Copy link
Contributor

Hi, can I pick this up?

@ChenX1993
Copy link
Contributor Author

Hi @Kaushal28,

Can I take this? Because we use jaeger-debug-id heavily on our side, and I will need to do some internal testings along with the OSS code change to make sure it can really work.

I am also doing the same thing on Java: open-telemetry/opentelemetry-java#5339

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
2 participants