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
As a developer I would like to see both, unhandled and handled errors as part of a trace. Currently our instrumentations are only built to record unhandled exceptions. However a likely pattern that developers might follow in views is to run an operation due to an event, and then catch + log errors from that operation, while showing the user some error notification. With access to application logs they can still see these errors, however with our solution that would not be the case.
We should consider enriching our traces with error logs at least. Logged errors would be recorded as events on traces, ideally on the current span, rather than the root span. This would require instrumenting specific logging libraries, like log4j or logback. OTel has existing instrumentations for both which could be checked to get an idea on how to make this work.
Depending on how the error handling in an application works (catch + log, catch + log + rethrow) we might want to make this optional as otherwise the error might be recorded multiple times.
The text was updated successfully, but these errors were encountered:
As a developer I would like to see both, unhandled and handled errors as part of a trace. Currently our instrumentations are only built to record unhandled exceptions. However a likely pattern that developers might follow in views is to run an operation due to an event, and then catch + log errors from that operation, while showing the user some error notification. With access to application logs they can still see these errors, however with our solution that would not be the case.
We should consider enriching our traces with error logs at least. Logged errors would be recorded as events on traces, ideally on the current span, rather than the root span. This would require instrumenting specific logging libraries, like log4j or logback. OTel has existing instrumentations for both which could be checked to get an idea on how to make this work.
Depending on how the error handling in an application works (catch + log, catch + log + rethrow) we might want to make this optional as otherwise the error might be recorded multiple times.
The text was updated successfully, but these errors were encountered: