Closed povilasv closed 10 months ago
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself.
Thanks for filing @povilasv, and for including all of the references! Agreed that this is a bug.
I don't have much context with the Datadog APM .NET Client Libraries
repo, but is it connected to OpenTelemetry (or supposed to match the OTEL semantic conventions)? If so, could you also file an issue against that repository as well to let them know it's not matching the spec? It's good to handle this case in our repo either way, but the source of the issue should also be addressed if it's not aligning with a spec it's supposed to line up with.
I don't think the Datadog APM .NET Client Libraries
is connected to OpenTelemetry, they use their own data model and protobufs and send the data, we receive it via datadodreceiver and transform to Otel.
So I don't think it makes sense to ask Datadog folks to change some header
Component(s)
receiver/datadog
What happened?
Description
Looks like DataDog's library uses ".NET" as value instead of "dotnet" in their instrumentation:
See: https://github.com/DataDog/dd-trace-dotnet/blob/ecb5d5949f6c29dbe99a451c7a3574013cfeb1bd/tracer/src/Datadog.Trace/AgentHttpHeaderNames.cs#L76
So we need to remap ".NET" to "dotnet" to follow OTEL semantic conventions.
I've also doublechecked other variables, and they seem to map to semantic conventions correctly -> https://opentelemetry.io/docs/specs/semconv/resource/#telemetry-sdk
The only other odd language is javascript. DD uses "javascript" in their instrumentation -> https://github.com/search?q=repo%3ADataDog%2Fdd-trace-js%20Datadog-Meta-Lang&type=code
But we don't seem to have equivalent in semantic conventions?
Steps to Reproduce
Expected Result
Actual Result
Collector version
v0.89.0
Environment information
Environment
OS: (e.g., "Ubuntu 20.04") Compiler(if manually compiled): (e.g., "go 14.2")
OpenTelemetry Collector configuration
No response
Log output
No response
Additional context
No response