On Thu, 2022-02-24 at 13:39 +0000, Andy Smith wrote:
Hi Conrad,
On Thu, Feb 24, 2022 at 08:58:49AM +0000, Conrad Wood wrote:
One of the ways I could see this working -
without having to create
a
new API - is to expose it as a metric in bitfolks
grafana/prometheus.
Okay. I will have a think about this. If it can go in to Icinga then
it can go in to Prometheus.
if there were metrics (gauges)
"traffic_predicted" and
"traffic_contracted", it would be trivial for me to query bitfolks'
prometheus to poll that regularly.
Can do say:
data_transferred_in
data_transferred_out
data_predicted_in
data_predicted_out
data_contracted_in
data_contracted_out
I guess they should be in bytes as Prometheus usually wants the base
unit.
What about the start and end times of the current period? Provided
as unix timestamps?
Thanks Andy for your patience (again),
No worries. Thanks for bringing it up on the list as it's useful to
see what other people think too.
Cheers,
Andy
Hi,
That would be very nice. The metrics you suggest will work for me.
I do scrape it from the website now as suggested by Tony (thanks again)
in this thread, but web-scraping does have a few caveats, so pulling
them from prometheus would be nicer.
As for the metrics, I now (as of this morning) put the result from the
web scrapes into my prometheus like so:
bitfolk_network_usage_bytes_current{vps="xxx",direction="in|out"}
bitfolk_network_usage_bytes_predicted{vps="xxx",direction="in|out"}
bitfolk_network_usage_bytes_max{vps="xxx",direction="in|out"}
The choice of labels means I only need a single alert for all VPS' I
monitor and for any direction (in and out):
"bitfolk_network_usage_bytes_predicted >
bitfolk_network_usage_bytes_max"
Of course, the "bitfolk_" prefix is entirely optional on bitfolks'
prometheus.
The above labels lend themselves quite well to alert on absent metrics
as well, should one want to do so.
I don't think the start and end period times are required, as long as
"predicted" and "max" values are provided.
Thanks,
Conrad