Skip to content

Time to fully support TraceContext #71

@watson

Description

@watson

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

  1. 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.
  2. 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.
  3. 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.
  4. 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

Agent Yes No Indifferent N/A Link to agent issue
.NET
elastic/apm-agent-dotnet#177
Go
elastic/apm-agent-go#503
Java
elastic/apm-agent-java#923
Node.js
elastic/apm-agent-nodejs#994
Python
elastic/apm-agent-python#628
Ruby
elastic/apm-agent-ruby#621
RUM
elastic/apm-agent-rum-js#477

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions