[mrtg] Trying to find a scaling method that produces readable graphs against spike loads

Steve Shipway s.shipway at auckland.ac.nz
Thu Oct 11 08:45:46 CEST 2007

Here are a couple of options.
If you are using RRD as your backend, try using routers2 as your frontend.  This has a 'rescale' button for just this sort of situation which autorescales the graph to show the detail.  Repeated clicks of 'rescale' will try different rescale algorithms.
Alternatively, you can set an UpperLimit for the graph to fix the Y-Axis to have a fixed maximum, no matter what the data is.  This will hide the spikes, and let you always see the detail, as long as you can work out a sensible value to fix the Y-Axis at.


From: mrtg-bounces at lists.oetiker.ch on behalf of Bill Moran
Sent: Thu 11-Oct-07 6:06 a.m.
To: mrtg at lists.oetiker.ch
Subject: [mrtg] Trying to find a scaling method that produces readable graphs against spike loads

I have some graphs that go unreadable because spike loads are throwing
off the scaling.

A daily cron job causes the graphs to spike to ~10 million for a brief
time every day, which causes the graphs to scale to that.  Unfortunately,
the data I'm _really_ interested in seeing is between 1000 and 100000,
which gets scaled to the bottom of the graph in such a way that it
can't really be read (it's just a flat line with a few little bumps.

I've switched to log scaling, but it's not enough in these cases.

I wouldn't mind losing the details off the top of the graph to get
the graphs to scale to where I can see the other data.  I already know
the cron jobs max out the resource, I really need to see what the
activity in between the cron jobs is doing.

Will MaxBytes accomplish this by completely ignoring the high values?
I tried it, but it simply draws a red line across the graph at the
Maxbytes value, Will this scale out correctly over time?

Any advice is appreciated.

Bill Moran
Collaborative Fusion Inc.

wmoran at collaborativefusion.com
Phone: 412-422-3463x4023

mrtg mailing list
mrtg at lists.oetiker.ch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/mrtg/attachments/20071011/b716c7f7/attachment.html 

More information about the mrtg mailing list