Prometheus spec: Clarify naming of target_info

[dashpole]

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]

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]

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.