Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Library instrumentation stays as Datadog in operation name (or Primary Operation). #30812

Closed
nicoroms opened this issue Jan 28, 2024 · 3 comments
Labels
bug Something isn't working data:traces Trace related issues exporter/datadog Datadog components needs triage New item requiring triage receiver/datadog

Comments

@nicoroms
Copy link

Component(s)

exporter/datadog, receiver/datadog

What happened?

Description

Traces receiver comes with InstrumentationScope Datadog 4.20.0 causing that datadog exporter create traces with Datadog instead of original library (like express, http, netty, etc). This change causes that backend recognize as original operation name.
image

And this happen in datadog traces view:
image

Metrics created in datadog are called with Datadog.server too
image

** span_name_as_resource_name on the exporter side seems to fix this behaviour on the traces, but metrics generated (like trace.express.request.hits) stay with the name trace.Datadog.server.hits, which is wrong.

Steps to Reproduce

Instrument app with datadog sdk and otlp collector with datadog receiver, any export to datadog will cause this

Expected Result

Instrumentation Scope should be the same as origin and not one created by datadog receiver or a config to keep the same behaviour of traces.span_name_as_resource_name in metrics.

Actual Result

Collector version

0.93.0

Environment information

Environment

OS: (e.g., "Ubuntu 20.04")
Compiler(if manually compiled): (e.g., "go 14.2")

OpenTelemetry Collector configuration

receivers:
  datadog:
    endpoint: ${POD_IP}:8126
    read_timeout: 60s
exporters:
  datadog:
    traces:
#      span_name_as_resource_name: true
    api:
      key: 

processors:
  batch:
    send_batch_max_size: 1000
    send_batch_size: 100
    timeout: 10s


extensions:
  health_check:

service:
  extensions: [health_check]
  pipelines:
    traces:
      receivers: [datadog]
      processors: [ batch]
      exporters: [datadog]

Log output

No response

Additional context

No response

@nicoroms nicoroms added bug Something isn't working needs triage New item requiring triage labels Jan 28, 2024
@github-actions github-actions bot added the exporter/datadog Datadog components label Jan 28, 2024
Copy link
Contributor

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@mx-psi
Copy link
Member

mx-psi commented Mar 8, 2024

Thanks for filing this @nicoroms. This is probably related to #1909 but I will keep this open until we verify this.

@mx-psi mx-psi added the data:traces Trace related issues label Mar 8, 2024
@mx-psi
Copy link
Member

mx-psi commented Mar 8, 2024

I am going to close this as a duplicate of #1909 indeed. This

** span_name_as_resource_name on the exporter side seems to fix this behaviour on the traces, but metrics generated (like trace.express.request.hits) stay with the name trace.Datadog.server.hits, which is wrong.

is not mentioned already on the original issue so I will highlight it in our internal tracking for this issue, but otherwise this is a particular manifestation of the general issue on #1909

@mx-psi mx-psi closed this as not planned Won't fix, can't repro, duplicate, stale Mar 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working data:traces Trace related issues exporter/datadog Datadog components needs triage New item requiring triage receiver/datadog
Projects
None yet
Development

No branches or pull requests

2 participants