[rrd-users] counter problem

Alex van den Bogaerdt alex at ergens.op.het.net
Wed Jan 31 14:07:25 CET 2007


On Wed, Jan 31, 2007 at 11:47:14AM +0200, Sterpu Victor wrote:
> I'm doing some tests with this rrd database:
> /usr/local/bin/rrdtool create /var/www/rrd/test.rrd --step 60 --start 
> 1862431200 DS:test:DERIVE:600:0:13107200 RRA:AVERAGE:0.5:1:505440
> 
> This database will store taffic in bytes.
> Problem is that from time to time the counter *will go up a lot*.
> I can't solve the problem by setting a smaller max value for the data 
> source.
> 
> I found one solution, but I must ask if there is *a more simple one*.
> Solution for reseting the counter: wait for <heartbeat seconds>.
> After I wait that number of seconds without inserting nothing in the 
> database, the counter will reset.
> 
> So, is there another solution?

try updating with value "U" (unknown).
The interval before your update is undefined, as well as the next update.
If you know you are going to reset your counter, make this second interval
really short:

hh:00:00  regular update
hh:00:50  update U
hh:00:51  update 0        <--- reset happens here
hh:05:00  regular update
hh:10:00  regular update


Question is: why would the value go up a lot ?!?  Normally when a counter
reset happens, it looks like a counter roll over.  RRDtool adds 2^32 to
the (negative) delta, and uses this adjusted value.  HOWEVER: you are
using derive, which can go down as well as up.  So, if your current counter
value is lower than your previous one (which is what happens when it is
reset!) then you should end up with a negative rate, which is then discarded
due to your minimum allowed rate (0).

Can you create an example that I, and others, can try?
Create a script that:
-1- generates a (small) database.  Nothing fancy, just one DS will suffice
-2- does a couple of updates.  Use timestamps, not "N", so everybody should
    get the same results
-3- does a fetch, showing which part has those high numbers


-- 
Alex van den Bogaerdt
http://www.vandenbogaerdt.nl/rrdtool/



More information about the rrd-users mailing list