Prometheus exporter handles instrumentation scope and prevents collisions

[dashpole]

Now that https://github.com/open-telemetry/opentelemetry-specification/pull/2703 is released, we can update the prometheus exporter to make use of OpenTelemetry scope, particularly for reducing collisions between metrics with the same name.

Describe the solution you'd like

There are a few components:

• Add otel_scope_name and otel_scope_version attributes to all metrics based on the instrumentation scope name and version.
• Add an otel_scope_info metric following https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#instrumentation-scope-1.
• Prevent collisions between TYPE, HELP, and UNIT comments following https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#metric-metadata-1

Note that the exporter SHOULD do the above by default, but may allow disabling the behavior.

[dashpole]

One additional consideration: The prometheus spec says:

All lines for a given metric must be provided as one single group, with the optional HELP and TYPE lines first (in no particular order). Beyond that, reproducible sorting in repeated expositions is preferred but not required, i.e. do not sort if the computational cost is prohibitive.

When name collisions between two metrics occur, and we handle that by combining the two metic groups (e.g. adopting one of the two descriptions), we have to make sure the metrics points for a given metric family are grouped together. For example, we might produce these metrics today, if we had a foo metric in two different scopes:

# TYPE foo gauge
# HELP foo help text a
foo{} 1
# TYPE bar gauge
# HELP bar another useless gauge
bar{} 1
# TYPE foo gauge
# HELP foo help text b
foo{} 1

This would not be valid per the prometheus spec. If we adopted the spec for instrumentation scope labels, and prevented duplicate type and descriptions, we would get:

# TYPE foo gauge
# HELP foo help text a
foo{otel_scope_name ="scope1", otel_scope_version ="1.2.3"} 1
# TYPE bar gauge
# HELP bar another useless gauge
bar{otel_scope_name ="scope1", otel_scope_version ="1.2.3"} 1
foo{otel_scope_name ="scope2", otel_scope_version ="1.2.3"} 1

But we still need to make sure the resulting metric lines are grouped by metric name like this:

# TYPE foo gauge
# HELP foo help text a
foo{otel_scope_name ="scope1", otel_scope_version ="1.2.3"} 1
foo{otel_scope_name ="scope2", otel_scope_version ="1.2.3"} 1
# TYPE bar gauge
# HELP bar another useless gauge
bar{otel_scope_name ="scope1", otel_scope_version ="1.2.3"} 1

[XuanWang-Amos]

Hi @dashpole, has this feature been implemented yet?

[dashpole]

not that i'm aware of

[XuanWang-Amos]

Thanks for the reply, is there any plans to implement this? I'm from gRPC team and working on Python OpenTelemetry integration, without those labels Python will fail our interoperability tests.