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

Prometheus spec: Clarify naming of target_info #3700

Closed
dashpole opened this issue Sep 21, 2023 · 2 comments · Fixed by #3871
Closed

Prometheus spec: Clarify naming of target_info #3700

dashpole opened this issue Sep 21, 2023 · 2 comments · Fixed by #3871
Assignees
Labels
spec:miscellaneous For issues that don't match any other spec label

Comments

@dashpole
Copy link
Contributor

What are you trying to achieve?

The current specification for converting between prometheus' target info metric and otel resource mixes up target_info (gauge) and target (info), and always refers to the metric as "target_info" without properly distinguishing between the OM and Prom versions:

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#resource-attributes-1

The reason for the confusion is that the metric differs between OpenMetrics and Prometheus.

OpenMetrics

Source in OpenMetrics specification:
https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#supporting-target-metadata-in-both-push-based-and-pull-based-systems

# TYPE target info
# HELP target Target metadata
target_info{env="prod",hostname="myhost",datacenter="sdc",region="europe",owner="frontend"} 1

Prometheus

In promethues, the metric name always matches the series name for gauges (comments like TYPE and HELP match the metric name). "Info" metrics are a naming convention, rather than a separate type, where the metric has an "_info" suffix and a constant value of 1.

# TYPE target_info gauge
# HELP target_info Target metadata
target_info{env="prod",hostname="myhost",datacenter="sdc",region="europe",owner="frontend"} 1

@open-telemetry/wg-prometheus

@rapphil
Copy link

rapphil commented Sep 21, 2023

What is being proposed or the desired behaviour?

It feels that target_info and scope_info should be of type gauge so that consumers of a prometheus endpoint know how to read those metrics.

Using a metric type that is not included in the list of types prometheus documents creates friction.

@dashpole
Copy link
Contributor Author

We should use the types which are appropriate for the protocol. For OpenMetrics, we should follow the OpenMetrics specification, which currently requires the use of an info-typed metric named target.

I am proposing clarifying the language in the specification, not changing it.

jsuereth added a commit that referenced this issue Mar 14, 2024
…fo metric naming (#3871)

Fixes
#3700

## Changes

The current specification mixes OpenMetrics and Prometheus in ways that
can be confusing. This change first explains the differences between
various Prometheus formats, and then consistently uses "Prometheus" to
refer to the general conversion rules. This is helpful for explaining
why the target (info) metric naming differs depending on the format
used.

Also, fix references to the "target" info-typed metric, which was
previously referred to as "target_info". "target_info" is only used when
info-typed metrics are not supported.

---------

Co-authored-by: Yuri Shkuro <yurishkuro@users.noreply.github.com>
Co-authored-by: Eero Tamminen <eero.t.tamminen@intel.com>
Co-authored-by: Robert Pająk <pellared@hotmail.com>
Co-authored-by: Anthony Mirabella <a9@aneurysm9.com>
Co-authored-by: Josh Suereth <joshuasuereth@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:miscellaneous For issues that don't match any other spec label
Projects
None yet
3 participants