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

Please clarify tracestate construction #263

Closed
falenn opened this issue Mar 19, 2019 · 3 comments
Closed

Please clarify tracestate construction #263

falenn opened this issue Mar 19, 2019 · 3 comments
Labels

Comments

@falenn
Copy link

falenn commented Mar 19, 2019

The concept of tracestate construction is not clear. Is tracestate conceptually constructed with each new span (Span.kind:SERVER) or translated / populated from headers?

Tracestate as upstream tracing system's format representation:
Following #57, #58 #80 #81 #88 #123 #158 Provide vendor/open source product name register for tracestate ,https://github.com/w3c/trace-context/blob/master/spec/20-http_header_format.md is pretty clear in its usage as original traceparent format capture, but what is not clear is "who" created the correct wire-format for downstream system traceparent consumption given the scenario where there are different tracing systems. In the example, it is assumed (or this is my current mental-model) that the upstream client created the correct header format for the downstream system but then also includes the traceparent data in OpenTracing's traceparent header in version-format 00 AND stores its own format in tracestate.

I'd like to conclude with my interpreted summary that tracestate is traceparent provenance with native format.

Here is my confusion - What actor is supposed to create the tracestate? If tracestate includes the various trace systems encountered during a trace, then each new encounter with a different trace vendor requires the opportunity to inject an entry into tracestate. Is this correct? How do we avoid tracestate from becoming "baggage?" Do we register with the tracer its vendor type and with a potential client the downstream tracer vendor type?

@SergeyKanzhelev
Copy link
Member

@falenn the best way to discourage the use of tracestate as a baggage is an aggressive limits of it. Also it's ordered and values will pop out of it as it grow bigger. So you will mostly store small and non-critical values there.

As we are working on correlation-context - once that spec complete you will have a better place for user-defined properties. Which is more comfortable as it has higher limits and more chances to be propagated untouched.

@falenn
Copy link
Author

falenn commented Mar 26, 2019

@SergeyKanzhelev can you provide a link to anything on correlation-context in development? I'm interested in seeing where that is at. Thanks!

@falenn falenn closed this as completed Mar 26, 2019
@SergeyKanzhelev
Copy link
Member

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

No branches or pull requests

2 participants