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 <[EMAIL PROTECTED]> 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 [email protected] 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
