OtelCol exporters should should only initialise for the telemetry types for which they're configured

[ptodev]

Request

If a River config file contains an otelcol.exporter such as otelcol.exporter.otlp, that exporter will always create the underlying Collector exporters for logs, metrics, and traces. For example, even if that exporter is only used for logs, it will still create the exporters for metrics and traces. The relevant code is in component/otelcol/exporter/exporter.go.

The code needs to be changed in such a way so that the component only starts the exporters which it is used for. For example, if only logs are forwarded to the exporter component, only the logs exporter should be created.

Maybe one way to solve this is to create lazy implementations of the interfaces of exporter.Traces, exporter.Metrics and exporter.Logs. Those lazy implementations would call functions like e.factory.CreateTracesExporter only when the Start function is called. Then have the code in component/otelcol/exporter/exporter.go use those lazy exporters instead of the result of e.factory.CreateTracesExporter directly. I'm not 100% sure whether this would work, but it's the most obvious approach that I can think of.

Use case

This change is necessary in order to support the load balancing exporter with metrics. The configuration for metrics is quite unique, and otelcol.exporter.loadbalancing can crash if it is configured to process a routing key of "trace ID" with a metrics exporter.

Related to grafana/agent#5684

[rfratto]

I don't understand why the current behavior is a problem; can you explain more?

Maybe one way to solve this is to create lazy implementations of the interfaces of exporter.Traces, exporter.Metrics and exporter.Logs.

One issue with this approach is that if you update your config to stop sending a particular telemetry type, the lazy implementation will still continue running, since components have no knowledge of other components wired to them.

[ptodev]

I don't understand why the current behavior is a problem; can you explain more?

It is possible to configure an LB exporter with metrics-specific config. This can be done by using a rounting_key of metric. This will cause the traces and logs exporters to crash, even if the user only configured that LB exporter to accept metrics. Similarly, if rounting_key is traceID, then the metrics exporter will crash because it is not able to route according to traceID. The compatibility matrix is in the OTel LB exporter docs.

If a user wires a otelcol.exporter.loadbalancing to receive metrics but uses a rounting_key of traceID, then I think it's ok to crash the process. But it should happen immediately after startup and not after the first pieve of telemetry is received. This requirement also needs to be kept in mind in case we go with a "lazy" approach.

[github-actions]

This issue has not had any activity in the past 30 days, so the needs-attention label has been added to it.
If the opened issue is a bug, check to see if a newer release fixed your issue. If it is no longer relevant, please feel free to close this issue.
The needs-attention label signals to maintainers that something has fallen through the cracks. No action is needed by you; your issue will be kept open and you do not have to respond to this comment. The label will be removed the next time this job runs if there is new activity.
Thank you for your contributions!

[madaraszg-tulip]

#2242 may fix this issue. Only exporters supported by routing_key are created, and experimental metrics support is added.

[ptodev]

Closing this since we could use #2242 as a baseline for how we handle such cases in the future. Thank you, @madaraszg-tulip!