Tracker: Stabilize prometheus compatibility specification

[dashpole]

This is a tracker for stabilizing this specification, which is currently experimental: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md

There are currently three compliant SDK implementations, per the compliance matix: Go, Java, Rust.

The prometheus receiver is compliant as well: open-telemetry/opentelemetry-collector-contrib#25865

Here are the open spec issues i'm aware of that block stability:

• Determine impact of Prometheus UTF-8 support on OTel compatibility #3736
• Prometheus Exporter: Copy Resource attributes into each time-series attributes #3705
• Prometheus spec: Clarify naming of target_info #3700
• prometheus: Remove namespace on attributes #3634
• Promethus Exemplar Compatibility #3325
• Reconsider modifying metric name with OTLP unit #2497
• Clarify timestamps should not be added in prometheus export and remove current references #2468

Notable non-blocking issues (additive changes):

• Prometheus spec: Should it be possible to disable target_info  #3702
• Prometheus Unknown MUST preserve its notion #3058
• Consider supporting additional OpenMetrics types to the datamodel #2409
• [Prometheus Compat] Figure out how to handle StateSet #1712
• Security in Prometheus exporter #2400

We should also verify that the prometheus and prometheusremotewrite collector exporters are compliant before stabilizing the specification.

Of the open issues, the Prometheus WG agreed today that #3736 is the primary blocker.

@open-telemetry/wg-prometheus @MrAlias @jmacd @jsuereth

[dashpole]

The prometheus exporter specification needs to be updated to clarify that it needs to follow the conversion specification.

[jack-berg]

Per the fully compliant java implementation: The java implementation currently does not serialize exponential histograms, so in incomplete in at least some sense. When I look at the prometheus exporter doc, it doesn't actually link / reference the prometheus compatibility document. This leads the definition of a "compliant" implementation ambiguous. Should update the prometheus exporter document to link to the prometheus compatibility document, and update the prometheus compatibility doc to indicate which portions of the OTLP Metric to prometheus are required for SDK exporters.

[dashpole]

@jack-berg Re: exponential histograms, i've tried to address that in #3872. The basic idea is that exporters should be required to support the text format. But since the text format doesn't support exponential histograms, exporters won't initially be required to support them.

It also now links to the compatibility document.