Microprofile Metrics specification allows to export metrics on /metrics endpoint (and some others). Even if it can appear surprising to have a default Prometheus exporter, it is quite natural when you deploy on kubernetes to try to reuse it.

However there are few challenges the specification does not solve:

  1. the naming: the specification is based on registries with a name (base, vendor, application) and prefixes metrics with this name. For instance a metric "foo" in the application registry will end up as the "application:foo" metric for prometheus. This is an issue when you will want to normalize the metrics name in a company and make it production oriented (ops driven) or if you don't use Microprofile in all your application (spring boot uses other names for instance).
  2. you do not control what you export since the available endpoints export either all metrics, or a particular registry, or a single metric.

To solve these issues, Apache Geronimo Metrics - which is an implementation of Microprofile Metrics, added last week a configuration to tune the Prometheus exportMETA-INF/geronimo-metrics/prometheus-mapping.properties. This file contains:

  1. A mapping of metrics name so if we want to rename our application:foo in my_foo you can add in the file "application\:foo=my_foo". This allows to exactly map all the metrics as expected by your ops team.
  2. geronimo.metrics.filter.prefix: this allows you to filter the metrics you want to export (using prefix as matching pattern).

This is generally enough to solve the previous two issues.

If you really want to go further, you can implement your own endpoint getting the registry injected and rendered as you want. I would recommand you to have a look at - or just inject - the class org.apache.geronimo.microprofile.metrics.common.prometheus.PrometheusFormatter which is reusable to avoid rewriting a bunch of formatting for prometheus.

From the same author:

In the same category: