Use the same default collector telemetry settings as upstream

[swiatekm]

We explicitly add a Prometheus metrics reader to the collector configuration if one is not present. We only set the endpoint, so the rest of the settings should use defaults. However, due to a recently fixed bug in the collector, this caused us to use non-default settings.

These settings control, among other things, the shape of the metrics data emitted by the collector, including the metric names. Changing this would be a significant breaking change. However, we should ultimately be aligned with collector defaults here.

The proposed solution here, as discussed during the SIG meeting on 05.05.2026, is:

• Set the other config values, so we keep the current behavior for 0.152.0. ( fix(collector): preserve Prometheus telemetry metric shape #5078)
• Introduce a feature gate to use the collector defaults instead. ( fix(collector): preserve Prometheus telemetry metric shape #5078)
• Flip the feature gate on in the following version and keep it around for a few versions - I'd suggest at least 2.
• Follow the normal feature gate lifecycle until it's removed and the operator uses collector defaults unconditionally.

Users who want different behavior can explicitly set it in their individual OpenTelemetryCollector CRs.

[swiatekm]

For reference, this is what is causing the tests in #5026 to fail.

[nikhilmantri0902]

Hi Team, I can think of the following approach, let me know if I can contribute to this issue:

1. In AddPrometheusMetricsEndpoint, we will explicitly set without_type_suffix, without_units and without_scope_info to false on the injected reader, thus preserving the metric names.
2. We will add an alpha feature gate operator.collector.usedefaulttelemetryshape which is turned off by default. When this is enabled, we skip setting the 3 fields so collector defaults can apply.
3. After 2-3 releases and stability check, we will promote this to beta, users who want historical shape can then pin it in their CRs.
4. Will include unit tests covering both gate states.

Can I work on this please? thanks!
@swiatekm

[swiatekm]

@nikhilmantri0902 that sounds like a good plan. But before I assign it to you, be advised that step 1 of this is something of an urgent item, as it's a release blocker for 0.152.0. Ideally we'd like to have this merged early next week at the latest. So be advised that if you aren't responsive in the PR, the release manager might merge a competing PR. Let me know if that's ok, no pressure.

[nikhilmantri0902]

Yes I will take this up asap. Will link a PR by tomorrow. Please assign it to me @swiatekm , thanks.

[nikhilmantri0902]

As per the SIG plan, the next step would be promoting operator.collector.usedefaulttelemetryshape to Beta after ~2 releases. Should I open a follow-up issue tracking the gate's lifecycle (Beta → Stable → removal) ?

[swiatekm]

I think we can use this issue. I changed the plan in the description to a checklist. You'll need to modify the description of your PR to avoid closing it automatically.

[nikhilmantri0902]

Sure on it.

[nikhilmantri0902]

Done @swiatekm

[swiatekm]

@nikhilmantri0902 0.152.0 is out, so we can flip the feature gate to beta.