New Component: Datadog Propagator

[MovieStoreGuy]

Problem Statement

Datadog have their own tracing standard provides a similar functionality that is expected of any W3C compliant tracing implementation. The only problem is they use custom headers for their tracing standard and it is not currently possible to use Otel instrumentation and work with datadog instrumented applications.

Proposed Solution

Add a new propagator that is able to handle the datadog tracing specification.

Alternatives

There is no officially supported propagators developed by the otel community or datadog (that I saw) that would allow a user to natively use otel instrumentation.

Prior Art

There is existing propagators for other tracing standards such as X-Ray and Zipkin.

[dmathieu]

See https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/instrumentation#new-instrumentation

Why does this need to be a plugin in this repository? Can't Datadog provide that in their own organization?
Would you be code owner for that plugin (and writing it?) would there be a datadog employee owning that code?

[pellared]

Side note: Datadog propagation format is not even defined in https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md#general-sdk-configuration.

[jade-guiton-dd]

The Datadog docs state that:

By default, the Datadog SDK extracts and injects distributed tracing headers using the following formats:

• Datadog (takes higher precedence when extracting headers)
• W3C Trace Context
• Baggage

My understanding is that applications instrumented with OTel should be able to extract the W3C Trace Context, so they should be compatible with Datadog-instrumented applications that use the default SDK configuration, without needing to understand Datadog's propagation format.

Is there a use case where this doesn't work and where a new propagator on the OTel side would be required?

[MovieStoreGuy]

So the scenario that I have is a user that has services within their org instrumented with Datadog SDK and is sending the Datadog specific tracing headers to services that instrumented using the Otel SDK.

Currently it isn't possible to enable W3C compatible headers from the DD instrumented apps, so they want to accept the DD headers and not have to the current instrumentation to depend on datadog packages.

I personal just want to find the best solution for the user that addresses their concerns, and felt it would be best host in a neutral, equal opportunity project instead of my personal space.

[jade-guiton-dd]

Currently it isn't possible to enable W3C compatible headers from the DD instrumented apps

Assuming that by "DD instrumented" you mean "instrumented using the Datadog SDK": according to the documentation I linked above, injection of W3C trace context headers can be enabled using DD_TRACE_PROPAGATION_STYLE=tracecontext, and should in fact be enabled by default. Do you know of a scenario where this doesn't work?

[MovieStoreGuy]

Currently it isn't possible to enable W3C compatible headers from the DD instrumented apps

Assuming that by "DD instrumented" you mean "instrumented using the Datadog SDK": according to the documentation I linked above, injection of W3C trace context headers can be enabled using DD_TRACE_PROPAGATION_STYLE=tracecontext, and should in fact be enabled by default. Do you know of a scenario where this doesn't work?

This currently isn't possible for the user since they can not modify the currently running services.

[jade-guiton-dd]

This currently isn't possible for the user since they can not modify the currently running services.

As I said, it should be enabled by default, so they shouldn't need to modify anything. Are they stuck using an old version of the Datadog SDK where this isn't the case? If so, that could be a valid, albeit niche use case for a propagator on the OTel side.