[EMAIL PROTECTED] writes: > On Fri, Oct 03, 2003 at 01:47:13PM +1000, [EMAIL PROTECTED] wrote: >> Use 64 bit counters where possible (ifHCInOctets). Collecting >> ifOperStatus, ifLastChange and sysUptime helps you distinguish between >> certain events, ie counters resetting due to a reboot. Program the speed >> of the interface in to your app so you can detect obviously wrong data. >> Take in to account network and cpu load, plus how frequent counters >> could wrap when deciding how often to poll. > > The rrdtool COUNTER type handles wrapping. Dunno about unexpected > outages.
I just checked the docs, they recommend using DERIVE, not COUNTER. But for people using COUNTER, there is an snmp-uptime setting, and if the uptime is less than the poll interval, it assumes a reboot. But uptime counters wrap occasionally, so... rrd or cricket seems to handle most spikes, but not all, hence spikekill or killspike, whatever it's called. And if such a widely used program like rrd occasionally gets it wrong, it can't be an easy thing to get right. But I was mainly talking about rolling your own NMS without rrd. > For me, rrdtool/cricket/ and the other stuff in the rrdworld links > page on rrdtool.org promise easy monitoring and beautiful graphs > in minutes, but the reality is lot of staring hard at manuals and > fiddling with scripts. I find cricket and the like are excellent for fault finding, and genRtrConfig makes life easy, but cricket doesn't do billing or overview type reports. rtg is suitable for both, but its a shame it doesn't use a standard database interface. At the moment I'm using cricket with copy-to, but you lose all the benefits of rrd with copy-to, you basically have to reinvent it. -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
