prometheus / client_java

Prometheus instrumentation library for JVM applications
http://prometheus.github.io/client_java/
Apache License 2.0
2.18k stars 797 forks source link

Enable federation-like match parameter. #633

Open hdost opened 3 years ago

hdost commented 3 years ago

This is something that indeed I think would be useful in all clients. As described here: https://prometheus.io/docs/prometheus/latest/federation/

Use Case: An internal library maintainer wants to scrape only metrics exported by their library for exposition and analysis related directly to their area of concern. This allows them to not need to scrape all metrics from every instance using their library, but only the metrics which they care about.

I know that metric relabeling exists, but the problem with that is it is a waste of resources to scrape a bulk payload of metrics when maybe 90%+ of them will just be dropped anyway. It makes scrapes slower. I would be interested in implementing, but before attempting to upstream the change I wanted to ensure it would even be accepted as an idea.

fstab commented 3 years ago

Not sure if I understand this correctly: You want to write a Java library, and this library should provide Prometheus metrics. You are looking for a way that an application exports only metrics from your library, and not other metrics.

What about providing a configuration option for your library that allows users to pass a custom CollectorRegistry? If a user wants to export only metrics from your library, they can use a dedicated registry and export just that. If a user wants to export metrics from other libraries as well, they can use the default registry.

bjung82 commented 3 years ago

If I unterstand it correctly, @hdost wants a metric endpoint that can exposes all metrics (including these of a specific library), but provide a new parameter that controls/filters the exposed metrics for a single call to the endpoint. This way not all metrics are exposed and scraped which saves resources.

In the edge case, only a single metric is exposed in the endpoint. We have something like this in place (single metric exposed, for special legacy monitoring system)

hdost commented 3 years ago

@fstab Yes it's more as @bjung82 is describing.

I did see the "name" parameter after the fact. And possibly this could work. I'll need to do a little toying around, but if it allows my to enumerate that could work, but I would be worried about too long of a URI resulting in a failure hence why the match would be more useful.

fstab commented 3 years ago

Ah, I see what you mean now. It's hard to say how difficult it would be to implement a match[] parameter, because that means we would need to re-implement the instant vector selector in Java. Anyways, it should be worthwhile to look into it, so I'm leaving this issue open.