[rrd-users] Re: Manipulating and Graphing Data

[Simon Hobson]

Tony Varriale wrote:

>Sorry, I replied to Simon directly...
>
>>  OK, try giving us an example of :
>>  what you put in
>>  what you expect to come out
>>  what you actually get out
>>  and if the latter two are different, why you think it's wrong !
>
>Ok.  I am trying to gather and graph dropped packets in a qos queue on
>multiple cisco platforms.  It looks something like this:
>
>ciscorouter#sh policy-map int sX/X/X:0
>     Class-map: class-default (match-any)
>       33723596 packets, 29789238429 bytes
>       30 second offered rate 95000 bps, drop rate 0 bps
>       Match: any
>       Queueing
>         Flow Based Fair Queueing
>         Maximum Number of Hashed Queues 256
>         (total queued/total drops/no-buffer drops) 0/656712/0
>
>If you look at the last line of that output, you'll see "total drops" is
>currently 656712.  That number will continue to increment at undefined
>intervals and will always go up except after a counter flip.  In 2 hours, it
>may have 0 additional drops...or it may have 100000.
>
>I am inputting the number of 656712 at this snapshot in time.
>
>What I would like to graph is if there are any increases in that number.
>So, if this was my first poll the "base" number is 656712.  On the graph it
>SHOULD represent 0.  Let's say I poll in another 5 minutes (which I do) and
>the number is 656812 (100 additional drops).  I would like to graph 100
>(656812-656712 or current-previous).
>
>What I actually get out depends on the DS type.  When set to gauge, I get
>the actual number of total drops and the graph keeps going up.  The graph
>shows approximately the number of 656712 in the first poll and 656812 in the
>second poll.  Again, the exact number isn't super important as long as I get
>close.
>
>If I set the DS type to COUNTER, DERIVE or anything else, I would get
>something as 0,1,3,0.  I believe I understand why this is the case but it's
>not close to accurate.
>
>Why I think it's wrong?  Well...0,1,3,0 isn't even close to the actual
>"total drops" which is my goal.  When set to GAUGE, it is close and I would
>be happy with that as long as I could take the difference between the
>current value and the previous and graph the difference.
>
>I hope I explained that correctly.

I'm sorry, but you seem to be wanting two different is mutually 
exclusive things. Do you want the graph to show you the rate of drops 
or the total ?

At times you are saying things like :
>   isn't even close to the actual
>"total drops" which is my goal

which suggests you want the total which is always going to be a graph 
that goes up or is horizontal - it will never go down.

At other times you say things like :
>as long as I could take the difference between the
>current value and the previous and graph the difference

which suggests that you want to graph the change - ie rate


Now, I do believe you want to graph the RATE, as in :
>So, if this was my first poll the "base" number is 656712.  On the graph it
>SHOULD represent 0.  Let's say I poll in another 5 minutes (which I do) and
>the number is 656812 (100 additional drops).  I would like to graph 100
>(656812-656712 or current-previous).

I believe that derive is what you want (count would also work). It 
will keep track of the last value fed in, substract it from the next 
value, and after adjusting the data to fit your defined time periods 
will store the rate. If you have defined your rrd as having an 
interval of 5 minutes (300 seconds), and you update on whole 
intervals, then using the numbers I would expect to see 100/300 = 
0.3333 as the result, giving 0, 0.3333, ... If you want drops per 
sampling period (ie 100 in this case) then multiply by 300.

However, you say that you get 0,1,3,0 That doesn't look right, simply 
because those are integer values and RRD does not deal with integers. 
Where did those numbers come from ? Could it be that they are 'wrong' 
simply because they've been rounded (incorrectly since 0.3333 should 
round to 0) ?

Derive DOES work, I have a system at work recording in and out 
traffic on 254 addresses (510 values, and doing some quite pretty 
graphs). The values really do work out correctly.

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-users
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi