[exporter/prometheus] Implement Prometheus translation strategies.

[ArthurSens]

Is your feature request related to a problem? Please describe.

Prometheus is introducing support to UTF-8 characters in its newest releases:

• 2.55.0 has UTF-8 support behind a feature-flag.
• 3.0.0 has UTF-8 characters enabled by default.

This introduces an opportunity here. prometheusexporter could expose metrics as they are, without need for translations.

Describe the solution you'd like

If the collector receives metrics from an app instrumented with Prometheus SDKs (no utf-8, units already as suffixes), just expose them as they come.

If the collector receives metrics from an app instrumented with OTel SDK (with utf-8 and no suffixes), again just expose them as they come!

For backward compatibility with Prometheus versions < 2.55.0, the exporter should add a config option to continue translating to the old format! Prometheus has configuration options for this, called otlp.translation_strategy, so let's do the same to keep configurations consistent.

Additional context

To allow UTF-8 characters, content negotiation needs to be done by the scraper (usually Prometheus) via the Accept Header: escaping=allow-utf-8. The exposition format is handled by one of our dependencies: prometheus/common, and we're already in the latest version so things will ✨ just work ✨!

All we need to do is just stop translating metrics :)

---

Blocked on: open-telemetry/opentelemetry-specification#4494

The otel specification is being updated to clarify exactly how these modes should be selected and how they should operate.

[github-actions]

Pinging code owners:

• exporter/prometheus: @Aneurysm9 @dashpole

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[dashpole]

Triaged. This is definitely the direction we want to go. The changes will be similar to open-telemetry/opentelemetry-go#5755.

[dashpole]

We could consider adding a feature gate to allow users to globally change model.NameValidationScheme to model.UTF8Validationfrommodel.LegacyValidation` (current default).

[ArthurSens]

We could consider adding a feature gate to allow users to globally change model.NameValidationScheme to model.UTF8Validationfrommodel.LegacyValidation` (current default).

If we use a feature-gate, that means that eventually the gate will disappear and users will never be able to disable UTF-8. Is that our intention here? I'm a bit concerned with keeping this exporter working for users who are stuck with Prometheus < 2.55.0 for whatever reason 🤔

[dashpole]

My understanding is that it will continue to be possible to disable UTF-8 using content negotiation. I'm not sure if we need to continue supporting disabling it from the client side.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• exporter/prometheus: @Aneurysm9 @dashpole @ArthurSens

See Adding Labels via Comments if you do not have permissions to add labels yourself.