Distributed setups

Mark Wagner markwag at u.washington.edu
Fri Jul 13 21:00:23 CEST 2007


Steve Shipway <s.shipway <at> auckland.ac.nz> writes:

> 
> > We're currently looking at creating a distributed setup using
> > NSCA. One thing that I've found no mention of is how the host and
> > service commands are forwarded.
> 
> I think they are not.
> 
> > Even if the central machien does all the notifications (as we're
> > planning), completely dis/enabling service/host checks would have
> > to be distributed from the central machine to the checking
> > machines.
> 
> This is the biggest disadvantage of the distributed model, in my opinion
> - enable/disable checks commands are not propagated (and indeed cannot
> be without some serious reworking of the cmd.cgi interface) and so you
> cannot stop checking any more.
> 
> However this is not such a big issue, as mostly you are more interested
> in scheduling downtime and disabling/acknowledging alerts, all of which
> are done on the central server.  The satellite servers (collectors) do
> not do notifications, only pass the status on to the central server
> (aggregator) via the OCSP command.
> 
> If I was obsessive about it, I'd modify the cmd.cgi script so that it
> spots a distributed service (no active checks, only freshness checks to
> set to 'unknown') and forwards to call to the host managing it (which
> I'd have to store the definition of in a separate database table or
> something).  Too much trouble though, particularly since our users are
> forever clicking 'disable checks' when they actually mean 'disable
> alerts' or 'acknowledge'.

It is an issue in the following situation: you have a backup aggregator. All the
collectors send results to both the primary and backup. The backup aggregator
watches the primary aggregator. If the primary goes down it starts sending out
notifications. In this case all the acked problems on the primary aggregator
will be sent out when the backup takes over.

The idea I'm toying with is to have cgi.cfg point to a different
main_config_file. This main_config_file will be identical to the real
main_config_file but have a different command_file. There will be a process
listening on this command_file that will write the result to the real command_file
and also forwards it to a daemon listening on the backup aggregator. This daemon
will write to the command_file on the backup. Viola', all commands from the CGIs
automatically get sent to the backup aggregator.


-- 
Mark Wagner <markwag at u.washington.edu>
System Administrator, UW Medicine IT Services
206-616-6119

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list