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, when
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
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 colors
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 100,000
writes per block, or something insane like that. Here is where it gets bad.
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 kill
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 store
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 get
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 firewall,
you're really not going to care much past 1 day's worth of information. You
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 going
to care about immediate information, like what's been going on over the past
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.
> 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