OTLP: Add configuration parameters to control label name translation#17345
Merged
aknuds1 merged 1 commit intoOct 22, 2025
Merged
Conversation
aknuds1
requested review from
bwplotka,
cstyan,
jesusvazquez and
tomwilkie
as code owners
October 16, 2025 15:09
aknuds1
force-pushed
the
arve/add-otlptranslator-params-with-config
branch
from
October 17, 2025 10:43
1588af8 to
d92a808
Compare
aknuds1
marked this pull request as draft
October 17, 2025 10:48
aknuds1
marked this pull request as ready for review
October 17, 2025 10:54
aknuds1
force-pushed
the
arve/add-otlptranslator-params-with-config
branch
2 times, most recently
from
October 17, 2025 11:23
35eb4df to
72bf5d3
Compare
As a follow-up to prometheus#17344, add two configuration parameters for controlling label name translation, both defaulting to on for backwards compatibility (currently these behaviours are hardcoded as enabled): * otlp.label_name_underscore_sanitization => Prefix label names starting with a single underscore with key_ when translating OTel attribute names * otlp.label_name_preserve_multiple_underscores => Keep multiple consecutive underscores in label names when translating OTel attribute names Signed-off-by: Arve Knudsen <[email protected]>
aknuds1
force-pushed
the
arve/add-otlptranslator-params-with-config
branch
from
October 17, 2025 11:26
72bf5d3 to
d28bb7e
Compare
ArthurSens
approved these changes
Oct 20, 2025
ArthurSens
left a comment
ArthurSens
left a comment
Member
There was a problem hiding this comment.
LGTM
One single comment, the configuration option label_underscore_sanitization could probably be renamed to something closer to its behavior. We're inheriting that naming in otlptranslator because we aimed for it to be used by OTel Collector;s feature gate "DropSanitization", that already existed before we started working on otlptranslator.
This name might not be easy to understand from a Prometheus user perspective, but I'm also failing to come up with better naming 😅. Anyways, I'm not gonna block the PR because of this.
Any other suggestions @ywwg ?
ywwg
approved these changes
Oct 20, 2025
ywwg
left a comment
ywwg
left a comment
Member
There was a problem hiding this comment.
I think the name is fine esp when coupled with the explanation. Lgtm
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
As a follow-up to #17344, add two configuration parameters for controlling label name translation, both defaulting to on for backwards compatibility (currently these behaviours are hardcoded as enabled):
otlp.label_name_underscore_sanitization=> Prefix label names starting with a single underscore withkey_when translating OTel attribute namesotlp.label_name_preserve_multiple_underscores=> Keep multiple consecutive underscores in label names when translating OTel attribute namesWhich issue(s) does the PR fix:
Related to #17342, although that's in itself fixed already by #17344. This PR just makes the behaviour configurable.
Does this PR introduce a user-facing change?