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 ?
Comment From: mhalbritter
Does this help you? https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using.auto-configuration.disabling-specific
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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