Polling Bandwidth as an Aggregate
mysidia at gmail.com
Fri Jan 20 00:16:14 CST 2012
On Thu, Jan 19, 2012 at 10:48 PM, Dale W. Carder <dwcarder at 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
RRDTOOL is clearly not designed to accurately report on information for
billing. To a great extent, RRDTOOL aggregates, averages, interpolates,
smooths what it reports.
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.
More information about the NANOG