Please clarify tracestate purpose

[falenn]

I would like to add custom tracking info to tracestate, however, I'm afraid this would violate the intent of the spec.

1. https://github.com/w3c/trace-context/blob/master/spec/20-http_header_format.md communicates to me that tracestate is traceparent provenance in native tracer system format.

2. https://github.com/w3c/trace-context/blob/fa851a7b31858c7e67ed2fbedcbc43a5447673f6/spec/30-processing-model.md communicates to me that tracestate is mutable. Not only are the entry positions mutable, in the sense that a new tracer format is inserted at the front of the entry list, but the comment:

6. Tracing System modifies the tracestate header
   Update key value. The value of any key can be updated. Modified keys MUST be moved to the beginning of the list. This is the most common mutation resuming the trace.

makes it sound like tracestate is baggage. I'm confused. Can you please clarify?
Thanks!

[yurishkuro]

Baggage is the provenance of the application developer. Tracestate is only changed by the tracing library, not the application. Mutability is irrelevant in this case (all headers are mutable as they pass through the application).

[falenn]

--- Just edited this comment. @yurishkuro Thanks for the clarification. The issue I'm working has downstream systems (using the same tracer library) wanting to make sampling decisions based on upstream callers (using the same tracing library) to throttle their sampling rate to avoid load issues. I can accomplish this through analyzing headers, but even better, can optimize by looking for and adjusting sampling based on an expected system-id. Better yet, I could leverage an existing header to place this id into rather than add another header. Since this would be a requirement of all participating tracer instances, I started looking at decorating the tracestate with this id.

In your opinion, is this an abuse of tracestate? I want a conventional way to distinguish service affiliation with system instances throughout the enterprise.

[yurishkuro]

This is an interesting question and has to do with your role.

1. If you are the author of the tracing library, then passing extra data in tracestate is perfectly reasonable
2. If you're using a 3rd party tracing library, then strictly speaking you should not be messing with tracestate and instead use correlation-context. However, it sounds like you can be classified as an "infrastructure developer" (not the end application developer), and your role is to provide tracing capabilities across many services, by creating shared middleware that also affects how the tracing library behaves (the sampling strategy). For the purposes of your company you are the author of the (tracing library + middleware) combination, and can potentially use tracestate to record common extra data. It's a bit of a gray area in the spec. The main issue is that you'd have to introduce a new vendor key in the tracestate for your extra data, because the 3rd party tracing library will already have its own vendor key with a bespoke format.

[SergeyKanzhelev]

@falenn please close the issue if you found your answer =).

[falenn]

Thank you for the clarification. @SergeyKanzhelev, thanks for the label.
Like the intent of opentracing/specification#86, I'd really like to "fit" instance-identifying information into the tracestate for downstream throttling (like adaptive sampling). If possible, I would like to not mandate extra headers or unwarranted impedance that appliances or service meshes won't expect (of course, this is selfish.)

[SergeyKanzhelev]

@falenn as @yurishkuro said - your use of tracestate looks legit.

[falenn]

@SergeyKanzhelev - this is what I'm looking for https://github.com/w3c/correlation-context/tree/master/correlation_context - This would allow a downstream system instance identifying information of the upstream system to perform throttling without overloading the essence of tracestate, particularly when both instances are of the same vendor.