[mrtg] Re: New Idea

[Alex van den Bogaerdt]

Shawn Barnhart wrote:

> > You're confusing graphing with collecting data.
> 
> Perhaps, but I'm using the collection of data to control what gets graphed.
> If there were controls for graphing behavior relative to numerical values,
> I'd use them instead.

If you know the implications, go ahead.  If you advise a novice user,
telling only part of the truth is (IMHO) like lying, especially in those
cases where you use a side effect of something.

You are presenting a side effect as a solution, without telling the real,
intended and perhaps unwanted intended effect of that option.

> > If you trow away values above MaxBytes, graphing may seem to be okay but
> > what about your maximum and average?
> 
> You're right it would trash those values, but it doesn't seem to stop us
> from having or using MaxBytes, does it?

That is because it is necessary.  You are abusing it for something it
was not designed for.  Again, if you understand the mechanism, go ahead.

> I guess what I'd like is a way to constrain the graphing between two values.
> For whatever the reason there seem to be things that have a large absolute
> operational range (say 0...1000) but where the interest and operational
> variance is really between some subset of that range (say, 900-950).

Right.  This doesn't mean that you can discard values outside that range,
however using MaxBytes (and MinBytes if it would be available) will discard
those values.

MRTG plots from 0 to maximum.  If you want something else, use something
else.  May I suggest RRDtool?  It integrates into MRTG.  Create your own
graphing script (which is not *too* hard to do) and you can do anything
you like without messing with your data.

> > This is reality.  You're monitoring reality.  If you're graphing a full
> day
> > while your bandwidth is utilized fully during 8 hours and zero during the
> > other 16 hours, the average MUST be 33.3333... %
> 
> It's mathematically correct but in terms of practical reality its nonsense,
> because I'm not concerned with those other hours.  They distort the view of
> the 8 hours.

They don't. You don't view 8 hours...  You deleted my remark about that
so here it is again:  if you want to see 8 business hours, create the
graph at (for example) 5pm and make sure the width of the graph is
exactly 8 hours.  Each pixel will be 5 minutes, 8 hours is 8*60 minutes,
8*60/5==8*12 --> width == 96 pixels.

> > Why do you think this is trivial.  Are you using MRTG for a long time and
> > did you read (not: browse through) the mail list archive?
> > I don't say it's not doable but it certainly is not trivial.
> 
> I'm sure its not trivial to do via mrtg, but its trivial through cron.  Just
> run mrtg against the targets of interest during the hours of interest via
> cron.  What part of the archive or mail list did I miss that tells me that
> this won't work?

MRTG remembers the last known rate.  It will use that during the
outage.  The "other" hours will therefore show a data rate that isn't
correct and also might not be zero.  When the MRTG process is run again,
the complete graph will be made, including the time where cron did not
start MRTG.  You gain nothing and loose precision...

-- 
   __________________________________________________________________
 / 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 |
+----------------------------------------------------------------------+
| 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