[nycbug-talk] Monitoring programs
Fri Aug 19 20:46:16 EDT 2005
On 8/19/05, Bob Ippolito <bob at redivi.com> wrote:
> On Aug 19, 2005, at 10:51 AM, pete wright wrote:
> On 8/19/05, Francisco Reyes <lists at natserv.com> wrote:
> > Going through the ports see a whole batch of monitoring packages. Any
> > recommendations?
> > In particular looking to monitor disk, memory and a couple of
> > directories.
> > So far I see on ports
> > cfgstoragemk-1.0_1
> > MRTG configuration generator for storage monitoring via SNMP
> > cricket-1.0.5_1
> > A high performance, extremely flexible monitoring system
> works well for us here, we track a considerable amount of services with
> cricket (we tie it into our nagios setup).
> > Extremely powerful network monitoring system
> also quite good, although frankly the configuration system can turn into a
> mess for a large number of systems. I would suggest getting a perl/DB front
> end for it. we monitor a *huge* amount of machines with nagios and aside
> from having to edit some header files to accomidate our hosts it runs pretty
> In my experience nagios seems to be the most flexible and robust solution
> going, it can be a pain to configure but by the same token you can get it to
> do alot of different things (SNMP checks, scripts, etc..). For the type of
> checks you want to run, this may be your best bet as most of those checks
> already exist or are online as plugins.
> Nagios seems to work well, but it's the worst piece of garbage I've ever
> put into production. The configuration language is custom, verbose, ill
> documented, and brain damaged. The web interface is mad oldschool and ugly.
> I haven't looked at the code, but I suspect that I probably wouldn't have
> been able to deploy it in good conscience if I had (the Wordpress dilemma).
here here, although you can fix the web unglyness.
However, I haven't seen anything better, so I second that Nagios
> recommendation. Just set aside a day or two to edit configuration files.
> Unless you're using something to generate Nagios configuration files, expect
> to be writing at least 60 lines of configuration across three or four
> different files for each host.
heh, try configuring it for litterally thousands of unix
workstations/servers/compute nodes/switches etc... ;) I'm testing out config
front ends now, and if i remember i'll post back to this thread with my
recommendations next week or so.
NYC's *BSD User Group
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk