-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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/prometheusexporter] Handle units in prometheus metric names #8950
Comments
Is this ever going to be implemented? I think it's a very important feature to make sure metric naming conventions are followed on both OpenTelemetry and Prometheus. But when this will be implemented, it will be a breaking change on the receiving end! (think of a Grafana dashboard relying on Otel metrics named after the Otel metrics convention, that would suddenly break once this is merged into the collector). So, this is the kind of change that needs to be implemented as soon as possible, to break as few things as possible. |
Yes, this will definitely be implemented eventually, and I agree with the urgency. It is just a matter of people having time to do the work. You can see the full set of prom-spec items here: https://github.com/open-telemetry/opentelemetry-collector-contrib/issues?q=is%3Aopen+label%3Acomp%3Aprometheus+label%3Aspec%3Ametrics+ |
At some point, my company will need this feature in prometheusexporter so we'll probably give it a try. However, I'm concerned with the many edge cases where appending Otel metrics will have adverse effects (when the metric name already contains the unit, or when the unit is a long string, etc.) |
…metrics to follow Prometheus naming convention * Updated **prometheusremotewriteexporter** to normalize metric names * Moved common code to new module /pkg/translator/prometheus * Added documentation
…rometheus naming convention (#10028) * Issue #8950 `prometheusexporter`: Automatic rename of metrics to follow Prometheus naming convention * Updated **prometheusremotewriteexporter** to normalize metric names * Moved common code to new module /pkg/translator/prometheus * Added documentation Co-authored-by: Dan Jaglowski <[email protected]>
Prometheus exporters have been modified to append the unit (and Now, we only need to update prometheusreceiver to do the reverse normalization! |
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 |
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 |
Is this still on? |
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 |
Any reason why this isn't fix? It basically breaks a ton of dashboards and I'd really like to avoid recreating them :§ |
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 |
…4256) **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 the`pkg.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
…24260) **Description:** Add add_metric_suffixes configuration option, which can disable the addition of type and unit suffixes. This is backwards-compatible, since the default is true. This is recommended by the specification for sum suffixes in https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#sums and allowed in metadata https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#metric-metadata-1: `Exporters SHOULD provide a configuration option to disable the addition of _total suffixes.` `The resulting unit SHOULD be added to the metric as OpenMetrics UNIT metadata and as a suffix to the metric name unless the metric name already contains the unit, or the unit MUST be omitted` This deprecates the BuildPromCompliantName function in-favor of BuildCompliantName, which includes the additional argument for configuring suffixes. **Link to tracking Issue:** Fixes #21743 Part of #8950 --------- Co-authored-by: Dmitrii Anoshin <[email protected]>
Fixed by #25887 |
After open-telemetry/opentelemetry-specification#2440, prometheus exporters must add units to as a suffix to the metric name (before type suffixes), and the prometheus receiver must trim a unit suffix after trimming type suffixes. I.e.:
is broken down into OTLP
The text was updated successfully, but these errors were encountered: