hey,
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.
-- tarko _______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
