'management.tracing.enabled=false' does not disable tracing propagation in Spring Boot 3.2.0

[lkleeven]

Before Spring Boot 3.2.0 setting the management.tracing.enabled property to false would also disable the underlying tracing propagation. However with Spring Boot 3.2.0 things have changed with regards to observability. As far as I understand this should have only affected how to test observability.

However, if I now run an application with tracing support and set the management.tracing.enabled to false I can see that the application still propagates tracing headers (or starts a new trace). I expected that setting management.tracing.enabled to false would also disable tracing propagation (and starting new traces).

I've reproduced the problem in this minimal Spring Boot project. The project has an included unit test that now fails. You can run it with .mvnw clean verify. Alternatively, you can run the application and do a call to the /demo endpoint which should return true but now returns false due to the suspected bug.

I've based my reproduction on a simple premise where you can call the /demo endpoint, which will then call another endpoint. That one checks if the traceparent header has been set. If so it returns false because we expect it not to be set, otherwise it returns true. In the applications properties the management.tracing.enabled property is set to false. Extra logging is present to help in debugging.

[mhalbritter]

management.tracing.enabled was never intended to switch off tracing in production apps. Its sole purpose was to disable tracing in tests. In hindsight it was a mistake that it ended up user visible in the documentation.

As we restructured the bean arrangement in #35354, now only the reporting beans are disabled when management.tracing.enabled is false. The beans which do the propagation are still in place.

If you want to disable propagation or tracing, please remove the dependencies from the classpath. Generally in Boot, we don't have enabled properties if there's a better signal, which in this case is the presence of classes on the classpath.

[lkleeven]

In that case, could you at least update the documentation for the property?

[mhalbritter]

Sure, i've opened #38626 for that.

[lkleeven]

Too bad that there won't be a property to disable this. In our experience providing a Spring Boot based framework to our company, having such properties has been invaluable to quickly help teams progress. If only to allow the option to quickly disable functionality in case of troubleshooting or production issues.

[mhalbritter]

You won't find a lot of enabled properties in Spring Boot. Features are usually enabled if a certain JAR is on the classpath. If you don't want a particular feature, either remove the JAR from the classpath or disable the auto-configuration.

[lkleeven]

They might not all have the ability to disable whole feature sets, but the properties documentation shows 152 enabled properties. Which we are happy users of because, like I said, this makes it much easier to test and troubleshoot issues.

[mhalbritter]

You're right, I should have said "You won't find a lot of enabled properties in Spring Boot that are detectable via a different signal".

These properties you linked to enable/disable features which are not detectable via other means.

[lkleeven]

As my final remark. The main reason for the request is the ease of use. I'm not just asking for myself, but also for the over 600 engineers in our company who use our own Spring Boot based framework daily. But if this is not a good enough reason for you, I'll leave it at that.

[quaff]

You won't find a lot of enabled properties in Spring Boot. Features are usually enabled if a certain JAR is on the classpath. If you don't want a particular feature, either remove the JAR from the classpath or disable the auto-configuration.

Then we need to build different artifacts for different deployments, I'd like build once and run for all by disable/enable feature flag.

[mhalbritter]

You can also disable auto-configuration with a property, see here.

[quaff]

see here

It's not very handy either since spring.autoconfigure.exclude is not easy for overriding, see #27414

[mhalbritter]

All auto-configurations work like that, I don't see why the auto-configuration for tracing should have a feature flag while the others don't.

[quaff]

All auto-configurations work like that, I don't see why the auto-configuration for tracing should have a feature flag while the others don't.

I'm discussing enable/disable feature by including dependency. But it's more desired for tracing, It's very common that an application need tracing for production deployment but not needed for SIT/UAT deployment.

[mhalbritter]

Okay. If you have that use case, please open an issue explaining why you need an enabled flag for tracing (and I guess the rest of observability?) and I'll bring it up in our next team meeting.

[mhalbritter]

Hey @lkleeven, we talked about that tracing disabling in our meeting and decided to make that management.tracing.enabled flag more official. What it does in 3.2.1 is that it disables span exporting (sending traces to your backend) and also trace propagation over the wire (e.g. HTTP). See #38641 for details.