Custom registry types

[AdamBien]

In my projects, I'm usually exposing a lot of APPLICATION metrics (counters) from different subsystems, with:

@Inject
@RegistryType(type = Type.APPLICATION)
MetricRegistry registry;

Having the possibility for further categorisation would simplify the access by introducing a sub-path: /metrics/application/validations

I think, we could start with something like:

@RegistryType(type = Type.APPLICATION, subType="validations") which would result in
/metrics/application/validations

[jmartisk]

Hi @AdamBien! We are actually currently considering removing the notion of multiple registries completely - see discussion from #384 (comment) I think MP Metrics is the only metrics framework that has multiple registries, and it has created a lot of confusion. Making it hierarchical, which basically what you're proposing here, might potentially make it even more complex. But perhaps we could apply your suggested change along with scaling down to one registry, that actually would make sense to me, because it would enable monitoring systems to retrieve just a specific group of metrics without the overhead of exporting everything...
Feel free to chime in to the discussion there.

[AdamBien]

From user perspective it is really convenient to do something like:

curl -H"Accept: application/json" localhost:8080/metrics/application

event better:

curl -H"Accept: application/json" localhost:8080/metrics/application/INTERESTING_SUBSYSTEM

In some projects we even built a small web application to receive "business" metrics. Prometheus still gathered everything.

For me, a MP user, it is useful feature.

Regarding:

MP Metrics is the only metrics framework that has multiple registries

IMO: more useful than others.

Separation between infrastructural (JVM) and application (business counters) helps in production. In fact we rely on APPLICATION registry first, then use the BASE registry to get the details.

[AdamBien]

Refining the requirement. Regardless of the amount of the registries it should be possible to fetch all interesting, pre-filtered (tagged, scoped, ...) metrics with a single, simple http command like e.g.:

curl -H"Accept: application/json" localhost:8080/metrics/application/INTERESTING_SUBSYSTEM

or

curl -H"Accept: application/json" localhost:8080/metrics/categories/INTERESTING_SUBSYSTEM

or

curl -H"Accept: application/json" localhost:8080/metrics?categories=INTERESTING_SUBSYSTEM (ugly)

(...)

IMO the registry should be also conveniently usable for apps and humans and not only for prometheus / open metrics compatible servers.

[Emily-Jiang]

Thank you @AdamBien for opening this issue further to our conversation! @jmartisk Even though we talked about the registry recently when exploring Micrometer, I think it was mainly from creator's perspectives. It is great that @AdamBien shared his use case and said it is a useful feature. We should carefully reassess the features provided by MP Metrics and lists which ones are useful. When incorporating other framework, it will be very valuable to retain some unique and useful features introduced by MP Metrics. By the way, I think @aleovic propsed here is reasonable.

[svenhaag]

Duplicate to?! #574

[ebullient]

@AdamBien .. I can see why viewing a subset of metrics might be useful, but is this for you as a human, or for processing by some other code? Have you looked at micrometer at all? If you feel the JSON output is useful, we'll probably need a micrometer registry that emits that format with configuration for filtering/grouping metrics (perhaps).

[donbourne]

@AdamBien , we've provided a solution for this in MP Metrics v5.0. Metrics can now be in one of the built-in scopes - base, vendor, application, or can be in a custom scope. There is no "hierarchy" to scopes - custom scopes are logically peers of the other built-in scopes.

Metric Registries can be injected for built-in or custom scopes:

@Inject
@RegistryScope(scope=MetricRegistry.APPLICATION_SCOPE)
MetricRegistry metricRegistry;

or

@Inject
@RegistryScope(scope="validations")
MetricRegistry metricRegistry;

You can also specify custom scopes in annotations, as in:

@Counted(scope="validations")

Metrics can be queried by scope, for example: /metrics or /metrics?scope=base or /metrics?scope=validations.