RFC - Universal Component Telemetry

[djaglowski]

Revisit spans vs logs items:

• RFC - Pipeline Component Telemetry #11406 (comment)
• RFC - Pipeline Component Telemetry #11406 (comment)

[jade-guiton-dd]

Because the comments linked above only mention the feasibility and "elegance" of using spans as opposed to logs, I'd like to add that spans in pipeline instrumentation would allow us to additionally capture timing information. Notably, measuring the latency of synchronous processors would now be feasible in a generic way, by comparing the timing of parent and child Consume spans. For receivers, doing this would only require some kind of root span to be emitted, which is often done automatically by gRPC/HTTP instrumentation anyway.

This is somewhat relevant to improving the internal telemetry of the OTLP receiver before its stabilization (see #11139). Its latency can currently be measured in a similar way, but the method relies on knowledge of implementation details, and does not currently work for profiles, issues that would be fixed by relying on pipeline instrumentation.