Closed yurishkuro closed 6 years ago
simultaneously copied historical context in https://github.com/TraceContext/tracecontext-spec/pull/18
Yuri, to answer your first question, I can think of a few scenarios where having an expected context format is beneficial:
There's likely other benefits that I've missed, but does what I've outlined above make sense?
Hi Morgan,
These are fine goals, but they are too high level imo to be able to draw a spec from. I.e. it's not useful to discuss what the values in the header mean without taking about that the receiving systems are expected to do with it. So far the specs only talks about the first part.
Let's take just the trace-id first. Assume my service is tracing-aware (not an LB/proxy). I can do two things with the trace-id:
I think we're taking about the second option here, but it's not stated explicitly and various comments on various threads implied other interpretations. Agreeing on a second option has certain implications already, like if we allow variable-length trace-ids, many Dapper-like systems won't be able to accommodate that without extending their internal data models and storage formats.
Then to continue, let's assume we handled the inbound trace-id one way or another, and we're making an outbound call. Again, several options:
Trace-Context
with the received trace-id and another (e.g. B3) with its own internal id For this part, I think we're talking about option 2 as well, but it's not stated explicitly.
Ahh, understood!
In my mind we're talking about the second option to each of the choices that you presented, as this enables pass-through scenarios, and the re-used instrumentation code scenario. Like you pointed out, there may also be scenarios where multiple headers are passed for compatibility purposes, though ideally this becomes less necessary more and more projects would adopt Trace-Context.
@adriancole since you already have #18 open, do you want to add this there (assuming that you agree, which I think that you do)?
I agree with how yuri stated this. I think the very least 2 is defined (or a required goal to define). Tacitly we discuss 1, which is real life problem.
Imho we need to explain 1 eventually and bear in mind always. It is important context (forgive the term) to relay transitional brown field suggestions. MS in their spec outline some guidance around this type of thing and we can too.
Iotw yes? What should we put down? I can spike a PR..
This one was created before we defined the W3C charter and is obsolete now
https://github.com/TraceContext/tracecontext-spec/blob/master/HTTP_HEADER_FORMAT.md#trace-context-http-header-format says