[Ntop] rrd graphs misleading (stacked instead of overlayed)

[Mel Beckman]

MRTG uses an overlay with just two data items, using area fill for one and an always-visible line for the other, so that works. You can't get MRTG to plot more than two things, though, unless you go to something like Cacti, which incorporates MRTG mods to do stacked graphs (e.g., http://ostatic.com/files/images/Cacti%20Screenshot%2010.jpg). You can have one area graph and multiple lines, but that's not much better than simply plotting multiple line graphs; in fact, it artificially draws attention to a single data source.

>PS: The highest value would always be in the back with lower values overlayed in front - so it should never "hide" any data points.

But there's no guarantee that one data source is always higher than another.  In my network sometimes HTTP is high, but at night it's FTP. No matter which way you go, one of those is going to be hidden in an area-graph overlay (and the problem gets worse with more data sources)

It's not an American thing. It's an information thing ;) The recommendation to Tufte's books is a good one. These are gold mines of data presentation wisdom.

 -mel


On 3/3/09 11:41 AM, "Gary Gatten" <Ggatten at waddell.com> wrote:

All good points - I'm just used to the data being presented in an overlayed fashion.  Maybe it's us crazy Americans?  MRTG for example uses the overlayed style.  Obviously you're well versed in this so who am I to argue :)  I'm just used to a different style and now that I know what's up I can live with it or change it as you pointed out.

Thanks for the prompt replies!!!

Gary



________________________________

From: ntop-bounces at unipi.it [mailto:ntop-bounces at unipi.it] On Behalf Of Burton Strauss III
Sent: Tuesday, March 03, 2009 7:46 AM
To: ntop at unipi.it
Subject: Re: [Ntop] rrd graphs misleading (stacked instead of overlayed)

I don't think they are misleading at all. Mail traffic is the blue part - it's clearly small except during the peak around 3:15am. HTTP is the bulk and the rest barely registers.  These are they way the charts have ALWAYS been drawn and never caused an issue.

Doubt they will be changed - IMNSHO, the other view would be the misleading one (read Edward Tufte's book on presentation of information - see www.edwardtufte.com/ <http://www.edwardtufte.com/> unfortunately, my two copies are @ home, so I can't give you the page reference :()

This graph presents two pieces of information - the area under the line is the TOTAL information flow and the size of each color bar shows its value. Overlayed graphs show one the one item (and poorly at that - what happens if A & B swap their position as largest traffic contributor (say day time vs. night)?  The chart you want will hide half it's information!

But: If you want other views, just use the command line against the actual rrd graphs - or the arbitrary rrd graph command built into ntop.

-----Burton


From: ntop-bounces at unipi.it [mailto:ntop-bounces at unipi.it] On Behalf Of Gary Gatten
Sent: Monday, March 02, 2009 10:27 AM
To: ntop at unipi.it
Subject: Re: [Ntop] rrd graphs misleading (stacked instead of overlayed)

[cid:3318926854_93245118]


________________________________

From: ntop-bounces at unipi.it [mailto:ntop-bounces at unipi.it] On Behalf Of Gary Gatten
Sent: Monday, March 02, 2009 12:25 PM
To: ntop at unipi.it
Subject: [Ntop] rrd graphs misleading (stacked instead of overlayed)

Some / many graphs (rrd) are misleading as they are "stacked" instead of "overlayed"  For example:

Summary -> Traffic -> Historical Data.  The Fifth graph down is "Bytes/sec" per protocol.  The vast majority of my traffic is http at 2.4MB/s.  The graph and the text/numerical data concur.  However, Mail traffic is 272KB/s - but when looking at the graph you'd think it was almost 3MB/s.  This is because it's stacked on top of the http graph line.

This is similar behavior on most/all of the graphs I typically look at.

Has anyone else noticed this and is there a fix? Upgrading to the latest release (still on 3.2.1) is on my task list for the next 2 - 4 weeks, so if that will fix it that'd be great.

Thanks!

Gary

"This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system."
"This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system."
"This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited.  If you have received this email in error, please immediately notify the sender by return email and delete this email from your system."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listgateway.unipi.it/pipermail/ntop/attachments/20090303/2568b885/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.jpg
Type: image/jpeg
Size: 59724 bytes
Desc: image.jpg
Url : http://listgateway.unipi.it/pipermail/ntop/attachments/20090303/2568b885/attachment-0001.jpg