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

Support restarting the trace with a different trace ID #1188

Open
yurishkuro opened this issue Nov 3, 2020 · 1 comment
Open

Support restarting the trace with a different trace ID #1188

yurishkuro opened this issue Nov 3, 2020 · 1 comment
Labels
area:sdk Related to the SDK release:after-ga Not required before GA release, and not going to work on before GA spec:trace Related to the specification/trace directory

Comments

@yurishkuro
Copy link
Member

What are you trying to achieve?

When SaaS products from cloud providers participate in the tracing, the providers are often reluctant to respect customer-supplied trace ID because it can be abused by the caller (e.g. sending the same trace ID for all requests). W3C trace context explicitly allows nodes in the call graph to restart a trace with a new trace ID, and return it to the caller via the response header (currently in the design phase). However, the current OTEL SDK spec states that the tracer must always respect & reuse the inbound trace ID.

OTEL SDK may support a configurable mechanism to restart a trace. The inbound SpanContext in this case can still be recorded as a Link to external trace.

Additional context.

Previous discussion here: #998 (comment)

Alternatives.

The behavior may also be implemented purely on the instrumentation side, e.g.

spanCtx := extract(request)
var span Span
if trusted(request) {
    span = tracer.StartSpan(parent=spanCtx)
} else {
    span = tracer.StartSpan(links=[spanCtx])
}

If OTEL Spec Committee decides not to support this directly in the SDKs, then the use case should be documented in some FAQ.

@yurishkuro yurishkuro added area:sdk Related to the SDK spec:trace Related to the specification/trace directory labels Nov 3, 2020
@andrewhsu andrewhsu added the release:after-ga Not required before GA release, and not going to work on before GA label Nov 6, 2020
@dyladan
Copy link
Member

dyladan commented Nov 10, 2020

The response header format is not near ready for implementation. The basic fields and data format is not yet agreed on. I would strongly recommend against implementing anything based on it yet.

As far as restarting the trace, this could be a useful feature for some people and should be fairly straightforward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:sdk Related to the SDK release:after-ga Not required before GA release, and not going to work on before GA spec:trace Related to the specification/trace directory
Projects
None yet
Development

No branches or pull requests

3 participants