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.