[mrtg] Re: New Idea

Alex van den Bogaerdt alex at slot.hollandcasino.nl
Wed Aug 30 21:49:04 MEST 2000


Shawn Barnhart wrote:
> From: "Denis Ahrens" <ahrens at pixelpark.com>
> > I use mrtg to monitor some ups devices. The graph shows two straight
> > lines in the the range from 230 to 235 volt. What I dont like is, that
> > windows shows the range from 0 to 240. I could see the two graphs better
> > if the window would show only the range from 300 - 340 or something near
> > the minimum and maximum values.
> > So my idea is a new config keyword, maybe rangepercent.
> 
> I'd prefer to see a "MinBytes" keyword which would do the opposite of
> MaxBytes.  I think this would accomplish what you're looking for.  By
> setting a ceiling and a floor for your values, you'd only show a graph of
> what's in the middle.

You're confusing graphing with collecting data.

MRTG will consider values above MaxBytes to be faulty (if AbsMax is not
used) and therefore MinBytes (if available) would do similar: reject
values below MinBytes (and of course, AbsMin).

If you trow away values above MaxBytes, graphing may seem to be okay but
what about your maximum and average?

Using AbsMax is no help here.  It will still show values above MaxBytes
while screwing up the averages.

> On a somewhat related note, I've been graphing some squid snmp values and
> what's kind of annoying (and this is maybe a squid thing as much as anything
> else) is that when no one's at work the values naturally drop to 0, but it
> makes the week/month/year averages (and graphs) totally distorted because
> the min value is always 0.

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

If you only want to see 9am 'till 5pm, you should only create a graph at
5pm (exactly) and make the graphs x-size 96 pixels. (96*5min==8h)

> My fix for this would be a TimeRange[] keyword which would accept a GMT time
> range that the target should be polled.  Once you had a handle on when your
> targets generated nonsense values you could omit those times. This would be
> trivial to accomplish through cron, although I'd prefer it in mrtg..

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.

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



More information about the mrtg mailing list