You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that the OTEL Event APIs in Java [1], JavaScript [2], PHP [3] (and presumable other languages as well) do not allow to handle errors if emitting the event fails (e.g. because of network issues).
According to Error handling in OpenTelemetry, OTEL “assume[s] that users would prefer to lose telemetry data rather than have the library significantly change the behavior of the instrumented application” and that makes sense to me as far as traces, metrics, and logs are concerned.
However, for events that are designed “high quality logs” [4], I would expect the ability to detect if the event failed to be emitted or not, e.g. for compliance-relevant logs/events that must not get lost.
Is the absence of such an ability owed to the fact that for regular logs this wasn’t required and OTEL would be open for such change, or am I missing something on the concepts of OTEL events?
Note that I am aware of global error handling capabilities in the SDKs, but I don't consider this to be suitable for what we're looking for.
Edit:
Given that you can register multiple log record processors including batch/async processors where a single log/event is not processed immediately, exposing errors on the emit() isn't as easy as I thought it would be.
A workaround seems to be to call forceFlush() on the logger provider to force invocation of the log record processors and accepting to lose potential benefits of the respective processor.
Yet, I'm still wondering whether this design should remain as-is for events or whether an API-level means to force processing of an event immediately would make sense for compliance-relevant events (e.g. emit(evt, { immediate: true }).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I noticed that the OTEL Event APIs in Java [1], JavaScript [2], PHP [3] (and presumable other languages as well) do not allow to handle errors if emitting the event fails (e.g. because of network issues).
According to Error handling in OpenTelemetry, OTEL “assume[s] that users would prefer to lose telemetry data rather than have the library significantly change the behavior of the instrumented application” and that makes sense to me as far as traces, metrics, and logs are concerned.
However, for events that are designed “high quality logs” [4], I would expect the ability to detect if the event failed to be emitted or not, e.g. for compliance-relevant logs/events that must not get lost.
Is the absence of such an ability owed to the fact that for regular logs this wasn’t required and OTEL would be open for such change, or am I missing something on the concepts of OTEL events?
Note that I am aware of global error handling capabilities in the SDKs, but I don't consider this to be suitable for what we're looking for.
Edit:
Given that you can register multiple log record processors including batch/async processors where a single log/event is not processed immediately, exposing errors on the
emit()
isn't as easy as I thought it would be.A workaround seems to be to call
forceFlush()
on the logger provider to force invocation of the log record processors and accepting to lose potential benefits of the respective processor.Yet, I'm still wondering whether this design should remain as-is for events or whether an API-level means to force processing of an event immediately would make sense for compliance-relevant events (e.g.
emit(evt, { immediate: true })
.Thanks,
Max
[1] https://github.com/open-telemetry/opentelemetry-java/blob/12eb62659d50750755c3f7533b6ed3c028cf5b8c/api/incubator/src/main/java/io/opentelemetry/api/incubator/events/EventBuilder.java#L153
[2] https://github.com/open-telemetry/opentelemetry-js/blob/81f78a6e4295300d3376b0f3592c5736ed528936/experimental/packages/api-events/src/types/EventLogger.ts#L25
[3] https://github.com/open-telemetry/opentelemetry-php/blob/fc28032748c70457d7adb8d3389c05b66a2b5a54/src/API/Logs/EventLoggerInterface.php#L14
[4] assume that users would prefer to lose telemetry data rather than have the library significantly change the behavior of the instrumented application
Beta Was this translation helpful? Give feedback.
All reactions