> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:nagios-users- > [EMAIL PROTECTED] On Behalf Of John P. Rouillard > Sent: Wednesday, March 29, 2006 4:45 PM > To: nagios-users@lists.sourceforge.net > Subject: Re: [Nagios-users] multiple nagios monitoring that have to agree? > > > In message <[EMAIL PROTECTED]>, > "Marc Powell" writes: > >> -----Original Message----- > >> From: On Behalf Of Philip Hallstrom > >> Sent: Wednesday, March 29, 2006 3:54 PM > >> I'm wondering if two nagios instances can be set up to monitor the > >> same hosts/services and have to agree with each other before sending a > >> notification? > >
[chop] > > >For an off-the-cuff suggestion, if you used multiple retries and didn't > >specifically require that both servers see the state as HARD you could > >embed that logic in your notification script. > > > >- NagiosA always sends notifications. > > If you have a redunant setup, only one server A or B would have to > send notifications for the service B. > I presume that you're referring to this from your previous e-mail -- "On both nagios 1 and 2 create service B that does notify (and poll) that uses check_cluster to require that both be in error condition to generate an error notification." How would you prevent duplicate notifications? Nagios 1 wouldn't know that Nagios 2 had already sent a notification and vice-versa unless you kept track of that externally. > >- ServiceX on HostY reaches hard state. > >- NagiosA initiates notification for ServiceX on HostY > >- Notification script searches status.log on NagiosB or performs HTTP > >screen scrape on NagiosB to determine state of ServiceX on HostY as seen > >from there. > >- If NagiosB shows CRITICAL, send notification > >- If only one shows critical do nothing(?) > >- repeat at regular intervals in case NagiosB was slow to pick up the > >state (or use the vice-versa logic to also send notifications from > >NagiosB) > > Neat idea, however you would need to handle the case where nagios B > isn't properly updating the service (and therfore isn't providing > valid data). Looking at Last Update should cover that scenario. > >There are probably pitfalls but I think that's how I would approach it > >at first. > > Yeah. It's a bit dicey regardless of how you slice it. Agreed. Interesting problem though. -- Marc ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Nagios-users mailing list Nagios-users@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
