Antwort: Re: Antwort: Re: Recovery not gettingsent duringdowntime?

[Morris, Patrick]

Responses inline. 

> > The problem is that it sounds like you're using scheduled downtimes 
> > incorrectly. It's not meant to be used for *un*scheduled downtimes; 
> > thus the name.  It's meant to supress alerts from a machine 
> during the 
> > specified window, and that's exactly what it's doing in your case.
> 
> It is a scheduled downtime. I put the host into downtime, 
> because I was planning to reboot it. I do not want 
> notifications to be sent out for the reboot of course, so I 
> am forced to set a downtime.

Or you could temporarily disable notifications for the host during the
reboot.  The Nagios docs are pretty clear that "[w]hen a host a service
is in a period of scheduled downtime, notifications for that host or
service will be suppressed."  It's working as designed.

I think we also have different definitions of "scheduled."  That's not a
word I would use to describe rebooting a box to bring a failed service
back up.

> > I can tell you that I'd really annoyed if it didn't work as 
> > advertised, and *did* send alerts in the middle of the night when I 
> > was working on a box and someone else was carrying the 
> pager (well, I 
> > might not be the guy to get annoyed, but I'd hear about it 
> in the morning).
> 
> I'm not talking about sending alerts. I'm talking about 
> sending recoveries for alerts that happened _before_ the 
> downtime, not for suppressed alerts _during_ the downtime. 
> For those a recovery should never be send of course - as no 
> alert has been sent.

But you are talking about sending alerts.  Recovery alerts are still
alerts, and alerts are suppressed during scheduled downtimes.

> > It sounds like you should probably be acknowledging 
> critical services, 
> > rather than marking them as being in scheduled downtime 
> when they're 
> > not.  That way the alerts stop until the service comes back up, and 
> > you'll be notified when it changes state.
> 
> If I acknowledge the problem, everyone get's a notification too.
> Where's the benefit?

If you don't want everyone to know you're acknowledging the problem (why
you wouldn't, I'm not sure), you can uncheck the "Send Notification" box
and everything stays nice and quiet.

> And acknowledging the problem doesn't make any difference.


> 
> Service goes critical
> SMS gets dispatched
> Problem gets acknowledged
> SMS gets dispatched
> Host gets scheduled for downtime
> Reboot
> Host/Service OK
> 
> Still no notification for the rest of the admins that the 
> service is fixed. For them it looks like it's acknowledged 
> and I'm working on it - but no sign ever that I fixed it.

That's not how it works.  If a service alerts that it's gone down, it
will also alert when it comes back up -- unless you mark it for
scheduled downtime, or otherwise disable notifications, in which case
alerts will be supressed.

> I still say: for every WARNING/CRITICAL/UNKNOWN that has be 
> sent there must follow a RECOVERY in case the Service/Host 
> recovers. That's expected behaviour and everything else is 
> rather diffuse behaviour in my opinion.

That's how it works when you don't turn notifications off, which is what
you're doing.

> (unless I explicitly suppress all notifications for the 
> service/host in question - but downtime shouldn't work this way)

But it does.  You're expecting it to do something other than what it's
designed for, and to behave in a way other than how it's documented.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
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