[rrd-users] Graphing COUNTER values absolutely

[Simon Hobson]

Felix Castillo Sanchez wrote:

>  > > I'm storing Oracle performance values that are continuously increasing.
>>  The
>>  > problem is that a user cannot handle a per second rate because we're
>>  talking
>>  > about centiseconds within 5 minutes. So how do I explain an end user
>>  that
>>  > sub-microseconds of wait time can be a performance bottleneck?!
>>
>>  Why do you think that it is easier to explain when you multiply
>>  the number by some arbitrary value?
>
>I don't want an arbitrary value - I want to have the rate per second
>multiplied by the seconds that lie between the data points.

Do you mean between fixed intervals (eg every 5 minutes), or between 
arbitrary points (eg last changes occurred at 12:04:01, 12:04:07, 
12:10:57) ?

If it's the former, then simply multiply the stored rate by 300 and 
you have '<somethings> per 5 minute period'.

If it's the latter then rrd is not the right tool for the job.



To expand on that a bit.


Taking the fixed intervals case, suppose that you last samples were 
0, 5, 10, and 15 - all at exactly 300 second intervals. The rate is 
'5/300 <somethings>/second', or '300 * 5/300 <somethings>/5minute 
period'.



Taking the second case, then I think what you are looking at is a 
bunch of <somethings> happened at 12:04:01 then nothing until 
12:04:07 when another bunch of <somethings> happened. Then a gap 
until 10:10:57 when another bunch happened. You then want to be able 
to show a user that "you did <x>, the result was that <y somethings> 
happened while the system was processing job <x>". RRD will NOT store 
this information<period> It isn't what it's designed to do.

If each bunch was 5 events, and an update was triggered at each 
event, and the step size was 5 minutes, then in the period 12:00:00 
to 12:05:00 it would store :
- whatever came before 12:04:01 (we'll assume zero for now)
- plus 5 events between 12:04:01 and 12:04:07
- plus 53/(53+300+57) * 5 between 12:04:07 and 12:05:00

All this combined would store a rate of 5.64634145/300s or 0.018821138/s


for 10:05:00 to 12:10:00 it would store a rate of 300/(53+300+57) * 5 
or 3.6585366/300s or 0.012195122/s


the remaining 57/(53+300+57)*5 would go into the 12:10:00 to 12:15:00 
bin together with a fraction of future updates.


See the tutorials on data normalisation (see the rrdtool website) for 
more details.