[RADIATOR] Prometheus statistics output
tarko at lanparty.ee
Tue Dec 31 15:46:56 UTC 2019
> A quick question: Would exporting metrics be preferred over pushing
> metrics even when Radiator already supports StatsLog FILE with JSON output?
Correct. It's best to get up-to-date metrics at the time of the scrape,
all other solutions like writing to files and scraping later time or
using pushgateway are just hacks (but they do work if done correctly).
> It seems that JSON is not directly usable, but would require a separate
> exporter too. Builtin exporter is certainly possible, but I thought I'd
> check that you had noticed the already existing JSON support.
Correct, I mentioned it because JSON is directly parseable without any
quirks. Separate exporter is still required.
> I see that Prometheus docs advocate a built-in exporter, for example,
> for storing 'up' metric directly based on queried instance responses.
Yeah, builtin exporter is the best because up metric will then show if
the actual scrape was successful. Other solutions will hide the actual
state of the radiator process.
One of course needs to keep in mind that successful scrape does not
necessarily show the actual state of the service (radius with SQL
backend is quite useless if the SQL is down but radiusd will keep
Even more important is that you get the metric values at the time of the
scrape (as the builtin exporter will read directly from statistics data
structures). This is ofc also true if out-of-process exporter queries
radiator via SNMP or other means during the HTTP scrape request and then
returns the metrics.
HNY to everyone now and I'll return to this when I'm back at the office
next week. It has been a while since I wrote real perl and I didn't find
any stdlib HTTP servers now during quick search. As radiator today
already requires you to have additional dependencies when you activate
functionality, it should not be too big of a deal.
More information about the radiator