Improve extension metrics

[jclingan]

Description
Quarkus needs a consistent approach to metrics. It would be nice for extensions to:

1. Document not just how to enable metrics, but also document the metrics themselves
2. Consistency (or at least formality) for enabling and exposing metrics.

• Hibernate logs statistics (via quarkus.hibernate-orm.statistics=true property setting) to stdout but not the /metrics endpoint.
• Kafka extension does not use a binary "true/false" metrics setting but instead it uses a metrics "level" like kafka-streams.metrics.recording.level=DEBUG. Not sure if these are logged to /metrics.

3. I did not do an exhaustive search, only a handful of extensions (3-5) support metrics. For example, from what I can tell, there are no metrics for the web stack (REST), like number of http sessions or connections. This can make it difficult to diagnose issues in production.

Implementation ideas
None.

[gunnarmorling]

it uses a metrics "level" like kafka-streams.metrics.recording.level=DEBUG. Not sure if these are logged to /metrics.

Currently the Kafka Streams extension doesn't expose any health checks or metrics. There's a related discussion in #4375, which is about providing means for letting extensions automatically expose metrics and health checks if the required other extensions are enabled.

So atm. a Kafka Streams application needs a little bit of glue code for exposing these, which ultimately should be handled by the extension itself. // CC @lhauspie

[ebullient]

I think some of this is changing as we switch over to micrometer: kafka instrumentation and hibernate instrumentation (and agroal.. ) all seem consistently enabled at this point.. I didn't notice some of the mentioned gaps/levels for logs vs. metrics..

[geoand]

@ebullient should this be considered done at this point?

[ebullient]

Either that, or John needs to go through and make a list. ;)

[jclingan]

Quarkus has come a long way since this was created. Consider this complete.