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

New component: Datadog Semantic Processor #35304

Open
2 of 3 tasks
IbraheemA opened this issue Sep 19, 2024 · 3 comments
Open
2 of 3 tasks

New component: Datadog Semantic Processor #35304

IbraheemA opened this issue Sep 19, 2024 · 3 comments
Assignees
Labels
Accepted Component New component has been sponsored never stale Issues marked with this label will be never staled and automatically removed

Comments

@IbraheemA
Copy link
Contributor

IbraheemA commented Sep 19, 2024

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

receivers:
  otlp:
    protocols:
      http:
      grpc:
processors:
  datadogsemantics:
exporters:
  debug:
  datadog:
        # ...

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [datadogsemantics]
      exporters: [datadog]
    traces/debug:
      receivers: [otlp]
      processors: [datadogsemantics]
      exporters: [debug]

Telemetry data types supported

Traces, metrics, and logs

Is this a vendor-specific component?

  • This is a vendor-specific component
  • If this is a vendor-specific component, I am a member of the OpenTelemetry organization.
  • If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.

Code Owner(s)

@IbraheemA

Sponsor (optional)

@songy23

Additional context

No response

@IbraheemA IbraheemA added needs triage New item requiring triage Sponsor Needed New component seeking sponsor labels Sep 19, 2024
@dmitryax
Copy link
Member

@songy23 will you sponsor this component?

@songy23
Copy link
Member

songy23 commented Oct 1, 2024

I sponsor!

@songy23 songy23 added Accepted Component New component has been sponsored and removed Sponsor Needed New component seeking sponsor needs triage New item requiring triage labels Oct 1, 2024
Copy link
Contributor

github-actions bot commented Dec 2, 2024

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

@github-actions github-actions bot added the Stale label Dec 2, 2024
@songy23 songy23 added never stale Issues marked with this label will be never staled and automatically removed and removed Stale labels Dec 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Component New component has been sponsored never stale Issues marked with this label will be never staled and automatically removed
Projects
None yet
Development

No branches or pull requests

3 participants