[rrd-users] problems with rrd and check_traffic

Simon Hobson linux at thehobsons.co.uk
Wed Apr 4 17:25:23 CEST 2007


Henrique Silveira Cadore wrote:

>The graphic generated shows me the average each 5 minutes. shouldnt 
>it be every minute since im updating the database every minute?

No, I suggest you try and understand what rrd is doing for you. 
Specifically, except under certain very specific circumstances you do 
NOT get out what you put in.


I does not matter how often you update, the rrd only contains a 
simgle data point for each <step> of time, in this case 5 minutes. No 
matter how frequently, or infrequently, you provide data, it is 
always normalised to these <step> sized sample periods. To give a 
very simple example, suppose you have a step size of 5 minutes (300s) 
and update every 2 minutes (120s), not ideal but it shows a couple of 
points. Further, lets assume you are able to provide the updates when 
the time (seconds since epoch) is an exact multiple of 120 seconds.

You need to be using a fixed pitch font for this :

Update   x   a   b   c   d   e   f
Store    |         |         |

The first 2 samples (a & b) plus half of the third (c) will be used 
for the first stored interval, the other half of sample c plus the 
next 2 samples (d & e will be used for the next interval, and so on. 
If the data is at a constant rate of 1/second then your updates would 
go like this :

Update a : rate is 1, so 120 (1/s x 120s) is added to the temporary store.
Update b : rate is 1, so 120 (again 1/s x 120s) is added to the store.
Update c : rate is still 1, but this time only 60 (1/s x 60s) is 
added to the store to give a total of 300, this is divided by 300 to 
get 1/s which is entered into the appropriate slot in the rrd. The 
other 60 is then placed in the store having first removed the 300 
from the previous time slot.

If the rate is increasing, you might have the following :
update a : rate is 2/s, so add 240 (2/s * 120s)
update b : rate is 3/s, so add 360
update c : rate is 4/s. Add 240 (4/s * 60s) to get 840, divide by 300 
to get 2.8 which goes into the rrd, finally put the other 240 into 
the store.

Note that other than the internal accumulator used in the 
normalisation process, the values you feed it are never stored 
directly into the RRD.


That's what the rrd contains, but it doesn't have to be what if 
graphed. You could take that rrd and graph it with an interval of 10 
minutes/step, and assuming you ask for average, then each pair of 
samples will be averaged and plotted as one point. It is not even 
essential to have the graph as an integer multiple of the sample 
period, the program will apply a similar normalisation process to 
match the stored data to points on the graph - but obviously every 
such transform is going to further obscure the original data points 
fed in.


If you can understand this fundamental different from an 'ordinary' 
database then you will better understand how to get the right results 
out.



More information about the rrd-users mailing list