Deprecate Micrometer Tracing code in favor of tracing in MongoDB driver

[mp911de]

We should deprecated our Micrometer Tracing implementation in favor of MongoDB's OpenTelemetry implementation in the driver. MongoObservationCommandListener.

Observation through MongoObservationCommandListener creates distributed tracing spans including context propagation and it creates long-task timers (e.g. spring.data.mongodb.command.active) that are sent to observability systems (e.g. Prometheus) using a set of tags.

Having an implementation on the Spring Data level while Spring Boot configures a different metrics implementation (see #4926) is unfortunate and that can be solved by having metrics and tracing directly within the driver.

[codesimplicity]

Not sure who's to blame here, but it's quite an annoying issue. Please let me know if I should raise this separately.

When using Prometheus, there also is a bug with same nasty consequences:

2025-07-04 05:30:37.928  WARN 1 --- [nio-5433-exec-1] i.m.p.PrometheusMeterRegistry            : The meter (MeterId{name='spring.data.mongodb.command.active',tags=[]}) registration has failed: 
Prometheus requires that all meters with the same name have the same set of tag keys. There is already an existing meter named 'spring.data.mongodb.command.active' containing tag keys [db.mongodb.collection, db.name, db.operation, db.system, net.peer.name, net.peer.port, net.transport, spring.data.mongodb.cluster_id]. The meter you are attempting to register has keys [db.mongodb.collection, db.system, net.peer.name, net.peer.port, net.transport, spring.data.mongodb.cluster_id]. Note that subsequent logs will be logged at debug level.

I've removed the actual tag values and our own tags, hopefully consistently.

The 2nd usage appears to be the db.name and db.operation tags.

The nasty consequence is, that this not only means that the meter above is not registered, but also that this is not logged for any other meter where the same problem exists which makes it hard to fix those problems.

[mp911de]

Looks like another incarnation of #4994. @jonatan-ivanov these reports seem to pile up. It's inconvenient to handle MeterRegistry-specific requirements in the observation code, especially because we're not familiar with these and have no real way to verify completeness. Can we work together to find an approach that would improve the situation? I get that certain tags are required to be present before starting an observation and cannot be changed later on, but that should be a concern of Micrometer (and ideally throw exceptions if observability instrumentation violates API usage).

[jonatan-ivanov]

Looks like another incarnation of #4994.

Yes, DefaultMongoHandlerObservationConvention still attaches keyvalues conditionally without a fallback, I think it should be fixed.

It's inconvenient to handle MeterRegistry-specific requirements in the observation code, especially because we're not familiar with these and have no real way to verify completeness.

Prometheus might be the (only?) one that complains but I think this is a general issue for metadata-completeness (other backends might not complain but this still can be weird on user-side).

Can we work together to find an approach that would improve the situation?

Of course, I think we should do two things:

1. Fix these issues
2. Add tests (this can be general unit tests using Micrometer's TCK or even more concrete using the Prometheus registry)

I get that certain tags are required to be present before starting an observation and cannot be changed later on, but that should be a concern of Micrometer (and ideally throw exceptions if observability instrumentation violates API usage).

From the perspective of the issue above, the only requirement that metadata should have a fallback value (we can definitely look into the API to make this easier).
We usually don't throw exception in these cases (Micrometer tries not to disturb the app) but we have an ObservationValidator that can be used in tests and we might be able to extend it so that it checks this scenario too.

[jonatan-ivanov]

We should deprecated our Micrometer Tracing implementation in favor of MongoDB's OpenTelemetry implementation in the driver. MongoObservationCommandListener.

I'm not sure this is the current case/what should be done:

• Right now Micrometer Tracing is not used for instrumentation (only for tests), the Observation API is used to instrument the code
• Not sure what MongoDB wants to do (I thought they want to use the Observation API) but using OpenTelemetry directly means losing functionality compared to the Observation API. It's like using log4j2 (a concrete implementation library) instead of slf4j (the abstraction that let's you plug implementations in/out).