I'd like to propose that we start the work of dropping the elastic-apm- prefix on our traceparent header + add support for tracestate. We have to add a transition period though. This issue is for discussion that 🙂
While TraceContext is not a finished standard yet, it's at it's final stage, Candidate Recommondation (CR), and require real-world usage from at least 3 APM vendors in order to become so. While I think there's already enough vendors pushing this so that we don't need to, I don't see any reason for us to hold back any longer. Hence this proposal.
Proposed plan
- On all incoming requests, our agents should look for both
elastic-apm-traceparent and traceparent. If both are present, but the values differ, the agent should prefer elastic-apm-traceparent over traceparent.
- On all outgoing requests, backend agents will always set
traceparent, and optionally set elastic-apm-traceparent; RUM agents will either set elastic-apm-traceparent or traceparent, due to CORS. This will be controlled by a new environment variable, described below.
- We will introduce a new config environment variable,
ELASTIC_APM_USE_ELASTIC_TRACEPARENT_HEADER, which will control the above behaviour. Its value will initially default to true, to ensure backwards compatibility with older agents. Later we will flip the default value to false, to phase out backwards compatibility. The configuration exists as an "escape hatch" for large/complex environments, but otherwise shouldn't be necessary.
- On all incoming requests, our agents should look for
tracestate and, based on the rules in the TraceContext spec, forward it to all outgoing requests. We currently don't need our agents to use this header for anything.
- Be aware that the incoming HTTP request can have more than one
tracestate header. Our agents should combine multiple incoming tracestate headers into one outgoing tracestate header.
Testing
@gregkalapos brought up that there's a bunch of compatibility tests we can run to ensure we support the spec correctly. It would be a good idea if we all added those to our CI in some way if possible:
https://github.com/w3c/trace-context/tree/master/test
What we are voting on
@elastic/apm-agent-devs Are you ok with moving forward with this plan?
@roncohen Please weigh in here if you have any objections.
Vote
I'd like to propose that we start the work of dropping the
elastic-apm-prefix on ourtraceparentheader + add support fortracestate. We have to add a transition period though. This issue is for discussion that 🙂While TraceContext is not a finished standard yet, it's at it's final stage, Candidate Recommondation (CR), and require real-world usage from at least 3 APM vendors in order to become so. While I think there's already enough vendors pushing this so that we don't need to, I don't see any reason for us to hold back any longer. Hence this proposal.
Proposed plan
elastic-apm-traceparentandtraceparent. If both are present, but the values differ, the agent should preferelastic-apm-traceparentovertraceparent.traceparent, and optionally setelastic-apm-traceparent; RUM agents will either setelastic-apm-traceparentortraceparent, due to CORS. This will be controlled by a new environment variable, described below.ELASTIC_APM_USE_ELASTIC_TRACEPARENT_HEADER, which will control the above behaviour. Its value will initially default totrue, to ensure backwards compatibility with older agents. Later we will flip the default value tofalse, to phase out backwards compatibility. The configuration exists as an "escape hatch" for large/complex environments, but otherwise shouldn't be necessary.tracestateand, based on the rules in the TraceContext spec, forward it to all outgoing requests. We currently don't need our agents to use this header for anything.tracestateheader. Our agents should combine multiple incomingtracestateheaders into one outgoingtracestateheader.Testing
@gregkalapos brought up that there's a bunch of compatibility tests we can run to ensure we support the spec correctly. It would be a good idea if we all added those to our CI in some way if possible:
https://github.com/w3c/trace-context/tree/master/test
What we are voting on
@elastic/apm-agent-devs Are you ok with moving forward with this plan?
@roncohen Please weigh in here if you have any objections.
Vote