[RADIATOR] Prometheus statistics output

Tarko Tikan 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 
working ofc).

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 mailing list