Disable trace exporting via properties

[kuldeep0508]

With spring boot 2.x below mentioned dependency is required for Sleuth to send spans to Zipkin or a Zipkin compliant tracing distribution system.
implementation 'org.springframework.cloud:spring-cloud-sleuth-zipkin'

But with spring boot 3.x this ZipkinAutoConfiguration is deafult present in org.springframework.boot.actuate.autoconfigure and gets enabled when

management.tracing.enabled = true

So MS start sending the spans.

In our case we rely on istio for this task and our micro-services are not supposed to send any data to zipkin server.

But with upgrade to springboot 3 this feature gets enabled as default and we get an error in our logs stating unabled to connect with zipkin server as we have not configure our MS to do this task.

I check there is no property to control the enablement of this behaviour.

So is there any plan to provide any properties like below to control this behavior.

management.tracing.zipkin.enabled = true/false

And as a workaround should we write noopZipkinSpanHandler ?

[mhalbritter]

Does this help you? https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using.auto-configuration.disabling-specific

[kuldeep0508]

Does this help you? https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using.auto-configuration.disabling-specific

It worked thanks :) ,

but it may be good for a better control over it we can have a property for enable or disable it in future.

[mhalbritter]

In Boot, we refrain from adding enabled properties if there are some other signals. In this case, the signal is Zipkin on the classpath. And if for some reason (like in your case) Zipkin is on the classpath and you don't want Zipkin to be enabled, exclude the auto-configuration.

[nioertel]

I understand this argument for Spring Boot 3.3.x.

However with Spring Boot 3.2.x and before, Brave 5.x is used and there brave.Span directly depends on zipkin2.Endpoint. Removing Zipkin from the classpath is not a viable option.
Therefore I would not consider the presence of Zipkin on the classpath as sufficient signal.

[mhalbritter]

In that case, please use the auto-configuration disable feature, as I said here. We won't add an enabled flag in the 3.2.x line anyway, as it only gets bugfixes and dependency upgrades, but no new features.

[kubav182]

Why should we mess our config with autoconfig exclusions?
spring.zipkin.enabled - simple, clear and intuitive
spring.autoconfigure.exclude=org.springframework.boot.actuate.autoconfigure.tracing.zipkin.ZipkinAutoConfiguration why should i write this to config and search for this long classpath? IDE can help you but usually you have external config where is no autocomplete for spring boot packages. The user experience should be considered too. Spring Boot and its changes should make it easier not harder.

[rivancic]

I have Zipkin on the classpath as application will use zipkin exporter when deployed in such environment.
OFC for local testing I don't need it. And like mentioned above, my first go to is to check Spring common application properties in how to enable/disable behavior. Now in this case you really have to know about the Autoconfiguration class.

[rishiraj88]

I fully agree with @rivancic . Autoconfiguration is so versatile and dependable.
We should always look up to this in first place while changing the inclusion/enabling of dependencies "automatically". It's such a powerful automation.

[kubav182]

Exactly we need to disable exporter for some reasons (tests, local env, maybe you dont need to export spans on every dev/test env). Removing zipkin from classpath is not option as we would have to make new build for each env. So having zipkin on classpath as signal is not the best option. Disabling autoconfiguration in yaml/properties is not user friendly from my point of view because we have to know all the autoconfigs relying on this signal instead of one shared enabled property. For example for redis there are 2 autoconfigs one relying on classpath and one relying on property it is quite confusing. I understand the argument there is complexity to have many ways to do the same thing, but our arguments are also valid I think.

[mhalbritter]

We talked about that and decided to add a .enabled property. This mirrors our metrics properties, e.g. there's a management.prometheus.metrics.export.enabled property, or a management.graphite.metrics.export.enabled. We want to do that for our tracing backends, too.

With these properties, users can disable the exporting of data without fiddling with the classpath.

[mhalbritter]

Changes are here and ready to be merged as soon as we have our 3.3.x branch: https://github.com/mhalbritter/spring-boot/tree/mh/34620-disable-trace-exporting-via-properties