[mrtg] Re: Weekly Max Greater than Daily

Alex van den Bogaerdt alex at ergens.op.HET.NET
Wed Aug 14 01:55:40 MEST 2002

Jim McAtee wrote:

> > The reason for this behaviour is, I guess, that the maximum and
> > average values are expected to be the same for the daily part of
> > the .log file.  As you can see, it isn't *exactly* the same.
> > This has to do with normalization (see faq site).


> Alex,
> Thanks for pointing me toward the FAQ and the discussion of normalization.
> It would seem that no normalization would be desirable for this type of data
> (ie, the max values, or colums 3/4 should always be exactly the same as
> columns 1/2.

Normalization is a required part of both MRTG and RRDtool.  It is
how it works.  There's no way to avoid it.  You can make it do
nothing by making sure the values are already in the correct
timeslot.  If you don't do that, MRTG will do it for you and
doing so it will recompute the *rate* you are inserting.

> In configuring these monitors I followed the example included with the
> pmlines.pl script and set Options: gauge, absolute.  The goal of the script
> (if you're unfamiliar with it) is simply to graph the number of phone lines
> in use at any point in time.

s/any/a given/

Using MRTG for this is like using a screwdriver to hammer a nail.
Don't complain if the screwdriver doesn't work entirely as you
expect it to do.

Specifying gauge *and* absolute for one target is like saying you
should take the next turn both left *and* right at the same time.

In the source:
    # select whether the datasource gives relative or absolte return values.
    my $up_abs="u";
    $up_abs='a' if defined $$rcfg{'options'}{'absolute'}{$router};
    $up_abs='g' if defined $$rcfg{'options'}{'gauge'}{$router};

I guess "gauge" overrides "absolute", at least for this version.

> From reading the configuration file documentation, it seems that the gauge
> option is desirable for this type of monitoring.  I'm not so sure about
> combining 'gauge with 'absolute', however.  It seems that for a "gauge", you
> would perform no normalization, since you're not tracking a rate.  Do you

You are *always* tracking a rate (as far as MRTG is concerned).

Gauge    == this is already a rate
Absolute == compute rate so: dividing current value by time lapsed
Counter  == compute rate so: dividing difference in the values by
                             time lapsed

*After* the value has been transformed into a rate (nothing to do
for gauge) the rate is normalized.  At this point, MRTG doesn't
know nor care what kind of input it received.

Normalizing a rate valid from n*300 to (n+1)*300 is a no-op. This
means you have to make sure both the previous update time and the
current update time are exactly at 5-minute intervals, then you
will keep the same rate as you enter.  This is hard (but not
impossible) to do with MRTG.  It is more easy by calling rateup
yourself, it is even more easy (because of better docs) to do
this with RRDtool.

Entering rates at any other time (such as n*300+1) will cause
normalizing to happen.

I think you missed it so here's a link right into the guthers
of the faq, pay extra attention to "gauge" and "resampling":


 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
| Technical questions sent directly to me will be nuked. Use the list. | 
| http://faq.mrtg.org/                                                 |
| http://rrdtool.eu.org  --> tutorial                                  |

Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

More information about the mrtg mailing list