-
Notifications
You must be signed in to change notification settings - Fork 40.9k
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
Spring Boot 3 DispatcherServlet not logging traceId (Impact on Error logging) #38261
Comments
I'm not sure I understand what observation should be going on during the Servlet infrastructure setup. There is no incoming request since the server is not started yet. Why should there be a trace id in this case? As for exceptions not handled by the Spring web framework, those are bubbling up to the Servlet container and are handled by Tomcat itself. This is too low level for a Spring instrumentation. This has been discussed in spring-projects/spring-framework#29398 and documented here. Micrometer might provide a Tomcat Valve for instrumentation in the future but you would need to disable web observations at the Spring level to not get duplicates. |
@bclozel, Thanks for the response, I did clearly state the logs for spring boot 2 and 3, as you might have noticed, spring-boot-2 is logging the traceId where as boot-3 is not logging it for both success and error scenarios. For later case i.e. error scenario servlet is initialized and traceId is populated by applicatin logs however when exception is not handled by application not sure who handles that whether spring framework or tomcat, but traceId is missing in that as well |
@sanintel3 it seems you're re-stating your first comment without replying to my question. Anyway, I think your concerns are covered by my previous comment. While it is a change of behavior, the Spring Cloud Sleuth approach had many issues and this is why the team chose a different route for instrumenting applications. You can follow micrometer-metrics/micrometer#3777 if you'd like to instrument your application at a lower level with Tomcat. |
In success scenario, agreed it's not important to log traceId during initialization logs but there is a change in behaviour as you mentioned in the previous comment between sleuth and micrometer how this is handled and it make sense, but for error scenario I don't understand whether a fix will be provided by container or not. However, we may need to go with workaround suggested in the other ticket. Thanks for looking into it |
@bclozel Is there any suggestion from spring how to deal with this? Any workaround? Whenever we have exceptions for example within in a filter, we just get this log:
Trace-id and span-id is always missing. Tested with spring boot 3.2.2. |
TraceId
andSpanId
are not getting logged by spring bootDispatcherServlet
which also affecting error logging.Any exception that is handled by spring (unhandled application exceptions/errors) logs stacktrace and this stacktrace doesn't contain
traceId
How to reproduce:
https://github.com/sanintel3/spring-boot-2-mvc
Versions:
Java 17
Spring boot: 2.7.17
Gradle: 8.4
Success scenario logs:
Error scenario logs:
https://github.com/sanintel3/spring-boot-3-mvc
Versions:
Java 17
Spring boot: 3.1.5
Gradle: 8.4
Success scenario logs:
Error scenario logs:
As shown above with spring boot 3.1.5 micrometer distributed tracing
DispatcherServlet
is not loggingtraceId
andspanId
which is having an impact on error logging as well (which is more critical for debugging any production issues)The text was updated successfully, but these errors were encountered: