Spring-cloud-sleuth: logging.pattern.level cannot be overridden or modified

[scheerer]

Custom logging.pattern.level configuration is overridden by Sleuth AutoConfiguration

It seems that org.springframework.cloud.sleuth.autoconfigTraceEnvironmentPostProcessor overrides the logging.pattern.level no matter what.

I would suggest a simple check that looks for the presence of a custom logging.pattern.level before setting it. This suggestion assumes that logging.pattern.level is null or blank... is that the case in a default SpringBoot app? I guess I could check.

This would then of course require some additional documentation on how to add the 4 Sleuth MDC fields back into a custom logging.pattern.level.

I am absolutely willing to help contribute to this fix.

[marcingrzejszczak]

I don't think that it's true. Please check https://github.com/spring-cloud-samples/sleuth-documentation-apps/blob/master/service1/src/main/resources/application-cloud.yaml#L3 . If you run the app with the cloud profile then it will pick up the logging pattern and print out the parent id in the logs. If you take a look at the code you can see that the property source is added at the least significant position - https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/autoconfig/TraceEnvironmentPostProcessor.java#L77 . That way if someone has set the value then it will take precedence.

[scheerer]

It seems the problem is specific to logging.pattern.level being specified in a cloud config server setup. For instance: in your example of overridding the pattern in a local application*.yml does work, however that same override in an application.yml (living in the config server setup) does not work.

I am working to put together a set of samples to illustrate the problem.

[marcingrzejszczak]

Awesome! That will be much easier to work with, thanks

[scheerer]

After more playing around I have discovered that it actually has nothing to do with cloud config, and all to do with the presence of a logback-spring.xml file in an app's classpath.

Example: Simply dropping this into src/main/resources will prevent the custom logging.pattern.level to not be picked up.

src/main/resources/logback-spring.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration debug="false">
    <!-- Notice, nothing custom is overridden here - should just inherit standard Spring Boot log setup -->
    <include resource="org/springframework/boot/logging/logback/base.xml" />
</configuration>

[marcingrzejszczak]

yeah if you have a custom logback-spring.xml then you have to do it like this https://github.com/spring-cloud-samples/sleuth-documentation-apps/blob/master/service1/src/main/resources/logback-spring.xml#L10 . But that's the case of Boot and Sleuth as such