Support per-component log level configuration

[rogercoll]

Component(s)

No response

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

The Collector's log level is configured globally via service::telemetry::logs::level, which applies uniformly to every component. There is no way to adjust the log verbosity of a single component without affecting all others.

This becomes a problem for resource-intensive components like the ebpf-profiler receiver, where enabling debug logging is essential for troubleshooting but doing so at the service level floods the output with noise from every other component in the pipeline. The ebpf-profiler is actively working around this limitation by introducing component-specific configurations like verbose_mode (opentelemetry-ebpf-profiler#1317), but this forces each component to reinvent its own log level control rather than relying on a collector-level mechanism. See opentelemetry-ebpf-profiler#417 for the broader discussion.

Describe the solution you'd like

Allow users to override the log level for individual components by adding an optional telemetry::logs::level key inside each component's configuration section. When omitted, the component inherits the service-level default. When present, it overrides the effective log level for that component only.

receivers:
  otlp:
    protocols:
      grpc:
  profiling:
    telemetry:
      logs:
        level: debug   # debug only for this receiver

exporters:
  otlp:
    endpoint: localhost:4317
  debug:
    telemetry:
      logs:
        level: error   # silence the debug exporter

service:
  telemetry:
    logs:
      level: info      # default for everything else
  pipelines:
    profiles:
      receivers: [profiling]
      exporters: [otlp]
    traces:
      receivers: [otlp]
      exporters: [debug]

This reuses the same telemetry::logs::level pattern already established at the service level and should zero changes to existing components.

I have a draft PR with a possible implementation that intercepts the telemetry key during config unmarshalling in configunmarshaler, strips it before delegating to the component's own unmarshaller, and applies the level override when building per-component TelemetrySettings in the graph (while preserving the service log level if not defined). This approach has a few drawbacks but doesn't require further changes into the components:

0. Hidden to component's devs
1. If a component ever uses telemetry as a config key, the collector silently steals it.
2. Might not work out of the box with config checks like validate command
3. Mutating the confmap with Delete mid-flight.

Describe alternatives you've considered

• An alternative that's less hidden would be to define per-component log levels at the service level:

  service:
    telemetry:
      logs:
        level: info
        component_overrides:
          receivers/profiling: debug
          exporters/debug: error

• Each component implements its own log level config: This is what the ebpf-profiler is doing with verbose_mode. It works but leads to inconsistent UX across components and duplicated logic.
• Setting the service log level to debug and filtering output externally: Produces excessive log volume and is wasteful at the source.

Additional context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[johnmichaelll238-cloud]

Hello, please can anyone put me up to speed on this issue, I'm a newcomer here and would really like to help out, even if it's just a sub issue. Thank you!

[mx-psi]

I support the general idea of adding this functionality. As I mentioned at KubeCon I want to explore to what extent it would be possible to use this as the config for handling this. (note that I am not sure if it is a good fit, I just think it is worth exploring to avoid further deviation from declarative config)

[perk]

The idea looks really useful 👍

I personally like the main proposed solution of controlling the component logging behavior from within said component configuration itself.

As a sidenote - this could be mixed with the global per-component logging configuration at the service level, with the in-component config taking a precedence if present. Not sure how useful this combination would be though as it feels like it's too much options for same result.

[vyagh]

hi, can i work on this ??