[exporterhelper] alternative tracing of components

[codeboten]

Instead of providing an interface that is then implemented by each helper, this proposes using the existing components as is and wrapping ConsumeFunc in each helper. This reduces new APIs, but it does mean that the wrapping code will need to be implemented inside each helper.

Alternative to #8833

Part of #8804

[TylerHelmuth]

@codeboten with this solution, any component that is not using the helper would have to manually instrument themselves to show up in the trace correct?

[codeboten]

@TylerHelmuth correct

[dmitryax]

The persistent queue drops the context, so this will break tracing if persistent queue is enabled

[codeboten]

@bogdandrutu @TylerHelmuth @dmitryax @djaglowski is there a preference between this and #8833? This one has less surface API, but I guess it does mean that anyone who isn't using helpers would have to implement this call themselves.

[TylerHelmuth]

@codeboten the helpers are pretty ubiquitous right? All the components in Core and Contrib would be instrumented?

[dmitryax]

@codeboten, unfortunately, neither of them will work with the enabled persistent queue. I think we need to keep it after the queue until we find a way to propagate the context through the persistent queue if we want to. But it may introduce a significant overhead.

[dmitryax]

But I may not realize all the consequences of the context being dropped down the pipeline. I assume we lose connection with the gPRC export span. Maybe it's not as bad. Just wanted to make sure we are not making it worse with the persistent queue enabled

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.