Depending on spring-boot-starter-actuator without a tracing bridge results in empty and unwanted correlation IDs in the logs

[vpavic]

I'm trying out 4.0.0-RC1 on one project, and after upgrading I've noticed Micrometer tracing being auto-configured. Upon closer inspection, it's due to Actuator starter now having api dependency on spring-boot-micrometer-tracing:

spring-boot/starter/spring-boot-starter-actuator/build.gradle

Line 29 in 87acda7

api(project(":module:spring-boot-micrometer-tracing"))

This shouldn't happen, so I guess this dependency should be removed from the starter.

[mhalbritter]

This shouldn't happen

Why?

I'd argue that if a user adds actuator ("Enabling Production-ready Features"), they should get metrics and traces out of the box.

[vpavic]

That's quite a shortcut to decide that Micrometer based tracing should be used.

There are so many options in the observability space and it's often preference of the broader organization what solution to use.

Like I mentioned recently in a completely unrelated issue: application framework shouldn't provide too strong opinions on aspects it's simply not in a position to provide.

[mhalbritter]

Micrometer tracing is the tracing infrastructure the Spring Boot project uses out of the box, and that's the reason the starter is giving you that. The whole idea of starters is that you need one dependency, and this pulls in the other dependencies the Spring Boot team decided you should have.

But even if you have Micrometer Tracing in there, this doesn't force some specific format or product on you. It's the basic infrastructure needed to make tracing work with Micrometer observation, which the whole Spring portfolio uses as their observability implementation.

If you don't agree with the team's decision to use Micrometer Tracing, then you can either use the starter but exclude Micrometer Tracing, or not use the starter at all.

[mhalbritter]

Nonetheless, thanks for trying RC1 and providing feedback!

[vpavic]

The point is that observability stack is an aspect that's largely external to the (single) application and as such shouldn't be in the domain of application framework to provide too strong opinions about it.

This presents a significant change to Actuator starter vs 3.x and for many it indeed seems better to simply not use the starter.

[mhalbritter]

This presents a significant change to Actuator starter vs 3.x

This is true. We'll talk about that as a team.