24 Feb
2022
24 Feb
'22
8:58 a.m.
On Thu, 2022-02-24 at 00:09 +0000, Andy Smith wrote:
Hi Roger,
On Wed, Feb 23, 2022 at 11:37:40PM +0000, Roger Light wrote:
Hi,
I totally forgot I asked it before. Re-reading the thread from 2 years
ago, it seemed to have gone down quite a rabbit hole then.
My focus wasn't on API design or authentication mechanisms - I would
not expect that.
In response to "use the counters on your vps" - I think it is worth
diving into a few details I am dealing with:
1)
The charges incurred (which is what I care about), are not related to
bandwidth but to bytes transmitted/received within a given period.
This means, any tool that I set up needs to be customised for bitfolk.
Specifically, at the very least, it needs to be configured to match the
billing period _exactly_ and reset the predictions at the appropriate
dates.
2)
Also, there is a slight, and quite theoretical discrepancy on what can
be observed on the VPS vs what is counted on the border routers.
Any encapsulation that is stripped by the host or added by the host my
VPS runs on, won't be counted as part of the VPS counters.
3) Whilst the VPS reboots, it won't be able to count the traffic,
whereas bitfolks systems continue to count the traffic. Traffic
received/transmitted during that time cannot be counted in my own
monitoring.
4) Somewhat "invalid" packets that arrive in the host or router but
don't make it to my VPS because they are being filtered on the way for
whatever reason, won't be counted in my stats either. (thinking DoS)
5) In case of the VPS misbehaving, because of an upgrade or software
failure or external attack, the counters on the VPS are no longer a
*reliable* source (I did experience that case before, so for me this
isn't just theoretical).
I _do_ count the traffic, but for the reasons mentioned above it is
less than ideal. It does work well for *most* cases, but clearly once
every 2 years or so it does not :)
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.
if there were metrics (gauges) "traffic_predicted" and
"traffic_contracted", it would be trivial for me to query bitfolks'
prometheus to poll that regularly.
This would be a perfectly suitable API for my purposes and perhaps much
simpler to implement?
This would be preferable (IMHO) to a plugin in icinga, because
prometheus already has a well-defined API, icinga less so (afaik), that
I can use if I (or anyone else) wish(es) to do so ;)
Thanks Andy for your patience (again),
Conrad
On Wed, 23 Feb 2022 at 20:51, Andy Smith
<andy(a)bitfolk.com> wrote:
It reads like you actually don't agree with me. What I was trying to
say was that I expect customers to actually be able to measure
their own bandwidth usage, and BitFolk telling them that they are
near or over quota is just a courtesy.
What you are saying is that you don't expect to have to measure
this yourself, you would never be aware of it or investigate it
without a notification from BitFolk and therefore these
notifications are essential to you. You did get the notification and
were able to take action, but only because email notifications
are satisfactory for you.
If most people are the same then this means that receiving and being
able to act upon these notifications isn't just a courtesy, it is
essential. The fact that you were able to is great, but the fact
that others aren't is of concern to me.
Conrad was saying that they do have their own monitoring but that
the email notifications and the figures on the panel web page aren't
satisfactory because they are hard to be aware of (emails get
overlooked) and don't provide easy spot checks.
Is there any middle ground that could improve things for you,
Conrad, without me having to make an HTTP endpoint that gives these
figures?
For example, I could probably plug it in to our Icinga monitoring¹
so that it continually gave you a WARNING email when predicted to
exceed, turning into a CRITICAL when it actually has. Besides email,
our Icinga can also do Pushover² alerts, and I am open to adding
more kinds of alerts there.
Even if that does not work for Conrad, it might be a better
interface for more people so I would be interested in feed back on
that or other ideas.
One of my big problems with the API thing is that I feel like it
will have a very limited audience, very likely at this point to be
only Conrad. I currently manage four Linodes for various reasons and
although Linode has an API I've never felt a need to use it myself.
I monitor my own bandwidth usage. I do often find myself at odds
with others though.
Cheers,
Andy
¹ https://tools.bitfolk.com/wiki/Monitoring
² https://pushover.net/
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users - The rare times that people do go over their
quota they tend to
focus on BitFolk's measurements of this instead of looking into
the behaviour of their own VM. I feel like anything I implement
is
just going to be a further distraction from the customer's own
responsibilities.
This matches my experience. I pay reasonable attention to the quota
emails but don't do any monitoring myself because I don't expect to
be
at any risk of going over the quota. From a customer perspective
though, I expect the measurements made by bitfolk to be the gold
standard in terms of billing so my measurements would ultimately be
secondary.