time-series graphing options (was: RE: Distributed SNMP monitoring.)

Carroll, Jim P [Contractor] jcarro10 at sprintspectrum.com
Wed Dec 4 20:59:37 CET 2002


Jamie Baddeley wrote:
> I originally used NRG because it auto-conf'ed everything, so 
> was easy to
> use. The downside is it was not so flexible. So, we moved over to
> Cricket+Smokeping. Seems all good (so far).

I spent a few cycles on Cricket, and ended up running aground at some point.
I suppose I could take another crack at it.

> But anyway, on to my point:
> 
> It's wouldn't surprise me that loadsa people want to do the same
> Nagios+RRD&Front-End combo (but with no fries).
> - APAN seems pretty good but when one has a plethora of RRD 
> front-ends out
> there - why would you create another one -especially when 
> people have an
> investment in the rrd stored data of the existing system? (no offense
> fredrik).
> - IMHO Cacti seems to be overkill. But I could be wrong.

Could be.  I just like that it makes creating the RRDs/RRAs considerably
simpler.  I've read the RRDtool docs a number of times, and only succeeded
in bogging down my brain.

My intent is to tap into the serviceperf.log file using Perl, scrub it every
5 mins (keeping track of the current position using seek/tell), then have
the appropriate RRDs populated.

Hmm, now that I think of it, if I could figure out a generic template (even
broken down by procs, memory, disk, etc), I could have the script scrub
serviceperf.log ever 5 mins, check for the existence of RRDs (and create
them if absent, based on a partial string match), update the RRDs, write the
tell to a file, then exit.  (Of course, I'd check to see if the seek/tell
value is greater than the size of the file, and if so, start from position
0, ie, the logfile was rolled over.)

Who knows, maybe I'll go back and check out Orca again.

> So, can I see a show of hands as to what people's preferences 
> are for an RRD
> "partner tool" for Nagios? Maybe we could all work together on making
> integration between the two really slick...
> 
> Architecturally my preference is to let the RRD tools do the data
> acquisition, and let nagios pull from the (probable) local 
> RRD file....What
> are people's thoughts on that?

Interesting approach.  But one needs to ask the question of whether
MySQL/Postgres could be used, since splicing Nagios into one of those at
compile time is a clear option.  Having said that, how would one easily
generate RRDtool-like graphics, short of extracting from one database (eg,
MySQL) to populate another (eg, RRDtool)?  I'm all for keeping data
duplication to a minimum.  Taking this a step further, one could create a
visual representation of any arbitrary data in MySQL, and not need to depend
on the cast-in-stone-at-creation-time approach of RRDtool.

jc


-------------------------------------------------------
This SF.net email is sponsored by: Microsoft Visual Studio.NET 
comprehensive development tool, built to increase your 
productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en




More information about the Users mailing list