[rrd-users] Re: Front-end suggestions ?

Mark Rowlands mark.rowlands at minmail.net
Fri May 31 22:04:37 MEST 2002

On Friday 31 May 2002 5:58 pm, James Schnack wrote:
> Hi,
> I've been using MRTG for a while for some simple monitoring graphs. I've
> been playing a bit with rrdtool (great tool!) and reading a lot of the
> documentation, and I'm looking into it to create a set of scripts and/or
> config files to monitor a few Unix server with specific applications.
> I've already decided to use rrdtool, due to its flexibility (CDEFs,
> different graphs, etc.), for this little project of mine.
> I'm not so sure I will have the time to write code for the front-end (HTML
> page generation, etc.). So I looked into the front-ends listed under "RRD
> World" in rrdtool's web site. And I'm not sure which of those, if any, is
> the right one for me, so I'd appreciate if anybody with more experience in
> this area can share some of his/her opinions.
> My requirements would be:
> a) be able to use the *full* graphing flexibility of rrdtool (CDEFs, lines,
> areas, stacks, INF, etc.);
> b) have alarming capabilities: trigger the sending of emails (or execution
> of external scripts) when acquired data goes over/under preset thresholds.
> I wouldn't mind just having simple HTML pages and generate them with
> rrdcgi, but I'm not sure I could tackle the job of generating my own
> alarming code (I'm just a basic-level Perl programmer). Surely I would not
> make it efficient, if I could manage to do it at all...  ;-)
> So, I'll round it up:
> 1) With those two requirements in mind, do you recommend any of the
> available front-ends ? Which would be the best ? Pros / cons ? Real-world
> experiences ?
> 2) Should I just go for a "pure" rrdtool implementation and use rrdcgi ?
> Any easy way that you can think of to add alarming capabilities to that
> setup ?
> And last of all:
> 3) How many data sources should I stash into each RRD ? What's "common use"
> ? I will be monitoring OS parameters (load, memory, disk usage, interface
> utilization, etc.) for 3 Unix servers, plus a bunch of application specific
> parameters. Should I create one RRD per server, one RRD per parameter and
> server, or what ? Pros / cons ? Any performance considerations to keep in
> mind ?
> I'm sorry about the avalanche of questions, but I'm taking my first steps
> with this tool and any help will be welcome!
> TIA!
> James

The PHB's appetite for pretty pictures is limitless and you will soon be 
getting requests to extend your deployment until you are producing graphs of 
the average use of toilet paper vs curry consumption in the staff restaurant

For that reason, even if your initial deployment is only 3 machines, I would  
try and avoid anything too "specialised" .

Try and use the tools that are around and extend them where you need.  I've 
tried most of the stuff around but in the end usually come back to orca, for 
mass generation of long term stats, Big Brother for realtime monitoring, and 
some handrolled bits and bobs,  perl / mysql / snmp are my usually tools of 

I am quite keen on one rrd per "thing", this is probably less efficient (i 
collect between  30-50  stats per machine then update 50+ rrds per 
machine...uuugh),  but it makes things easier when disks get repartioned / 
added, network interfaces changed.....etc. I however store them by machine / 

ps, you do have a sensible machine naming convention and a procedure that 
ensures you know what machines / services / apps are going live / being 

Performance, get a dedicated box, no, get two!.... I like to have one as a 
data repository / processor box and one as a webserver. funding can often be 
obtained by pointing out the benefits of creating a central logging 
facility....some one might actually check the logs for a start. 

Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

More information about the rrd-users mailing list