Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow responding to errors when emitting log records #4377

Open
pellared opened this issue Jan 20, 2025 · 0 comments
Open

Allow responding to errors when emitting log records #4377

pellared opened this issue Jan 20, 2025 · 0 comments
Labels
sig-issue A specific SIG should look into this before discussing at the spec spec:logs Related to the specification/logs directory

Comments

@pellared
Copy link
Member

pellared commented Jan 20, 2025

Discussed in #4085

Originally posted by mlenkeit June 21, 2024
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

Related to:

@svrnm svrnm added spec:logs Related to the specification/logs directory sig-issue A specific SIG should look into this before discussing at the spec labels Jan 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig-issue A specific SIG should look into this before discussing at the spec spec:logs Related to the specification/logs directory
Projects
Status: No status
Development

No branches or pull requests

2 participants