[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nagios Integration

From: Martin Pala
Subject: Re: Nagios Integration
Date: Thu, 20 Feb 2003 00:38:47 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9

We spoke about using SOAP for data transmission. I think with some engine like XSLT it will be easy to translate XML data which will monit provide into for example plaintext, HTML, whatever.

With present possibilities of Monit, i think the best method to collect alerts could be:

1.) sent monit logs to syslog and redirect it from local machine where Monit runs to central machine (remote syslog). Monit has now built-in syslog facility+priority - maybe we can though about new statement which will allow to customize syslog facility (for example local1) and made syslog redirection easier. Example configuration:

/etc/monitrc (server1):
set log syslog
set facility local1

/etc/syslog.conf (server1):
local1.debug    @logger

/etc/syslog.conf (logger):
local1.debug    /var/log/monit.log

On the 'logger' server you need to allow remote syslog (514/udp) and collect the data to appropriate file (or database). You can use default syslog, or extended one, such as syslog-ng, etc. You can use logwatch or something similar to generate another alarms from central logs.

2.) read the data directly from monit's webserver by for example: http://server1:2812/apache. You can use for example lynx and some text processor like awk, etc. The data could be read in regular interval and represented by script, which could do anything you want (for example Netsaint/Nagios module).


Russell Adams wrote:

Russell Adams <address@hidden> writes:

I'm not sure I'd even use a central monitoring app for monit. ;]
If you're using monit on one or maybe two machines I agree. But if you
use monit in a server-farm context with many identical machines, a
central application can help in many ways.
Consider, via a central application you can push out a new monitrc
file to ever machine when you install a new program. Or if you have a
web-rack with HTTP servers you can push one button to stop, start or
restart all HTTP servers at once and so on. And of course it will also
monitor every machine, with uptime, statistics and suchs. But the main
benefit, because monit does not only report events but *act* on events
is that from one central application you will be able to control and
manage many servers from one screen.

Depends on how complex you want monit to get. With a central server
administrating remote systems over the network, you get network
security issues.

My first impulse is to use rsync or CVS in the "gold server" mentality
to push out configs. As far as start/stop/restart multiple machines, with
proper ACL's on the local monit webserver, you could use wget from a
single central machine to script remote actions.

An aggregate status for all monits would be a useful feature, but I
would consider it redundant to the other applications I use to monitor
uptimes and statistics on all of my machines (Nagios, cricket).

Perhaps a central monitoring/management app would simply build on your
integrated webserver commands. That'd be neat. ;]

Oddly enough, I'll be using monit to ensure Nagios is always
running. I crashed Netsaint once with a bogus plugin... ;] Hence my

Along the thought of a central machine, I think toward a plugin for
Nagios to query the status of monit on a machine. But then I'm just a
Nagios buff.

To elaborate, I use Nagios and SNMP/NSClient/NRPE to check on critical
processes on remote machines, but only to alert others to the
problems. Not all the machines could run monit (windoze :P), but those
that could would save me time and bandwidth by having a single plugin
call monit and verify everything is running ok, or monit reporting in
via submitting a passive critical service check when there is a
problem that it can't resolve.

That being said, all I'd like to do is allow more flexible alerts,
based on running an artibrary command instead of using just
email. That one feature alone would be simply awesome.

This way I could use paging directly like so:

alert `/usr/bin/snpp -m "Monit: $EVENT for $PROGRAM on $HOST" rladams`

or I would have the option of using any other program to pass on the
data as needed. Spawn, exec, launch or whatever the program specified,
and terminal the child process if it fails to exit in less than 90 seconds.
Actually we have discussed this idea before also, it's not a bad idea
and I'm not sure why we didn't implement it. Anyone remember?

Apparently not I. ;] Still, its a worthy feature.


To unsubscribe:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]