Do not require adding ObservationHandlers

[cfredri4]

It would be much nicer if the observation handlers weren't needed. I.e. I don't want to have to do this:

ObservationConfig observationConfig = observationRegistry.observationConfig();
observationConfig.observationHandler(new ConnectionTracingObservationHandler(tracer));
observationConfig.observationHandler(new QueryTracingObservationHandler(tracer));
observationConfig.observationHandler(new ResultSetTracingObservationHandler(tracer));

I only want to do this:

var listener = new DataSourceObservationListener(observationRegistry);
return ProxyDataSourceBuilder.create(dataSource)
        .listener(listener)
        .methodListener(listener)
        .proxyResultSet()
        .build();

For most (all?) other cases where Micrometer is used, it's enough to only set/wrap with the ObservationRegistry (e.g. Kafka, JMS, RestClient, gRPC, MicrometerHttpClient, Lettuce, Cassandra to name a few).

[ttddyy]

Hi,
Thanks for the feedback.
If you are using datasource-micrometer-spring-boot, the auto-configuration will handle the registration of the tracing observation handlers for you.

For most (all?) other cases where Micrometer is used, it's enough to only set/wrap with the ObservationRegistry (e.g. Kafka, JMS, RestClient, gRPC, MicrometerHttpClient, Lettuce, Cassandra to name a few).

datasource-micrometer is a bit different because it focuses on span creation and uses custom TracingObservationHandler implementations rather than the defaults. It also inherits certain behaviors from Spring Cloud Sleuth. In this setup, properties like spring.sleuth.jdbc.includes (or jdbc.includes) determines which types of spans are created.

This doesn’t necessarily mean it requires separate tracing handlers. It’s simply how the current implementation works.
For now, if you’re using it with Spring Boot, the recommended approach is to rely on the auto-configuration to set up the necessary infrastructure.