Opentelemetry-java: Allow adding events to Spans after calling .end() for asynchronous logging

Created on 10 Jun 2020  路  4Comments  路  Source: open-telemetry/opentelemetry-java

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.

Feature Request after-ga

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?

All 4 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jkwatson picture jkwatson  路  5Comments

arminru picture arminru  路  5Comments

pavolloffay picture pavolloffay  路  5Comments

jkwatson picture jkwatson  路  5Comments

arminru picture arminru  路  4Comments