[rrd-users] Re: Calculating traffic

Thomas Erskine erskine at sourceworks.com
Thu Jun 27 19:32:53 MEST 2002

Hi Iñaki.
At 14:30 2002-06-27 +0200, Iñaki Martínez wrote:
>  Ok... i MUST CHANGE ALL!!!!!
>  But i am too confussed now to know/calculate the values.
>  Can you help me with this????
>  If i want to make this kind of graphs:
>  graph of 1 hour (last one)
>  graph of 2 hours (last one)
>  graph of 1 day (last one)
>  graph of 1 week (last one)
>  graph of 1 month (last one)
>  graph of 1 year (last one)
>  graph of 2 years (last ones)
>  graph of 1 year (1 year ago)
>  graph of 1 year (2 year ago)
>  graph of 1 year (3 year ago)
>  graph of 1 year (4 year ago)
>  graph of 1 year (5 year ago)

There are two other pieces of information to consider when deciding how 
much data to keep at which resolutions:
         - the step time
         - the graph image size

Say you're using an RRA like:

Unless you know the step time, you don't know what time-period the 600 
values cover.  Say we use your suggested step of 60 (which is probably 
overkill).  Then we know the time-span covered: 600 * 60 = 36000 seconds or 
10 hours.  So for any time in the last 10 hours, we can get the 
best-resolution data.  This covers your first two graphs (1-hour and 
2-hour), and I'll ignore the image size since, ...

To cover the 1-day graph, we want to arrange things so that we have data at 
the same (or a bit better) resolution as the image.  Say the image is 
800x200 (width x height); only the width (time-axis) matters.  So to make 
sure that we've got data which won't look stepped, we want to have 
data-points every
         day (your time-span to be covered) / 800 (the image size) = 
60*60*24 / 800 = 108 seconds

Given that your base resolution is one data-point every 60 seconds, we're 
not going to get that resolution (1 point / 108 seconds) by consolidation, 
so we need to extend the first RRA to cover that time-period.  I.E. we need 
one-day coverage, sampled every 60 seconds = 60*24 = 1440.  Add a bit extra 
to make sure that the whole day is covered,  so change the first RRA to:

For the 1-week graph, we need to cover 60*60*24*7 = 604800 seconds.  For 
the same size graph, we need data every 604800 / 800 = 756 seconds.  There 
are two ways to cover this.  The simple way is to just extend the original 
RRA again to cover one week:
That's overkill, because we don't really need that resolution of data for 
that long.  The better way is to make a consolidation RRA.  We need data 
every 756 seconds, so we need to consolidate 756 / 60 (step time) = 12 
points per consolidated point; say 10.  We still need to cover a week with 
this: one week worth of consolidated points is 60*60*24*7 (a week) / 
60(step time) / 10 (consolidated points) = 1008; say 1100 for a bit 
more.  So the RRA looks like:
Note the "???" I put in instead of the consolidation function.  Now we have 
to think about our data.  If averages are good enough, then put in AVERAGE 
for the cf and have done.  However, if you want to be able to show _real_ 
maximum values over this period, that won't cut it.  The problem is that 
the consolidation takes 10 of the original values and averages them to 
create one new value.  If you ask for the maximum over this time-period, 
with only an AVERAGE RRA, then what you're really getting the the maximum 
of the averaged values.  It's fine if you want smoothed values, but it 
isn't the maximum.  For that, you need to have another RRA:
Whenever you want to show a maximum value, you'll need to make sure that 
you're doing your LINE1 or GPRINT or whatever, using MAX.

The other graphs are left as an exercise for the reader. :-)  The only ones 
that are slightly different are the last-year, year-before, ... 
graphs.  All these do is require the same data resolution as the this-year 
graph, for longer periods.

>  these graphs are about:
>   servers: swap, ram, processes, ethernet, partitions, cpus, ...
>   switchs: ports, ...

Doesn't matter what they are, just how much you need to keep.

>Now i have the following
>(all rrd files have the same values in step, heartbeat and RRA,
>  DS has diferent names and DST is diferent for Ethernet):
>rrdtool create XXXX.rrd --step 60 \
>   DS:in:GAUGE:600:U:U             \
>   DS:out:GAUGE:600:U:U            \
>   RRA:AVERAGE:0.5:1:600           \
>   RRA:AVERAGE:0.5:6:700           \
>   RRA:AVERAGE:0.5:24:775          \
>   RRA:AVERAGE:0.5:288:3725        \
>   RRA:MAX:0.5:1:1:600             \
>   RRA:MAX:0.5:6:700               \
>   RRA:MAX:0.5:24:775              \
>   RRA:MAX:0.5:288:3725
>  The IMPORTANT questions (with the information above):
>  * how many RRAs and with which values must i use???
>  * What hearbeat and step values are the correct????

The step time is how often you will be updating the RRD.  The "correct" 
value for the heartbeat depends on the data and personal preference.  If 
you set the step and the heartbeat the same then there will be a hole 
(missing data) wherever you fail to update the RRA.  If you set the 
heartbeat to twice the step time, then you can skip every second update and 
it will fake the missing data.

>  NOTA: i get data each minute.

Yes.  Why?  If you've got only a few hosts to manage, this is do-able, 
though it gets more difficult to scale it up to lots of hosts.  But my real 
question is: what do you get, that you really need, from a 60 second step 
time, that you wouldn't get from a 300 second step time?  The only thing I 
can think of is the ability to see short-duration spikes.  Which often 
aren't interesting.  Sometimes they even get in the way of seeing what's 
really happening, if there are lots of spikes.

>  Thanks in advance.......
>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://www.ee.ethz.ch/~slist/rrd-users
>WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

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://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

More information about the rrd-users mailing list