Is your feature request related to a problem? Please describe.
We are using log4j as logging framework with asynchronous logging for some deployments. At the moment, the logs from log4j are added to spans as events with a custom log4j appender. This works great for synchronous logging, but in case of asynchronous logging, we have to create new spans (with the original span as parent) to be able to log reliably, as the end() methods could be called before the log4j appender is called.
Describe the solution you'd like
It would be great to be able to send additive updates of span after calling end(). I understand that the spec requires that every method call after end() is ignored, but the async logging is imho not an esoteric use case. As some methods like addEvent can never create a conflict, it might be feasible to allow it.
Describe alternatives you've considered
I was thinking about adding an own logic to keep track of the unfinished log events and end the span when everything is finished. But as we use the log4j API directly, i'm not sure if the idea is even feasible.
Unfortunately this is impossible to support with our current design. This would require us to export a span at a later time than end and probably would complicate the logic a lot.
Can we work to find an alternative option?
I recommend capturing logs as spans for now (until there is an OpenTelemetry logging API). We started out capturing them as events but then switched to spans, see https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/212:
Capture logs as spans, to avoid the limitations of current implementation that captures them as events (no log capture when no current span, and limited number of events per span).
I recommend capturing logs as spans for now (until there is an OpenTelemetry logging API).
Even with an OpenTelemetry Logging API, it should be possible to support the most important logging frameworks. For many projects it will not be feasible the replace the logging system.
Once OpenTelemetry logging API exists, we can use that as the destination for logs that we capture from existing logging frameworks.
Most helpful comment
Unfortunately this is impossible to support with our current design. This would require us to export a span at a later time than end and probably would complicate the logic a lot.
Can we work to find an alternative option?