This is a discussion on [rrd-users] Re: Manipulating and Graphing Data within the RRD Users forums, part of the Networking and Network Related category; Tony Varriale wrote: > Why I think it's wrong? Well...0,1,3,0 isn't even close to ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Tony Varriale wrote:
> 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. Okay, maybe I can help here with an example from OpenNMS. The value you are trying to graph is a counter. This is a value that increases over time yet one is interested in the delta or change between two values and not the actual value at any given time. RRDtool handles counters quite well. Now, as Alex mentioned, everything in RRDtool is a rate. You want to measure "total drops". That is not a rate. Hence, it can not stored directly via RRDtool. However, if you have "drops per second" and "total seconds" it *is* possible to calculate "total drops" by multiplying the numbers together. For example. With OpenNMS we collect the counter ifInOctets (the number of bytes inbound on a network interface). By default we do this every 300 seconds and we store that value in an RRA with a step of 300 seconds. We store the average value but since we are only storing one value per step it will be the value collected (subject to the NOTE below). So just suppose that I get the value of the counter and it is 100, and 300 seconds later I get the counter and it is 400, for a difference of 300. When I go to store that value in RRDtool it will be stored as a 1 (since 300 octets/300 seconds is 1 octet/sec). It *must* be stored as a rate because that's what RRDtool does. Now we have users who want a number that shows how many bits went by in a certain time period. First a calculate the rate in terms of bits: CDEF:bitsIn=octIn,8,* Then in order to calculate the total number of bits I have to multiply that value by the timespan of the graph: CDEF:inSum=bitsIn,{diffTime},* The {diffTime} is something that OpenNMS will pass to RRDtool and it represents the end time minus the start time for the graph in seconds. I then print out that value: GPRINT:inSum:AVERAGE:" Tot In \\: %8.2lf %s" Now, in your case you will need to find a way to come up with your own {diffTime}. There are a number of ways to do this and you will probably end up using something outside of RRDtool unless all of your graphs have a fixed time range. NOTE: As I mentioned above, if you try to store one value per step that value should be the actual value collected. However, in practice that is much harder than it seems to do perfectly all of the time. In any automated system there will be some "drift" as the time to collect and write the data can not be a perfect 300 seconds all of the time. Then you may find yourself writing two values into one step and they will be consolidated. However, your requirement was for a number that is "close" and not perfect so you may be able to do this. HTH, -T -- Tarus Balog The OpenNMS Group, Inc. Main : +1 919 533 0160 Fax: +1 503-961-7746 Direct: +1 919 647 4749 Skype: tarusb Key Fingerprint: 8945 8521 9771 FEC9 5481 512B FECA 11D2 FD82 B45C -- Unsubscribe mailto:rrd-users-request@list.ee.ethz.ch?subject=unsubscribe Help mailto:rrd-users-request@list.ee.ethz.ch?subject=help Archive http://lists.ee.ethz.ch/rrd-users WebAdmin http://lists.ee.ethz.ch/lsg2.cgi |
![]() |
| Thread Tools | |
| Display Modes | |
|
|