I'm having trouble understanding how data points are being consolidated into an RRA in a particular circumstance. I have 3 counters I want to store in a single RRD (I plan to use a COMPUTE, but I've left it out of this example). The counter data is delivered to me by a router, with 1 counter (ifHCInOctets) being delivered at a different time than the other 2 (greenBytes, redBytes). If I update only ifHCInOctets, or only greenBytes and redBytes, the results are what I expect. However, if I update all three, I get all NaNs. I expected with the xff set to 0.99 that 1 known data point and 1 unknown data point during the step would consolidate into a known data point. Interestingly, if I substitute COUNTER with GAUGE, I get values, so I presume it is a nuance of consolidation with respect to the rate calculation.
Example 1: ---------------- rrdtool create x.rrd -b 1161180810 -s 300 DS:ifHCInOctets:COUNTER:600:0:U DS:greenBytes:COUNTER:600:0:U DS:redBytes:COUNTER:600:0:U RRA:AVERAGE:0.99:1:2304 rrdtool updatev x.rrd -t ifHCInOctets 1161180811:5303133556 rrdtool updatev x.rrd -t greenBytes:redBytes 1161180822:5562882597:0 rrdtool updatev x.rrd -t ifHCInOctets 1161181114:5304677809 rrdtool updatev x.rrd -t greenBytes:redBytes 1161181124:5564615866:0 rrdtool updatev x.rrd -t ifHCInOctets 1161181417:5306928049 rrdtool updatev x.rrd -t greenBytes:redBytes 1161181426:5566896441:0 Output: ----------- return_value = 0 return_value = 0 return_value = 0 [1161180900]RRA[AVERAGE][1]DS[ifHCInOctets] = NaN [1161180900]RRA[AVERAGE][1]DS[greenBytes] = NaN [1161180900]RRA[AVERAGE][1]DS[redBytes] = NaN return_value = 0 return_value = 0 [1161181200]RRA[AVERAGE][1]DS[ifHCInOctets] = NaN [1161181200]RRA[AVERAGE][1]DS[greenBytes] = NaN [1161181200]RRA[AVERAGE][1]DS[redBytes] = NaN return_value = 0 So, I made the assumption that leaving a DS value as "unknown" caused the CF to return NaN regardless of the xff. Following this line of thinking, I set the RRA's CF to MAX instead of AVERAGE, and used 0s in place of the unknown values. This got rid of the NaNs, but introduced another problem. Example 2: ---------------- rrdtool create x.rrd -b 1161180810 -s 300 DS:ifHCInOctets:COUNTER:600:0:U DS:greenBytes:COUNTER:600:0:U DS:redBytes:COUNTER:600:0:U RRA:MAX:0.99:1:2304 rrdtool updatev x.rrd 1161180811:5303133556:0:0 rrdtool updatev x.rrd 1161180822:0:5562882597:0 rrdtool updatev x.rrd 1161181114:5304677809:0:0 rrdtool updatev x.rrd 1161181124:0:5564615866:0 rrdtool updatev x.rrd 1161181417:5306928049:0:0 rrdtool updatev x.rrd 1161181426:0:5566896441:0 Output: ----------- return_value = 0 return_value = 0 return_value = 0 [1161180900]RRA[MAX][1]DS[ifHCInOctets] = 2.0726678730e+17 [1161180900]RRA[MAX][1]DS[greenBytes] = 5.5365785706e+16 [1161180900]RRA[MAX][1]DS[redBytes] = 0.0000000000e+00 return_value = 0 return_value = 0 [1161181200]RRA[MAX][1]DS[ifHCInOctets] = 6.1489146912e+16 [1161181200]RRA[MAX][1]DS[greenBytes] = 6.1013367128e+16 [1161181200]RRA[MAX][1]DS[redBytes] = 0.0000000000e+00 return_value = 0 Those numbers are much larger than I expected. Can someone explain what's going on and, if possible, propose a work-around that keeps the counters in the same RRD so I can add a COMPUTE? I am using rrdtool 1.2.15. Thanks, Jeremy Hough -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://lists.ee.ethz.ch/rrd-users WebAdmin http://lists.ee.ethz.ch/lsg2.cgi
