95th billing and automation

Thu Dec 10 19:38:30 UTC 2020

 'cacti' isn't really a monolithic thing. Ultimately it's a gui front end
for rra files and rrdtool. If one chooses not to go down the route of disk
space intensive but lossless time series database interface metric storage
(influxdb or similar), we are talking about what level of detail is lost
over the week and month scales in an rra file.

The step settings and compression-over-time for the rra file, defined when
its first created, will affect precision as well as the poller interval. An
older default cacti install with 5 minute intervals and small rra files
(under 500KB max size for the whole time scale per single interface and
file) will look very different than on a cacti 1.2+ install set up for 1
minute poller intervals. If you do a new cacti install on Debian testing or
unstable, during the initial configuration process you'll have the options
to define these. The difference between the two is best seen on some sort
of circuit that sees lots of very brief bursty high Mbps/Gbps traffic.

In 2020 considering the low cost of disk space I would recommend something
time series database storage based, polled on 60s intervals for interface
bps. Even if each discrete 95th billed interface eats up several hundred MB
of disk space. You can always set up something later on, to truncate the
time series db to throw away all data older than 12 months.

On Thu, Dec 10, 2020, 10:29 AM Mehmet Akcin <mehmet at akcin.net> wrote:

> hi there,
>
> i have asked about this in the past. What is the best tool out there to do
> 95th percentile billing. I have decided to use observium and librenms as
> result of responses but there seems to be some kind of billing module issue
> with these tools (thy are basically the same code).
>
> What are other systems besides observium and librenms (and old
> fashion cacti) people are using these days with 95th billing and
> integration with a CRM like salesforce/zoho, etc. I appreciate the
> responses.
>
> Mehmet
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201210/b13804b4/attachment.html>