auth: Prometheus statistics endpoint #4947
Comments
I'd be in favour of it - right now getting stats is either push (carbon) or non-standard pull (rec_control/pdns_control or custom json over http api). |
@pieterlexis can you fix the first sentence? I can't make sense of it :) |
Hasn't anybody already written a localhost carbon listener that remembers what it heard and can then serve it over HTTP? |
My Eur 0.02, It'd be nice if it supported json stats, with a json schema. There's not a lot of non-go software that has native prometheus support. But it's not an unreadable / unreasonable way to expose your metrics. You're already serving a webserver, its just a small change exposing the same data in a format thats machine parsable. There is another project that reads the current exposed json metrics. It probably works fine, but it would be nice if the metrics are clear, concise, named properly, etc. Make it suck a little less. Then we should try and get knot, unbound, bind to do the same. Snmp is obviously not the way forward :-) Thanks! |
Please, yes, add native Prometheus metrics! Running separate exporters is such a PITA, especially if they're not actively maintained or have errors in their implementation. |
Is there any chance to have this feature implemented? |
Already fixed in #6901 ! |
But that PR only addresses dnsdist, not either of the pdns daemons? |
I misread [discussion] as [dnsdist] in the title, my bad! |
This would be very handy, especially now that both incarnations of powerdns_exporter are broken with pdns 4.2 (mixed string/array value types in statistics API) |
I'd like to again express my immense interest in seeing auth also providing prometheus metrics, now that the recursor and dnsdist already do! <3 |
@pieterlexis Any chance of squeezing this FR into Auth 4.3? Pretty please! |
We managed to completely forget about this in the process towards auth-4.3.0. I have now milestoned it auth-4.4.0 (instead of dnsdist-helpneeded) so it's not so easy to miss. I cannot promise we will squeeze it into 4.3.x at some point, but we might. |
Thanks, that is already awesome news! <3 |
+1 Having prometheus endpoint would be awesome! |
Are metric and label names defined at least for auth? We're implementing our own solution for scraping stats, would be nice to know we wouldn't need to relabel once it's out. |
@administratorius Maybe have a look at the metric names of pdns-recursor and how they're exported on the Prometheus endpoint, then compare those to the metric names in pdns-auth. https://doc.powerdns.com/recursor/metrics.html |
@jangrewe yes, this is excellent advice! |
Thanks @Habbie, looking forward to the next alpha/beta/RC :-) |
Short description
Prometheus is a statistics collector that pulls metrics over HTTP(S). The format to be returned is quite simple and adding new metrics is trivial.
The question is: Do we want to implement a prometheus endpoint (path) in the built-in webserver, or will we only support carbon output and all other outputs by means of 3rd party programs?
See also #3935.
The text was updated successfully, but these errors were encountered: