Prometheus: Allow changing metric names by default when translating from Prometheus to OpenTelemetry

[dashpole]

Changes

The current Prometheus -> OTel spec was written based on the needs of the Prometheus receiver. Prometheus/client_java recently released OTLP support by following the Prometheus -> OTel spec in the java prometheus client.

When the collector tried to trim suffixes by default in the Prometheus receiver (open-telemetry/opentelemetry-collector-contrib#21743), it broke a number of users, which is why the current language requires not changing metric names. However, in cases where OTLP export is "new", such as the java prometheus client, it may be acceptable to remove suffixes by default.

This changes the requirement to not alter metric names by default from a MUST to a SHOULD to make it a recommendation.

[dashpole]

@open-telemetry/wg-prometheus @fstab

[fstab]

Thanks a lot @dashpole.

[fstab]

Not sure if I have the rights to approve this, but LGTM :)

[pirgeo]

Would this also open the path for allowing a refactoring of metric names (e.g. implementing a NameTranslator or similar) that would replace underscores with dots or whatever else the user might want? Thinking about semantic conventions for example: if they are already collected in a "compatible" format in the Prom client, could they be exported directly in the dot-notation when exporting to an OTLP consumer? This is probably the wrong issue to discuss this, but I wonder if that is something that would be interesting to folks.

Edit: I see that the wording still explicitly calls out that this is mainly about trimming suffixes. I still wonder if there would be an interest to have metrics that map 1:1 onto OTel semantic conventions translated.

[dashpole]

@pirgeo I think whatever mechanism we land on for mapping prometheus names/labels to OTel names/labels, it should live outside of the prometheus exporters/receivers themselves. I could see schemas potentially solving that problem, as they define a mapping from one naming convention to another.