You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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#158Provide 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?
The text was updated successfully, but these errors were encountered:
@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.
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?
The text was updated successfully, but these errors were encountered: