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
The default state of an OTel SDK configures a basic standard-error error handler and logger. Using examples/otel-collector as a test case, I edited the example's main() to use a non-blocking Dial, which would be more conventional. This has the side-effect of making the example a useful test for what a user will see if they run an OTel SDK with an invalid endpoint.
I've identified three ways the OTLP exporter errors could improve, so that the default error and logging handlers provide sufficient detail to explain what is failing.
Proposed Solution
The proposal includes three elements.
In the retry package, in wait() when the context deadline is exceeded, return a the same form of error with text explaining the final retryable error code (which will be "connection refused" in the example scenario).
In the OTLP trace exporter, ensure that every error returned is prefixed with trace export: .
In the OTLP metric exporter, ensure that every error returned is prefixed with metrics export: .
The final two points ensure that the user can differentiate metrics and traces errors independently; they are different points because these packages have diverged.
Alternatives
To keep things as they are, the users sees for example what's shown in #2217. You get a timestamp and "context deadline exceeded", no indication of what or why.
The text was updated successfully, but these errors were encountered:
Problem Statement
The default state of an OTel SDK configures a basic standard-error error handler and logger. Using
examples/otel-collector
as a test case, I edited the example'smain()
to use a non-blocking Dial, which would be more conventional. This has the side-effect of making the example a useful test for what a user will see if they run an OTel SDK with an invalid endpoint.I've identified three ways the OTLP exporter errors could improve, so that the default error and logging handlers provide sufficient detail to explain what is failing.
Proposed Solution
The proposal includes three elements.
retry
package, inwait()
when the context deadline is exceeded, return a the same form of error with text explaining the final retryable error code (which will be "connection refused" in the example scenario).trace export:
.metrics export:
.The final two points ensure that the user can differentiate metrics and traces errors independently; they are different points because these packages have diverged.
Alternatives
To keep things as they are, the users sees for example what's shown in #2217. You get a timestamp and "context deadline exceeded", no indication of what or why.
The text was updated successfully, but these errors were encountered: