Re: Polling Bandwidth as an Aggregate

[Jimmy Hess <mysidia () gmail com>]

On Thu, Jan 19, 2012 at 10:48 PM, Dale W. Carder <dwcarder () wisc edu> wrote:

> With the rrdtool backend, you can certainly define and add multiple
> sources from different files together.  Using 'AREA' first and
> subsequently 'STACK' to view multiple data sources is particularly
> nice for visualization.

Except Cacti/RRDTOOL is really just a great visualization tool, while you
can build stacks, it is not something that accurately meters data for
billing purposes.   The right kind of tool to use would be a netflow or
network tap-based billing tool,  that  actually meters/samples specific
datapoints at a specific interval and applies the billing business logic
for reporting based on sampled data points,  instead of  smoothed averages
of approximations.

RRDTOOL is clearly not designed to accurately report on information for
billing.  To a great extent, RRDTOOL   aggregates, averages, interpolates,
smooths  what  it reports.
http://oss.oetiker.ch/rrdtool/tut/rrdtutorial.en.html
See "Data Resampling"

Aggregation could be mitigated by including a large number of data rows at
step=1  while creating the RRD file, eg  for 5 minute polling
1440*(ndays)  data rows; (enough rows to include the whole bill period +
some number of days without aggregating), but not the rest of the issues
with RRD, and including  so many rows greatly increases .rrd file size.
I would look at Torrus or RTG before RRDTOOL for that, but even then...


If data is not gathered using a mechanism that communicates timestamp to
the poller, datapoints will still be imprecise, SNMP would be an example
--  the cacti application may assume the SNMP response is current data, but
possibly on the actual hardware, the internal MIB on the device was
actually updated 10 seconds ago,  which means there will be  small spikes
in traffic rate graphs that do not represent actual spikes in traffic.

--
-JH