Skip to content

Please clarify tracestate construction #263

Closed
@falenn

Description

@falenn

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions