# [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:
[snip]
>  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:
RRA:AVERAGE:0.5:1:600

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:
RRA:AVERAGE:0.5:1:1500

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:
RRA:AVERAGE:0.5:1:10080
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:
RRA:???:0.5:10:1100
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:
RRA:MAX:0.5:10:1100
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.

>   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.

>
>--
>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