[collector] Support configuring collector telemetry settings in the CRD (not just embedded in spec.config)

[cschanhniem]

Component(s)

collector

What happened?

The OpenTelemetryCollector CRD does not expose a first-class field for configuring the collector's own telemetry (metrics, traces, and logs generated by the collector itself). Users must embed telemetry settings in the spec.config string under the service.telemetry block, which:

1. Bypasses CRD validation - the operator cannot validate telemetry settings at the API level.
2. Makes it impossible to set opinionated defaults for self-telemetry.
3. Prevents the operator from aggregating or forwarding collector telemetry independently.

Steps to reproduce:

Deploy an OpenTelemetryCollector with custom telemetry settings embedded in the opaque config string. The telemetry configuration cannot be validated, defaulted, or observed by the operator.

Expected behavior:

The CRD should have a top-level spec.telemetry field similar to the upstream collector's service.telemetry. The operator would merge spec.telemetry into the collector's service.telemetry config at reconciliation time, allowing CRD-level validation and defaulting.

What did you see instead?

All telemetry configuration is opaque text inside spec.config. No validation, no defaults, no observability into what the collector is publishing about itself.

Additional context:

This is tracked as a known gap in #5075. The operator already exposes certain top-level fields in the ClusterObservability CR. Extending the same pattern to the collector's own telemetry would provide consistency.

[iblancasa]

I don't fully understand why this is needed. The current mechanism allows doing validation in the web hook and set defaults. Why would it be useful to duplicate the logic?

Because:

Bypasses CRD validation - the operator cannot validate telemetry settings at the API level.

Would some logic in the validation web hook not be enought? I'm not sure what other validation would be nice to have here.

Makes it impossible to set opinionated defaults for self-telemetry.

Can you provide an example?

Prevents the operator from aggregating or forwarding collector telemetry independently.

I don't understand the use case.

[swiatekm]

I'm not fully opposed, but keep in mind that reproducing the configuration schema of the collector in the CRD binds the operator to its shape, including breaking changes to it. It's quite expensive for the operator to make breaking changes to CRDs, so we're wary of embedding config schemas we don't control in them. At the very least, I would be against doing this until the collector is stable.

[pavolloffay]

All telemetry configuration is opaque text inside spec.config. No validation, no defaults, no observability into what the collector is publishing about itself.

I disagree; the operator already parses different parts of the collector configuration (to apply defaults or validate). Our approach with the collector CR was from the beginning to embed entire collector config in the CR which operator can parse, understand and adjust.

[pavolloffay]

For intance there is #5229 which fixes some of the service telemetry issues.