Replies: 1 comment
-
related open-telemetry/opentelemetry-java#6940 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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