Perhaps compile-time flag might be safer for testing (as discussed internally with @owen-d e.g. build tag)

wrong owen :) (I'm @ywwg for extremely historical reasons)

compile-time flag

Do you think that approach has a good chance of being accepted? Every other experimental feature uses the feature flag infrastructure so this would be a totally new infrastructure for enabling features and I would hate to do the work and then have it be rejected.

compile-time flag

Do you think that approach has a good chance of being accepted? Every other experimental feature uses the feature flag infrastructure so this would be a totally new infrastructure for enabling features and I would hate to do the work and then have it be rejected.

If I am not wrong this approach has been used before for stringlabels https://prometheus.io/blog/2023/03/21/stringlabel/.

Yes, we have precedence with stringlabels and deduplabels and a positive feedback on Slack discussion on this approach here (:

Opting in to this would break existing dashboards and rules, which is a problem for folks who generally want no-translation but are already using the existing translation.

I can see options:

• Allow to configure for certain metrics (e.g. a matcher), so they can cut over gradually.
• Generate both translated and not-translated versions (i.e. doubling cardinality).
• Fix it query-side (which has been discussed before and generally found to be too hard).

For renaming, we will be speaking about some way in https://kccnceu2025.sched.com/event/1txHv/how-to-rename-metrics-without-impacting-somebodys-observability-bartlomiej-plotka-google-arianna-vespri-independent?iframe=no with @vesari ;p

Here is the issue where we discussed doing the migration on the query side and decided it was too complex and "magical" -- #13765

I like the idea of gradual cutover, though we would need to think about how to manage the performance

I can see options:

• Allow to configure for certain metrics (e.g. a matcher), so they can cut over gradually.

Can we introduce that without making breaking changes to the current configuration file? We currently have the following structure

otlp:
  translation_strategy: NoTranslation | UnderscoreEscapingWithSuffixes | NoUTF8EscapingWithSuffixes

How could we introduce matchers to this?

• Generate both translated and not-translated versions (i.e. doubling cardinality).

That sounds an even bigger problem because doubling cardinality could lead to Prometheus crashing. Your dashboard will also break if Prometheus isn't running 😅

• Fix it query-side (which has been discussed before and generally found to be too hard).

Yep...

I agree that the switch from translation to noTranslation won't be 100% smooth, but isn't updating dashboards the easiest task here?

@bboreham Otel's Prometheus working group had a meeting and we came up with the following proposed positions:

• Metric name migration is a general prometheus problem that can be triggered by any number of infrastructure changes, of which changing this flag is just one. We believe accommodation of metric name migration is out of scope for this particular feature, and in general we'll add language and warnings to the effect of, changing this flag on an existing system will change metric names and cause breakage
• Default dashboards and alerts will indeed need to be updated to support these new names, but we also believe that this feature should not be blocked on the non-existence of those dashboards. That seems to us to be a bit putting the cart before the horse. We do agree that companies would not want to opt-in new customers on no-translation mode without such updates.

So, tl;dr, we'd like to move ahead on implementing the feature and then fork off two new issues: consideration of metric name migration, and updating stock dashboards and alerts for the new names.

closing in favor of @ArthurSens 's work