[processor/datadogsemantics] Make defaults explicit and add test #39596
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
requested review from
ankitpatel96,
dineshg13,
jackgopack4 and
jade-guiton-dd
jackgopack4
suggested changes
Apr 23, 2025
There was a problem hiding this comment.
I would prefer if each attribute followed the same pattern as much as possible. If there is a way you can either set service variable explicitly prior to calling GetOTelService, or leave a comment above those lines explaining what service gets set to by default, that would be appreciated
| if err = tp.insertAttrIfMissingOrShouldOverride(rattr, "datadog.service", service); err != nil { | ||
| return ptrace.Traces{}, err | ||
| } | ||
| if err = tp.insertAttrIfMissingOrShouldOverride(rattr, "datadog.service", traceutil.GetOTelService(otelres, true)); err != nil { |
There was a problem hiding this comment.
am I understanding correctly that this change, if otelres is blank, then traceutil.GetOTelService will return "otlpresourcenoservicename" and that's what datadog.service will be set to?
https://github.com/DataDog/datadog-agent/blob/0d44e61fa623ef2572ba8d7fbe30e2632540d8aa/pkg/trace/traceutil/otel_util.go#L276
Worth adding a link to the function or noting the default setting in the comments here?
There was a problem hiding this comment.
alternatively, you could always make that an exportable constant in pkg/trace/traceutil and set service equal to the value before calling GetOTelService.
I just think we should try to have the pattern for each attribute follow a similar pattern to the maximum extent practical, so the code is easy to understand later
There was a problem hiding this comment.
Agreed, I added a comment explaining the default
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
jackgopack4
approved these changes
May 9, 2025
mx-psi
approved these changes
May 13, 2025
johnleslie
pushed a commit
to johnleslie/opentelemetry-collector-contrib
that referenced
this pull request
May 23, 2025
…n-telemetry#39596) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Explicitly set defaults for each field - whatever the Datadog backend would populate if you send the field as blank; e.g., if we send a blank env, it would show up in the UI as the string `default`, so we should surface that to the user with this processor. Also, populate `datadog.*` fields even if they would be blank (this includes overriding them even if the result would be blank if the `overrideIncomingDatadogFields` option is set, for consistency) <!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. --> #### Link to tracking issue Fixes <!--Describe what testing was performed and which tests were added.--> #### Testing <!--Describe the documentation added.--> #### Documentation <!--Please delete paragraphs that you did not use before submitting.--> --------- Co-authored-by: Pablo Baeyens <[email protected]>
johnleslie
pushed a commit
to johnleslie/opentelemetry-collector-contrib
that referenced
this pull request
May 23, 2025
…n-telemetry#39596) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Explicitly set defaults for each field - whatever the Datadog backend would populate if you send the field as blank; e.g., if we send a blank env, it would show up in the UI as the string `default`, so we should surface that to the user with this processor. Also, populate `datadog.*` fields even if they would be blank (this includes overriding them even if the result would be blank if the `overrideIncomingDatadogFields` option is set, for consistency) <!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. --> #### Link to tracking issue Fixes <!--Describe what testing was performed and which tests were added.--> #### Testing <!--Describe the documentation added.--> #### Documentation <!--Please delete paragraphs that you did not use before submitting.--> --------- Co-authored-by: Pablo Baeyens <[email protected]>
dragonlord93
pushed a commit
to dragonlord93/opentelemetry-collector-contrib
that referenced
this pull request
May 23, 2025
…n-telemetry#39596) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Explicitly set defaults for each field - whatever the Datadog backend would populate if you send the field as blank; e.g., if we send a blank env, it would show up in the UI as the string `default`, so we should surface that to the user with this processor. Also, populate `datadog.*` fields even if they would be blank (this includes overriding them even if the result would be blank if the `overrideIncomingDatadogFields` option is set, for consistency) <!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. --> #### Link to tracking issue Fixes <!--Describe what testing was performed and which tests were added.--> #### Testing <!--Describe the documentation added.--> #### Documentation <!--Please delete paragraphs that you did not use before submitting.--> --------- Co-authored-by: Pablo Baeyens <[email protected]>
dd-jasminesun
pushed a commit
to DataDog/opentelemetry-collector-contrib
that referenced
this pull request
Jun 23, 2025
…n-telemetry#39596) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Explicitly set defaults for each field - whatever the Datadog backend would populate if you send the field as blank; e.g., if we send a blank env, it would show up in the UI as the string `default`, so we should surface that to the user with this processor. Also, populate `datadog.*` fields even if they would be blank (this includes overriding them even if the result would be blank if the `overrideIncomingDatadogFields` option is set, for consistency) <!-- Issue number (e.g. #1234) or full URL to issue, if applicable. --> #### Link to tracking issue Fixes <!--Describe what testing was performed and which tests were added.--> #### Testing <!--Describe the documentation added.--> #### Documentation <!--Please delete paragraphs that you did not use before submitting.--> --------- Co-authored-by: Pablo Baeyens <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Explicitly set defaults for each field - whatever the Datadog backend would populate if you send the field as blank; e.g., if we send a blank env, it would show up in the UI as the string
default, so we should surface that to the user with this processor. Also, populatedatadog.*fields even if they would be blank (this includes overriding them even if the result would be blank if theoverrideIncomingDatadogFieldsoption is set, for consistency)Link to tracking issue
Fixes
Testing
Documentation