well, i have more info now. and it is more confusing than ever. since zenoss is using an rrd type of derive instead of counter, all counter wraps should be recorded as unknown/nan, but this doesn't happen all the time. if the zenperf daemon is running such that the samples come between the natural 5 minute marks (like at 2. 7, 12, etc), then it records nan when the counter wraps. but if it is running pretty much on the 5 minute marks (5, 10, 15, etc) then it seems to cope with the wraps (although the rrd derived values don't make as much sense). it appears that the rrd magic to realign data to the natural 5 minute marks has varying behaviour based on where it falls between the natural timepoints.
so there appear to be 3 ways to deal with this issue. 1. create templates to allow 64 bit counters to be used. it would be nice if zenoss could do some kind of *_64 match. i'm going to dig into the code to see how hard it would be to do that mapping. 2. change ethercsmacd template to use counter. the reason for using derive instead of counter does not apply to everyone. if your link speed is fast but not too fast and doesn't reset randomly, then counter should be fine. 3. make sure zenperf is running close to the 5 minute mark. that last one is still perplexing me. _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
