-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Comments
@songy23 will you sponsor this component? |
I sponsor! |
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 |
#36918) …>DD trace semantics <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This PR introduces a new component, `datadogsemanticsprocessor`. See linked issue for more information. This first iteration only performs the semantic mapping for traces - logs and metrics will be added in followup PRs. Future versions will also add more attributes to the mapping. <!-- Issue number (e.g. #1234) or full URL to issue, if applicable. --> #### Link to tracking issue #35304 <!--Describe what testing was performed and which tests were added.--> #### Testing Ran unit tests, ran collector with datadogsemanticsprocessor in trace pipeline and verified that `datadog.` prefixed fields are outputted as expected. <!--Describe the documentation added.--> #### Documentation Added changelog. OTLP->DD semantic mappings are documented on [this public facing document.](https://docs.datadoghq.com/opentelemetry/schema_semantics/semantic_mapping/?tab=datadogexporter) <!--Please delete paragraphs that you did not use before submitting.--> --------- Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
Can someone clarify if this is a breaking change for 0.122.0? I see the component mentioned in the release notes: But it doesn't state what happens next. Are we required to use this processor when upgrading to 122, or is the exporter going to still support "the old format" for a while? I need to know this as we are preparing documentation for the 122 upgrade, and we need to know exactly what is the consequence of this change here. |
@julealgon it is still under development and is not ready for use. @IbraheemA will post updates (blog / announcement) once it is ready. |
Also to clarify: you are not required to use this processor even after it is ready. The old OTel -> DD way will continue to work. |
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
The text was updated successfully, but these errors were encountered: