-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does this crate implement Prometheus or OpenMetrics? #111
Comments
Can you expand in which way recent Prometheus versions are not compatible with the OpenMetrics specification? Note that this has also been discussed in #66 (comment) and in #51. I don't understand why this requires a new GitHub issue. |
Consider a counter metric exported via
Note that the HELP and TYPE lines have metric name "kademlia_exporter_xxx" and that the actual metric data line has a metric name "kadmelia_exporter_xxx_total". This may be valid for OpenMetrics, but it is not valid for Prometheus. Prometheus requires consistent metric names, e.g.
|
Consider this issue a superset of the other issues. OpenMetrics and Prometheus define specs which are not equivalent. If this repo lives in the Prometheus org, it should implement the Prometheus spec. If it doesn't implement the Prometheus spec, then it shouldn't live in the Prometheus org. That's my only point. |
I was also trying to understand why the metrics exported by this crate can't be scraped by Prometheus. In particular, the issue is with the So I think it is confusing indeed that the official Prometheus client doesn't work with Prometheus. I can see the following possible solutions:
Upd: after setting the correct header with the response, Prometheus could parse the output, but it's still confusing that those formats are not compatible and the naming doesn't suggest which one is used. |
@08d2 and @kalabukdima I understand your concerns. @RichiH do you have additional input here as one of the authors of the open metrics specification? How should the Rust client proceed to be consistent within the Prometheus ecosystem. In the meantime, @08d2 and @kalabukdima, how about very prominently calling out on the main docs.rs page (i.e. in |
FYI, OpenMetrics is now part of Prometheus officially I am on the road right now, but this feels like a bug in Prometheus. Potentially dev summit material to discuss? |
Can you point us to some docs @RichiH? Is OpenMetrics the default? Is setting the HTTP content type still needed? Related: #194 and prometheus/prometheus#13944 |
There is a relationship between OpenMetrics and Prometheus, but as far as I understand, they are not the same thing, and are definitely not fully compatible with each other.
lib.rs currently states that this repo is a "Client library implementation of the Open Metrics specification".
If that's true, then I propose that this repo should not exist underneath the prometheus GitHub organization. If it will remain in the prometheus org, then I propose that it should change its mandate such that Prometheus compatibility is the first-order goal, and OpenMetrics is a secondary and e.g. nice-to-have goal.
The text was updated successfully, but these errors were encountered: