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
Steps to reproduce
When exception is thrown out of code surrounded by a span, use_span() sets status to error. This does not get one any troubleshooting info and does not correlate with logs...
E.g. the span may have captured events or log statements PRECEDING the exception, but not the exception itself. You only have a chance to log that exception when it is caught, but this is when the span originating the exception is closed already, so this info is in the wrong place and can only go into a parent span, potentially many levels up from the source of issue
What is the expected behavior?
span.record_error() called in use_span() on error, so that error info is captured together with relevant preceding steps. Also possibly logger.exception() called in the same place. Or let it be configurable - what is done on error may depend on error type and origin
What is the actual behavior?
Simplistic error=true event set, which actually makes more sense on the parent spans leading to an exception (which is the way it is now) but not on the span that caused the exception
Additional context
There are two ways to correlate with logs: 1) capture normal log statements as events 2) put span context into each log statement. I can use neither to associate error log with originating span: there is no log statement till the span is closed; there is no event either
The text was updated successfully, but these errors were encountered:
Describe your environment
python 3.7, jaeger
Steps to reproduce
When exception is thrown out of code surrounded by a span, use_span() sets status to error. This does not get one any troubleshooting info and does not correlate with logs...
E.g. the span may have captured events or log statements PRECEDING the exception, but not the exception itself. You only have a chance to log that exception when it is caught, but this is when the span originating the exception is closed already, so this info is in the wrong place and can only go into a parent span, potentially many levels up from the source of issue
What is the expected behavior?
span.record_error() called in use_span() on error, so that error info is captured together with relevant preceding steps. Also possibly logger.exception() called in the same place. Or let it be configurable - what is done on error may depend on error type and origin
What is the actual behavior?
Simplistic error=true event set, which actually makes more sense on the parent spans leading to an exception (which is the way it is now) but not on the span that caused the exception
Additional context
There are two ways to correlate with logs: 1) capture normal log statements as events 2) put span context into each log statement. I can use neither to associate error log with originating span: there is no log statement till the span is closed; there is no event either
The text was updated successfully, but these errors were encountered: