-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Logback logging.level.pattern is overriden by Sleuth #25418
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
Comments
Thanks for the report. Unless you are deploying multiple applications in the same JVM, #24835 shouldn't be related to this, although you may have been relying on the buggy behaviour that meant that the first context's pattern would be reused by every subsequent context. To help us to investigate the cause, can you please provide a minimal sample that works with 2.4.1 and fails with 2.4.3? |
https://github.com/artemy/spring-logging-sleuth-override here it is Example startup output with 2.4.1:
Output from 2.4.3:
|
Thanks, @artemy. I've reproduced the behaviour that you have described. The behaviour that you preferred appears to be specific to 2.4.0 and 2.4.1. 2.3.x and 2.4.2+ all use the configuration from Sleuth. In other words, I think the bug introduced in 2.4.0 (#23767) and fixed in 2.4.2 (#24835) was advantageous to you. We'll need to see if there's something else that we can do here or on Sleuth to stop it from overriding your explicitly configured |
Adding the actuator to the app and looking at the config props endpoint, we can see that the property source that contains Sleuth's configuration has higher precedence than the source the contains the bootstrap configuration. The following output is from 2.4.2:
With 2.3.9.RELEASE, the behaviour is rather surprising. The configprops endpoint shows that the bootstrap property should be used:
But the log output shows that's not the case:
|
In 2.3.9.RELEASE,
Note that the ordering is different to that shown above via the config props endpoint. At this point in time, This appears to be a Spring Cloud bug. I'm not sure if Sleuth is doing the wrong thing when it creates or replaces the |
I've opened spring-cloud/spring-cloud-sleuth#1863. |
right, I'll follow the issue there. Thanks a lot for the investigation 👍🏻 |
Uh oh!
There was an error while loading. Please reload this page.
We have a Spring Boot 2.4.3 application that uses custom
logging.level.pattern
defined in a bootstrap.yml.It works only for a few log lines until configuration is fetched from the config server and then it's overriden by the default pattern provided by Sleuth.
%5p [${spring.zipkin.service.name:" + "${spring.application.name:}},%X{traceId:-},%X{spanId:-}]
I have seen a similar issue here #24835, but upgrading our app to 2.4.3 didn't help with this.
This used to work in 2.4.1. The current workaround we found is to add the pattern override to application.yml instead or to have custom
logback-spring.xml
on the classpath.The text was updated successfully, but these errors were encountered: