spring-boot-micrometer-tracing-brave module not pulling in Brave library causing auto-configuration not to work

[cabbonizio]

As part of upgrading to Spring Boot 4, we noticed the trace and span ID's not being logged as part of the micrometer brave implementation, so we found there's some new Spring Boot dependencies to handle this:

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-micrometer-tracing-brave</artifactId>
</dependency>

When we adopted this we noticed the trace and span tags still were not appearing so we looked into the following auto-configuration class:

org.springframework.boot.micrometer.tracing.brave.autoconfigure.BraveAutoConfiguration

This class is conditional on having io.micrometer.tracing.brave.bridge.BraveTracer on classpath. We noticed this class was not on the classpath with the expectation the spring-boot-micrometer-tracing-brave dependency would automatically include given it's very specific to "brave".

In the modules build.gradle we noticed it was an optional dependency:

optional("io.micrometer:micrometer-tracing-bridge-brave")

The question is, was this intentional? If so, why? Since this is a specific module for brave I would expect to make sure it's included on the classpath the same way for example the spring-couchbase-starter includes the Couchbase java SDK. Many thanks for taking this into consideration.

[cabbonizio]

We can work around this by specifically adding the following dependency:

<dependency>
     <groupId>io.micrometer</groupId>
     <artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>

[mhalbritter]

That's how all the modules work. Take for example the one for Micrometer's OpenTelemetry Tracing, it has this:

optional("io.micrometer:micrometer-tracing-bridge-otel")

Usually, these modules aren't used directly but through a starter. The starter for opentelemetry has this:

runtimeOnly('io.micrometer:micrometer-tracing-bridge-otel')

which puts the optional dependency on the classpath.

spring-boot-micrometer-tracing-brave is a weird one, because it doesn't have starter which is named like it, but the spring-boot-starter-zipkin is using that module. I'm guessing you're using Brave to export traces to Zipkin?

Does spring-boot-starter-zipkin fix your problem?

[snicoll]

Since this is a specific module for brave I would expect to make sure it's included on the classpath the same way for example the spring-couchbase-starter includes the Couchbase java SDK

To complete the answer @mhalbritter gave you, you are mixing modules and starters. Those aren't the same thing. Modules have the minimum amount of mandatory dependencies while starter are more opinionated. In your scenario you should definitely use the starter. Please review the migration guide.

[cabbonizio]

That's how all the modules work. Take for example the one for Micrometer's OpenTelemetry Tracing, it has this:

optional("io.micrometer:micrometer-tracing-bridge-otel")

Usually, these modules aren't used directly but through a starter. The starter for opentelemetry has this:

runtimeOnly('io.micrometer:micrometer-tracing-bridge-otel')

which puts the optional dependency on the classpath.

spring-boot-micrometer-tracing-brave is a weird one, because it doesn't have starter which is named like it, but the spring-boot-starter-zipkin is using that module. I'm guessing you're using Brave to export traces to Zipkin?

Does spring-boot-starter-zipkin fix your problem?

Thanks very much, yes we were curious why this one also doesn't have a "starter" specific dependency so assumed the one with "brave" given it had an Auto-Configuration class in it, was the one. Will give the starter a try and report back.

[cabbonizio]

Since this is a specific module for brave I would expect to make sure it's included on the classpath the same way for example the spring-couchbase-starter includes the Couchbase java SDK

To complete the answer @mhalbritter gave you, you are mixing modules and starters. Those aren't the same thing. Modules have the minimum amount of mandatory dependencies while starter are more opinionated. In your scenario you should definitely use the starter. Please review the migration guide.

Our team have read the migration guide thoroughly but this one did not seem obvious to us. We are trying the zipkin starter to see how that works for us to minimize the amount of dependencies.

[cabbonizio]

Ok we got it working using the "zipkin" starter but had to do an adjustment for clean implementation as we do not use zipkin to export our logs but have a log aggregator using OTEL which pushes to our Elastic stack. I had one of 2 options:

1. Use starter excluding zipkin

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-zipkin</artifactId>
	<exclusions>
		<exclusion>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-zipkin</artifactId>
		</exclusion>
	</exclusions>
</dependency>

2. Use starter without exclusion but disable zipkin via configuration

management.tracing.export.zipkin.enabled=false

Both of these work for us. Would it make sense to use the zipkin starter in this case knowing we are just going to disable it? I don't mean to drag this on any further but just looking for the cleanest implementation and use of the framework.

[mhalbritter]

I don't quite get your setup. You're using brave as your tracer. Are you exporting your traces somewhere? If yes, where to? Not Zipkin?

You're also exporting your logs (via otlp i guess?) to Elastic. This is done with which dependency? The logback otel exporter?

Are you exporting metrics, too?