Re: [Nagios-users] Antwort: Recovery not getting sent duringdowntime?
On Thu, 3 Aug 2006 [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] schrieb am 02.08.2006 18:36:18: > > > I think you might want to rethink your process so that it matches the > > paradigm of the tool you are using. It already can do what you want if > > you just work with the way it was designed, rather than forcing a > > process that breaks the paradigm. > > I think you might want to re-read my mail, it seems you did > not fully understand what I meant ;) The same issue might be the case the other way around. > > >Reboot > > >Host/Service OK > > Recovery Note goes out to everyone, including CTO. Problem Solved. > > Everyone knows what is happening. Your performance evaluation gets a > > boost for being the one to solve the problem. > > Uhm and what about the 2 SMS going out to everyone stating the > host going down and up again? That is neither expected (by the rest > of the admins for example), nor wanted behaviour. That are two completely different things. You propably did not expect the service to go down either. But it did. So how is that different in someone taking a full server down to 'fix' a service? The 'damage' of that action is propably larger then the single service. So shouldn't the rest know you took such draconic actions to fix a service? Even if happened to be the only option. > I DO know what the documentation says regarding scheduled downtimes. > I DO know it says it suppresses all alerts. > Yet I still say it should not suppress recoveries for critical/warning/ > unknown which happened before a schedule downtime. Somewhere else in the > documentation (or was it by Ethan somewhere else?) it states that for > every alert sent, there will be a recovery if it goes OK again. Pardon me for noting this sounds a lot like guessing. But feel free to show a reference. And if you find conflicting statements then you know both of them can not be true at the same time. I think you found out which one of the two is true and which one is not. In the end. You got the sources. If this bothers you so much you are free to use them and rewrite certain aspects the way you think it needs to be. If this is such a business critical tool then I am sure someone is willing to pay for someone to rewrite this to suit your needs. Hugo. -- I hate duplicates. Just reply to the relevant mailinglist. [EMAIL PROTECTED] http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of magicians, for they are subtle and quick to anger. - 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@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
[Nagios-users] Antwort: Recovery not getting sent duringdowntime?
[EMAIL PROTECTED] schrieb am 02.08.2006 18:36:18: > I think you might want to rethink your process so that it matches the > paradigm of the tool you are using. It already can do what you want if > you just work with the way it was designed, rather than forcing a > process that breaks the paradigm. I think you might want to re-read my mail, it seems you did not fully understand what I meant ;) > >Service goes critical > This is not a scheduled event. It is unscheduled. I never said anything else. I never said I scheduled a downtime for the SERVICE. I said I scheduled a downtime for the HOST, because I was forced to reboot the HOST to fix the SERVICE problem. I didn't have the possibility of acknowledging the service, fix it and be happy. Sometimes certain services of some retarded OS tend to kastrate themselves and only a reboot can fix it. If I do not schedule a HOST downtime, then SMSs get dispatched for the HOST being down and going up and then for the service recovering. Not exactly the behaviour I'd like to see. > Since the unscheduled event has already been acknowledged and everyone > who might want to jump in to help already knows it is being handled, > there is no need to schedule a downtime for an unscheduled event. Just > acknowledge it. > > >Reboot > >Host/Service OK > Recovery Note goes out to everyone, including CTO. Problem Solved. > Everyone knows what is happening. Your performance evaluation gets a > boost for being the one to solve the problem. Uhm and what about the 2 SMS going out to everyone stating the host going down and up again? That is neither expected (by the rest of the admins for example), nor wanted behaviour. I DO know what the documentation says regarding scheduled downtimes. I DO know it says it suppresses all alerts. Yet I still say it should not suppress recoveries for critical/warning/ unknown which happened before a schedule downtime. Somewhere else in the documentation (or was it by Ethan somewhere else?) it states that for every alert sent, there will be a recovery if it goes OK again. And alas, Ethan seems to agree with me, so I can't be that wrong, eh? regards Sascha -- Sascha Runschke Netzwerk Administration IT-Services ABIT AG Robert-Bosch-Str. 1 40668 Meerbusch Tel.:+49 (0) 2150.9153.226 Mobil:+49 (0) 173.5419665 mailto:[EMAIL PROTECTED] http://www.abit.net http://www.abit-epos.net - Sicherheitshinweis zur E-Mail Kommunikation / Security note regarding email communication: http://www.abit.net/sicherheitshinweis.html - 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@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
