Proposal for exposing `logging` and `traces` as components.

[mattdurham]

Background

Created issue #1361 to allow exposing tracing and logging write to's. This would allow modules to fan out logs and help move away from singletons.

Proposal

Add two new components name TBD but assume alloy.logging and alloy.traces for now. This would allow modules to tap into the logging and tracing pipelines. This means that individual pipelines can turn on the level dynamically and take actions different from each other easily without having to chain the write to up the stack.

This would require making tracing and logging services that the two new components can access and tie into.

logging {
  level = "error"
}

alloy.logging "d1" {
   level = "debug"
   write_to = [...]
} 

alloy.logging "d2" {
   level = "warning"
   write_to = [...]
}

In the above all logs would enter the 2 components d1 and d2 and logging. The components and logging would filter out based on level and then pass the logs on down the pipeline.

Some considerations is to ensure performance is acceptable, instead of rejecting logs at log time, they are instead rejecting when passing to components/configuration block.

[fstab]

Do you think there's a chance to use https://github.com/open-telemetry/opentelemetry-collector/tree/main/exporter/loggingexporter?

[thampiotr]

I would really like to be able to control the log level per component (or component instance) and per service. Sometimes you want to debug just one part of the graph and enabling debug logging for all components creates a lot of noise.

I think we should either incorporate the above use case into this proposal or at least make sure that we can extend the design in the future to allow this use case.