multiple nagios monitoring that have to agree?

[John P. Rouillard]

In message <A7B0A9F02975A74A845FE85D0B95B8FA03468E0E at misex01.ena.com>,
"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?
>
>That's not a standard configuration and you'd probably run into timing
>issues.

Good point that I forgot to address in my original reply.

>If NagiosA has checked the service and finds it down, NagiosB
>may not have checked the service yet and may still consider it up. What
>do you do then (nothing?)? How can you tell the difference (Last Check
>time?)? Nagios isn't built for that kind of coordination.

If you have a correlation service B watching services A1 (polled from
nagios A) and A2 (polled from nagios B and sent passively to nagios A)
you want B to poll at least twice as fast as the poll interval for A1
and A2. E.G. If A1 and A2 poll at 4 minutes, poll B at 2 minutes
maximum to allow you to sample the state that can change twice every 4
minutes.

>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.

>- 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).

>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.

				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.


-------------------------------------------------------
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&kid=110944&bid=241720&dat=121642
_______________________________________________
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