Add 'translation_strategy' to PrometheusMetricExporter

[ArthurSens]

Fixes #261

This PR adds a new configuration option to control how PrometheusMetricExporters expose Prometheus metrics—complying with the spec change open-telemetry/opentelemetry-specification#4533. This new option is meant to replace the already existing options without_units and without_type_suffix, while adding extra control over whether UTF8 characters should be exposed or replaced with underscores.

[ArthurSens]

The big doubt here is how to proceed with deprecating the existing configuration. The OTel collector already uses the PrometheusMetricExporter schema, so removing those options would mean breaking the Collector configuration. At the same time, the PrometheusExporter schema is marked as experimental... so not sure if there is a concept of "Deprecation" here.

[ywwg]

Per the OTEL spec SIG, we can mark as deprecated but cannot reasonably remove the old options. We can make sure to emphasize the new options in docs etc, but will have to keep supporting the old code ~forever.

[ArthurSens]

Hmmm, I'm not sure if the CI failures are related to my changes. I'm assuming they are not 🤔

[zeitlinger]

Hmmm, I'm not sure if the CI failures are related to my changes. I'm assuming they are not 🤔

No, I have the same error - I'll see if I can fix that

[ywwg]

github link checker often fails due to timeouts, I see that all the time

[zeitlinger]

github link checker often fails due to timeouts, I see that all the time

this was the fix #276

[ArthurSens]

Hi folks, anything I could do here to enable the merge?

[zeitlinger]

This PR is failing because lychee is not pinned

@trask can you add the new lychee setup in this repo?

@codeboten you can ignore the link checker errors for this PR

[codeboten]

Thanks @ArthurSens, the collector can move to these new options behind a feature gate as per the breaking change policy for the collector https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/coding-guidelines.md#end-user-impacting-changes

[zeitlinger]

Feedback from meeting: This PR can already remove the options instead for deprecating, since the collector isn't using this schema.

[ArthurSens]

Feedback from meeting: This PR can already remove the options instead for deprecating, since the collector isn't using this schema.

I'm not sure if I'm missing something, but I'm almost sure it is 🤔.

otelconf, is the go implementation of the spec maintainer here, right? And otelconf is used to build the configuration file of otel-collector:

https://github.com/open-telemetry/opentelemetry-collector/blob/b2ac3f5e1d2bf8a4db9be21d5d34ebf83c3cb5ad/service/telemetry/otelconftelemetry/sdk.go#L9

[MrAlias]

Feedback from meeting: This PR can already remove the options instead for deprecating, since the collector isn't using this schema.

I'm not sure if I'm missing something, but I'm almost sure it is 🤔.

otelconf, is the go implementation of the spec maintainer here, right? And otelconf is used to build the configuration file of otel-collector:

https://github.com/open-telemetry/opentelemetry-collector/blob/b2ac3f5e1d2bf8a4db9be21d5d34ebf83c3cb5ad/service/telemetry/otelconftelemetry/sdk.go#L9

It isn't otelconf, but otelconf/v0.3.0 that is being used by the collector. That package is not going to change based on these changes. There will be a new otelconf/v1.0.0 (or similarly named) that will contain the changes being introduced here. When the collector upgrades to that different package it can translate to this new configuration definition or itself handle a migration path for its configuration that will match.

The two configurations (this and the collectors) are decoupled and this change will not break the collector's. This was confirmed by @codeboten, the author of most of otelconf and the collector configuration.

[codeboten]

The two configurations (this and the collectors) are decoupled and this change will not break the collector's. This was confirmed by @codeboten, the author of most of otelconf and the collector configuration.

Just confirming this, the configuration schema as provided by otelconf was already decoupled in the migration from v0.2.0 to v0.3.0 to support the breaking changes there. The same path can be taken when migrating from v0.3.0 to v1.0.0-rc2 with the breaking changes in this PR.

As discussed in the meeting yesterday, my opinion is that it's better to remove the options now, rather than releasing a 1.0 already including deprecated options.

[ArthurSens]

Alright, thanks for the explanation! Let me update the PR