codefromthecrypt
commented
2 hours ago I like doing this at SDK layer and having an ENV to enable it. This is much better than having each instrumentation make a similar modification.
To your point on the collector, some notes discussed in various places limit the viability for some reasons.
- processor requires a context to work with
- A context (datapoint, span event, etc.) is later used to apply the transformation, but the processor cannot create new contexts
So, you can't do cross signal processing. The way out suggested for "cross signal" stuff in the collector was a connector component, but I've not seen one built.
Is your feature request related to a problem? Please describe.
It's not uncommon to be running only a tracing backend or otherwise have no way to ingest logs, for example for sites using jaeger. Then events cannot be consumed at all.
Describe the solution you'd like
An option that will have the logs sdk instead of queueing for OTLP export, check if there is an active span with the same context as the log. If true, convert to a span event. If not, drop it. I guess it would basically be a special logprocessor.
Describe alternatives you've considered
A collector plugin could be nice for being cross language but ordering challenges of spans coming in before logs would require some tricky time-based buffering (wait x seconds before assuming the span's events have all come in) that at best would delay telemetry and at worst would miss telemetry.
Additional context
Well, the answer to this topic will likely be needing a spec issue, but given how much engineering time has already been spent on this topic there, I'm putting it forth to more practical minded folks 😉