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

prometheusreceiver: Add trim_metric_suffixes configuration option #24256

Merged

Conversation

dashpole
Copy link
Contributor

@dashpole dashpole commented Jul 13, 2023

Description:

Adds a new configuration option: trim_metric_suffixes to the prometheus receiver. When set to true, suffixes will be trimmed from metrics. This replaces use of thepkg.translator.prometheus.NormalizeName feature-gate in the prometheus receiver, but leaves it for exporters.

The first commit simplifies the usage of the feature-gate. The tests and implementation were passing around an entire registry when it wasn't necessary.

Link to tracking Issue:

Part of #21743
Part of #8950

Testing:

Unit tests.

Documentation:

Added to the README.

cc @gouthamve @dmitryax

@dmitryax
Copy link
Member

dmitryax commented Jul 14, 2023

Why do we need pkg.translator.prometheus.NormalizeName feature gate if it is controlled by config options now? Maybe we should just deprecate it as the first step? Keeping add_type_and_unit_suffixes disabled for some time on the exporter side would be the same as keeping pkg.translator.prometheus.NormalizeName in alpha the state, but maybe it's even unnecessary... It just seems a bit confusing having several controls for the same behavior.

@dashpole
Copy link
Contributor Author

The feature gate is useful if we still consider the feature alpha. Do you think we need to resolve #23208 before graduating it to beta?

If everyone agrees it is beta, we can remove it as part of adding the config options.

@dmitryax
Copy link
Member

Do you think we need to resolve #23208 before graduating it to beta?

#23208 is only about the receiver. Given that the option trim_metric_suffixes is off by default, it won't affect users unless they explicitly enable it. I think we can just mark the config option as experimental and subject to change until #23208 is resolved

@dashpole
Copy link
Contributor Author

That works for me. I'll update this to remove the feature gate from the receiver path.

@dashpole dashpole force-pushed the prometheus_normalization_config branch from 54117e2 to 80ae5c6 Compare July 14, 2023 16:02
@dashpole
Copy link
Contributor Author

dashpole commented Jul 14, 2023

@dmitryax done. I marked the config option experimental in the README.

@dashpole dashpole force-pushed the prometheus_normalization_config branch from cb34582 to e1631f8 Compare July 14, 2023 17:23
@dashpole
Copy link
Contributor Author

Fixed make tidy

Copy link
Member

@gouthamve gouthamve left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dmitryax dmitryax merged commit 5a975ab into open-telemetry:main Jul 17, 2023
89 checks passed
@github-actions github-actions bot added this to the next release milestone Jul 17, 2023
dmitryax added a commit that referenced this pull request Jul 21, 2023
…iguration options (#24257)

**Description:**

Fixes #24258

Found while adding documentation for
#24256.
The prometheus receiver had two config options that AFAICT have never
been used.

The config options have existed since the very first commit ever for the
Prometheus receiver:
7c728ef


Co-authored-by: Dmitrii Anoshin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants