[mrtg] Re: Peaks Crush Graphs

[Jim McAtee]

----- Original Message ----- 
From: "Jay Hennigan" <jay at west.net>
To: "Jim McAtee" <jmcatee at mediaodyssey.com>
Cc: <mrtg at list.ee.ethz.ch>
Sent: Saturday, October 09, 2004 3:42 PM
Subject: [mrtg] Re: Peaks Crush Graphs


> On Sat, 9 Oct 2004, Jim McAtee wrote:
>
>> I'm monitoring bandwidth on a 10 Mbps circuit which typically runs well
>> under 1 Mbps.  Every once in a while I'll get a very bad single data 
>> point
>> spike up to 7 or 8 Mbps and this spike will just crush down the rest of
>> the data being graphed.
>>
>> A. What's a good way to contain this?  ABSMAX?  Manual scaling?
>
> That depends on what is causing the "bad single data points".  If it is
> genuine traffic of short duration, then you need to ask whether you are
> more interested in accurate data or pretty graphs.


My machine running mrtg was acting up and I'd gotten no readings since 
sometime last night, so I rebooted it.  All of my bandwidth monitoring (of 
switch ports) shows bad spikes when the mrtg machine came back up.  I know 
the other servers in the farm didn't spike their output due to this 
machine being rebooted.  Monitoring of other services, such as modem usage 
on some dialup access servers, didn't exhibit the same behavior.

I wondering could the spikes be the _entire_ bandwidth that passed through 
those ports during the 10 hours that mrtg wasn't able to SNMP plotted into 
a single five minute perid?  For each of the ports the spike size is 
relative to the expected traffic through each connected servers.


>> B. If I set ABSMAX and then delete all the graphs for a data set, would
>> the newly generated graphs suppress the spikes or is it once the data
>> point is in the database I'm SOL until I can either edit it out or it
>> scrolls out of the data set.
>
> I believe that it will suppress the spikes when MRTG recalculates the
> graphs, 5 minutes , 30 minutes, 2 hours and daily.
>
> Beware that doing this will give you nicer-looking graphs that don't
> necessarily represent the reality of the parameters you're measuring,
> which can be a bad thing.
>
> There may also be a de-spike utility in the contrib directory, I seem to
> recall such.


I'll look into it.  Thanks.

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