[exporter-prometheus] Implement Prometheus translation modes

[lucas-gregoire]

Hi team 👋,

The OpenTelemetry spec has recently evolved with PR #4533, introducing configuration options for Prometheus exporters to control how OTEL metrics should be mapped to Prometheus metric names and metadata (e.g., unit suffixes, naming conventions, UTF8 characters, etc.).

Previously, the mapping from OTEL metric names/units to Prometheus format was fixed, with some exporters not always matching emerging best practices or spec recommendations (notably unit suffix usage or abbreviation expansion).
This recent update offers explicit, exporter-side configuration to make mapping more consistent, controllable and interoperable for end users.

Feature Request

Implement the new translation_strategy configuration option as per spec PR #4533 in the JS Prometheus exporter:

- `UnderscoreEscapingWithSuffixes`, the default. This fully escapes metric names for classic Prometheus metric name compatibility, and includes appending type and unit suffixes.
- `UnderscoreEscapingWithoutSuffixes`, metric names will continue to escape special characters to `_`, but suffixes won't be attached.
- `NoUTF8EscapingWithSuffixes` will disable changing special characters to `_`. Special suffixes like units and `_total` for counters will be attached.
- `NoTranslation`. This strategy bypasses all metric and label name translation, passing them through unaltered.

[...]

Although a Prometheus Exporter MAY be configured with a `translation_strategy` for internal metric processing, the final output format and character escaping MUST follow what the content negotiation process determines based on the client's `Accept` header. The content negotiation requirements MUST take precedence over the configured translation strategy when determining the final output format.

Examples:

- If configured with `NoTranslation` but the client requests `escaping=underscores`, the exporter MUST apply underscore escaping.
- If configured with `UnderscoreEscapingWithSuffixes` but the client requests `escaping=allow-utf8`, there's no need to revert what has been translated since the exporter will continue to be compliant.

References

• Prometheus translation modes opentelemetry-specification#4533
• Update Prometheus spec based on new updates to UTF-8 and name translation in upstream Prometheus opentelemetry-specification#4494
• exporter/prometheus: Implement translation strategies opentelemetry-collector-contrib#41530
• exporters/prometheus: Migrate to the new configuration options opentelemetry-go#7083

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stale for 14 days with no activity.