As you know, the majority of Java application latency cases, especially Spring Boot applications, can be attributed to the default configuration of Spring Boot in the application.properties files. In my case, I assist multiple clients in resolving performance issues by suggesting the use of Elastic Observability. However, there is an important missing piece of information: the metrics for the JDBC pool.
In the Metrics section of the Application Performance Monitoring (APM) tool, we can find metrics for threads, JVM, and GC, but there is no section for JDBC pool metrics. To enable this feature, a comprehensive configuration is required in the agent's settings to activate JMX. I believe it would be highly beneficial to have native retrieval of JDBC pool metrics since it is a crucial element in detecting performance bottlenecks.
Hi @btsinfo , this is definitely something where we can improve here, and I am looking forward to being able to invest time in this area.
I agree with you, the current state of JMX metrics means a tedious and verbose configuration, having to build custom dashboards and maintain everything over time, which is not ideal.
I did a PoC a while ago (PR) where the goal was to do the same for Tomcat JMX metrics, but it would definitely be quite similar for SpringBoot or any database connection pool.
The biggest challenge here is to properly describe the metrics in a generic way that would enable to create generic visualizations (Spring boot DB connection pools should not be very different from other DB connection pools). Reusing the OTel semantic conventions for database metrics could really be a good idea. Also, until we are able do implement this you could try with OpenTelemetry instrumentation agent that might already capture this.
Do you already have some JMX configuration that you could share for your use-case ? I think that would really be helpful for when we invest time into this to make sure we cover your use-case.