On Thu, Apr 19, 2001, Greg A. Woods wrote:
Neither MRTG nor Cricket (nor anything with RRDtool or anything similar underlying it), in their standard released form, are truly suitable for accounting purposes since they both can introduce additional averaging errors. You need to keep all of the original sample data.
The best tool will depend on what type of device is being queried, but in general something like Cricket could provide a decent framework that already draws pretty pictures for visualisation. All you'd need to do is introduce a second call in the collector to send the current samples to some other recording mechanism so that you can save the original sample data separate from the Cricket RRDs. You could simply drop the samples along with a timestamp into a flat file for later processing, or you could immediately insert them into some kind of database. Cricket would be a good starting point because it already has ability to do not just SNMP queries but also the ability to take data from any program. It's also got a half-decent configuration framework.
A little bit of math will show that its actually very feasable to collect and store minutely or 5-minutely data from a router and store them in a database. I've done *that* before, and it works very well.
One thing I should point out is that from an auditing perspective it's fairly important to try and record the time that the counter sample was actually taken. This sample timestamp can be used to assure anyone looking at the data that even if samples are missing the counter deltas between samples are still being used to properly calculate the average rate over the actual sample period.
What? You would consider storing samples without a timestamp? *grin* Adrian -- Adrian Chadd "Two hundred and thirty-three thousand <adrian@creative.net.au> times the speed of light. Dear holy <censored> <censored>"