Why is there no "component.Host.GetProcessors" ?

[DWonMtl]

Hello,

Many of the "Processors" found in opentelemetry-collector-contrib are using the component.Host.GetExporters in order to send their data to additional exporters. A good example of this is the spanmetricsprocessor that use it to send metrics information about traces to a metrics exporters.

We are currently developping our own spanlogsprocessors to send logs about our traces to a log exporter (ex. lokiexporter). This pattern work nicelly, however, we would like to apply changes on the logs before sending it to the exporter.

We know that we can do it directly in the processor before sending to the lokiexporter but some processors already exist to perform these tasks, like the resourceprocessor.

Therefore, it could be nice if we could use the same pattern as the one using the component.Host.GetExporters but to send it to a processor instead.

Is there a reason why the component.Host interface doesn't support a GetProcessors function similar to the already existing GetExporters and GetExtensions ?

If there is no specific reasons other than "it hasn't been done yet", we are willing to create an issue and start contributing.

[secat]

@bogdandrutu and @tigrannajaryan is it something that could be added to opentelemetry-collector? As stated in the description, we can open issues regarding this topic and start contributing.

Thank you in advance for your response.

[bogdandrutu]

I would personally prefer to not move forward with this hack, see #2336 for a more elegant and clean solution to this

[tigrannajaryan]

This is my feeling as well. If components start talking to each other directly we start loosing the concept of user-definable pipelines specified in the config file and instead end up with data flows that are difficult to understand or are unique for each individual component. The generalized pipelines have other potential benefits that addhoc data flows between components don't (e.g. ability to add automatic observers that emit metrics from each point of the pipeline in the future).

I would prefer to move away from the ability for components to speak to each other directly and instead provide solutions that make the desired scenarios possible (e.g. the signal conversion proposal that Bogdan linked to).

[DWonMtl]

I aggree with you!

Looking at how flexible is the opentelemetry configuration is, I was kind of surprise to see that this was the way to do cross signals communication. The issue you showed me (#2336) is exaclty what we are looking for.

Thanks for the quick response!