Support OTel declarative configuration in the Instrumentation resource

[dashpole]

Component(s)

auto-instrumentation

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

As a user of OpenTelemetry on K8s, I likely have a mixture of applications which have native instrumentation, and others which I want to auto-instrument. With the imminent stable release of OTel declarative configuration, i'll soon be able to define the SDK configuration for my natively-instrumented applications using the OTel declarative configuration in a configmap. But when I want to define the SDK configuration for my applications which are auto-instrumented, I need to use a similar, but subtly different, Instrumentation custom resource.

Describe the solution you'd like

As a user, I use the same YAML configuration structure to configure my OpenTelemetry SDKs, regardless of whether they are using auto-instrumentation vs native instrumentation. I can copy-paste, and don't have to learn two things.

Introduce a new custom resource (or a v2alpha1 of the existing Instrumentation resource) which embeds the OTel declarative configuration in it:

apiVersion: opentelemetry.io/v2alpha1
kind: Instrumentation
metadata:
  name: my-instrumentation
spec:
  # SDK configuration related fields are replaced with this field.
  sdkConfiguration:
    # This could potentially be removed, and we could rely on the apiVersion of the object instead (with a mapping)
    file_format: "0.4"
    disabled: false
    log_level: info
    resource:
      attributes:
        - name: service.name
          value: my_service
    propagator:
      composite:
        - tracecontext:
        - baggage:
    tracer_provider:
      processors:
        - batch:
            exporter:
              otlp_http:
                endpoint: http://localhost:4318/v1/traces
    meter_provider:
      readers:
        - periodic:
            exporter:
              otlp_http:
                endpoint: http://localhost:4318/v1/metrics
                default_histogram_aggregation: base2_exponential_bucket_histogram

The Instrumentation resource presumably needs other configuration related to injection of auto-instrumentation (not SDK configuration) which can still exist separately in the spec.

For the OpenTelemetry Operator project, this takes away the responsibility of defining SDK configuration, and lessens the burden of keeping up with SDK improvements over time. The Operator becomes "pass through" for SDK configuration, which means fewer issues to debug, and easier reproduction of reported bugs.

Having the SDK configuration in a custom resource brings the benefit of being able to validate the configuration when the object is created. This would be beneficial even for applications that don't need auto-instrumentation. They could use the Instrumentation resource to manage their SDK configuration across the whole cluster.

Describe alternatives you've considered

This likely would be a breaking change for the Instrumentation resource. The alternative is to not do this, and continue with the existing direction.

Additional context

No response

[swiatekm]

I'm broadly in favor of doing this, but I think we could just make it a mode exclusive with the current one. The user could either let the operator handle generating the config file based on the spec, or they could provide it themselves. I'd consider configuring the SDK directly a more advanced use case, where the operator mostly gets out of your way other than ensuring the SDK is injected into the application.