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:
> > On Wed, 23 Feb 2022 at 20:51, Andy Smith <andy@???> wrote:
> >
> > > - 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.
>
> 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@???
> https://lists.bitfolk.com/mailman/listinfo/users
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
