> To be honest, I'm surprised that m0n0wall isn't using rrdtool to generate
> it's graphs. SVG is cool and all, but why go through all that trouble,
> you could just dump data to rrdtool every few seconds. And since it's a
> round robin database, the filesize is constant, so it won't eat up your
> compact flash card's memory. If you want the graph to update automagically
Just a precision : With the SVG traffic grapher, there is absolutely NO
stockage on m0n0wall disk or CF or memory, so this way doesn't eat up your
compact flash card's memory. All data are saved by your browser for just
20s. And you can see that your memory browser is not eated up too.
Traffic grapher is just an instant shoot of what happens on your Interfaces.
Consider it for that, and not as an rrdtools-like for a long way analisys.
Sure, you right, I think both are useful. But I think too that m0n0wall is
not a traffic analyser box. As an Extension why not (-;
----- Original Message -----
From: "Eric Shorkey" <eshorkey at commonpointservices dot com>
To: <m0n0wall at lists dot m0n0 dot ch>
Sent: Saturday, April 03, 2004 2:26 AM
Subject: Re: [m0n0wall] some notes on how we added traffic graphs to
> Of course, there is a downside. RRDTOOL requires the use of an rrdtool
> database, which is just a file that you have rrdtool create for you so you
> have somewhere to store these datapoints. As you collect datapoints, you
> give them to rrdtool to store within that database, and later you use the
> graph generator within rrdtool to create pretty images with lines and
> and all that to give you a visual description of whatever data you've been
> having it store all this time. Most compact flash cards are good for
> writes per block, or something insane like that. Here is where it gets
> That means that as your firewall runs, rrdtool would be constantly writing
> to the same few blocks on your CF card. Which, after a few years, would
> it. A better idea would be to have m0n0wall create a ram disk on boot, and
> create the rrdtool database within that. Since you aren't going to be
> storing a lot of datapoints (only 1 day's worth at the most), the ramdisk
> would only need to be a few MB.
> I bet you're wondering why you only store 1 day of graph data at the most.
> If you wanted longer graphs, you should use SNMP to grab the data, and
> it on another box. Preferably one with a much bigger hard drive. High
> resolution graphs of firewall throughput can quickly turn out to be bigger
> than you had anticipated. For instance: I store our firewall traffic stats
> for 1 year, and poll the device every 15 seconds for data. (This allows me
> to get 1 minute averages over 4 datapoints. If one of the datapoints is
> invalid, corrupt, gets "lost", or whatever, i still have 3 good ones to
> a proper average from.) These 1 minute averaged datapoints, for only 2
> interfaces, created a 32MB database. I have another firewall with 4
> interfaces in it, and that DB is 64MB.
> So anyways, if you're going to put a traffic graph right into the
> you're really not going to care much past 1 day's worth of information.
> really only log into a firewall for 2 reasons. Either you're making a
> change, or your trying to figure out what's broke. You're really only
> to care about immediate information, like what's been going on over the
> hour, and the past day. Anything more than that, and you'd be looking at
> your much bigger traffic logs.
> ----- Original Message -----
> From: "Adam Nellemann" <adam at nellemann dot nu>
> To: "Jay Wherley (SEI)" <jrw at squires dash eng dot com>
> Cc: <m0n0wall at lists dot m0n0 dot ch>
> Sent: Friday, April 02, 2004 6:32 PM
> Subject: Re: [m0n0wall] some notes on how we added traffic graphs to
> > Hi Jay,
> > Jay Wherley (SEI) wrote:
> > > i've put together some notes and a pair of screenshots describing a
> > > method we used to add network traffic (and net4801 enviromental
> > > data - Temperature, Vcc, Vpower) graphs to m0n0wall.
> > >
> > > full details here: http://www.squires-eng.com/graphinfo.html
> > >
> > > the data is collected (via cron job) using SNMP for the network
> > > interfaces, and some parsing of env4801 program output for the
> > > enviromental data. it is stored in a fixed size "round robin"
> > > database.
> > >
> > > lots of different custom graphs could be used to pull up the data -
> > > the ones i made show hourly, daily, weekly, monthly, and yearly
> > > data.
> > >
> > > the data is persisted across power cycles by periodically copying
> > > the database to /cf (and using that if it exists at startup).
> > VERY nice! Any chance you'd care to implement this using the new
> > plugin interface for m0n0wall, making it a bit easier for us *NIX
> > ignorants to get it up and running?
> > If not, anyone else on the list who'd be up to this task?
> > By the way, I'm using the PC version of m0n0wall, any chance this
> > would work anyway? I guess the environment part wouldn't, at least not
> > without some changes, but I'm primarily after the traffic graphs.
> > Perhaps, if being implemented as a plugin, it could be split into two
> > seperate ones, one for the traffic, and one for the environmental
> > stuff. This would also allow the latter to be modified for the various
> > platforms supported, in case someone want or need to do so.
> > Regards,
> > Adam.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch