Built into RRDTool is the ability to guess at whether a counter is 32 bit or 64 bit. This plays into behavior in storing data in RRD files. RRDTool basically tries to evaluate whether if a counter rolls over around 4,294,967,295, then it is likely a 32-bit counter. Otherwise, it is probably a 64-bit counter.
I have seen several Counter32 RRDs begin recording 0.0000000 when it can not properly identify whether a counter is 32-bit or 64-bit. Zenoss seems to bump into this mostly on any data_point that applies the "8,*" RPN function to RRDs with the type Derive and no maximum value listed (I.E. ifInOctets,ifOutOctets). In this instance the counter will not rollover until 34,359,738,360 (4,294,967,295*8). This seems to be outside whatever fudge factor RRDTool implements. Without any other instructions, it assumes that the value is out of bounds and records 0.000000 or "unk". The way to address this is to include a maximum value in the rrd file, to help the RRDTool identify the actual upper limit. Accounting for a little bit of variation when doing math with different levels of precision, I would suggest 34,359,739,000 should be listed as the default MAX value for any data_point that includes the "8,*" RPN function. However, if your RRD file is already created, you would need to use "rrdtool tune" to manually change the max value. The following command updates the max value on an individual file: rrdtool tune /path/to/rrdfile.rrd -a ds0:34359739000 It can be undone by using: rrdtool tune /path/to/rrdfile.rrd -a ds0:U I have only a few switches that periodically bump into this limit. I would appreciate any feedback on whether anyone else who bump into gaps in the ifInOctets and ifOutOctets graphs on whether this fix helps address the issue. -- James D. Roman IT Network Administration Terranet Inc.On contract to: Science Systems and Applications, Inc. _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
