Currently the way in which OpenTelemetry semantics are mapped to those in Datadog is documented, but it is hard to observe the output of this mapping before it is shipped to Datadog since it is executed by the datadogexporter. This is problematic because users are often confused by the logic or wish to override it.
Rather than silently mapping over OpenTelemetry semantics to Datadog semantics in our datadogexporter we will provide a datadogsemanticsprocessor that performs the same mapping explicitly within the context of OpenTelemetry signals and namespaces the result under datadog.
This work will also involve modifying datadogexporter to expect signals in the new format.
The purpose and use-cases of the new component
Currently the way in which OpenTelemetry semantics are mapped to those in Datadog is documented, but it is hard to observe the output of this mapping before it is shipped to Datadog since it is executed by the datadogexporter. This is problematic because users are often confused by the logic or wish to override it.
Rather than silently mapping over OpenTelemetry semantics to Datadog semantics in our datadogexporter we will provide a datadogsemanticsprocessor that performs the same mapping explicitly within the context of OpenTelemetry signals and namespaces the result under
datadog.
This work will also involve modifying
datadogexporter
to expect signals in the new format.Example configuration for the component
Telemetry data types supported
Traces, metrics, and logs
Is this a vendor-specific component?
Code Owner(s)
@IbraheemA
Sponsor (optional)
@songy23
Additional context
No response