On 17.09.2013 17:08, Denis Simonet wrote: >> an eventhandler behaves differently than the notification logic does. so >> *if* you're comparing things, you should look for eventhandlers. >> >> and yet, i doubt the behaviour change unless proven with a working >> example from both core versions. > Well, it is possible that this changed with newer Nagios versions. It > seems to be worth a try to verify - I will send another eMail as soon as > I did so.
i haven't tried them very hard because since 3.4.x every release got more bugs, and broke my testruns. i'm only analysing and collecting valuable patches for porting them to icinga 1.x - some from the 4.x branch too. but i cannot imagine that they changed such an elementary behaviour. though, in icinga it works like you've experienced and won't be changed. > >> so your eventhandler wraps the notification logic into its very own >> algorithm and does the voodoo inside. i'd rather look for errors in your >> script then, catching up with "host down, don't send service notification". > I didn't check this in our logic up to now because when we used nagios, > nagios was doing it. Or at least I thought that it would do so. The > question should have been: Why does the event handler trigger for > services when their host is down? And the answer is simple - because one would want to do something at that state. i.e. when the host is just one cluster node, but the service can be restarted anyways on a different node triggering the failover sequence. in short - with eventhandlers you'll have to deal with state types and changes for yourself. if you're taking the cores notification and implicit service->host dependency logic, you'll save yourself the hassle. > >> that's a very common case that eventhandlers get called even if the host >> is down... >> http://docs.icinga.org/latest/en/eventhandlers.html#execution >> >> and well - for the interested readers - why can't icinga handle the >> notification logic itsself, and why are you using a proprietary event >> handler wrapper for that? > We wrote a frontend application for Icinga (formerly Nagios) where we > can administer hosts and export configuration files for Icinga. In the > same applications teams can be configured on a daily basis. The alerting > itself is done in a round robin way and the alerts are all logged in our > application. Therefore it was the easiest solution to write an own > daemon application which does the alerting. Ok, then your application got a bug it did not trigger before - it does not check the service's host state before sending an alarm. If it's perl that's 1 or 2 loc. > >> next time, please tell about that in the first place. makes error lookup >> pretty hard if one thinks of notifications, but the user (you) is just >> using eventhandlers. totally different part of the story. > I accidentially messed up notification with event handler - I don't > think this is a crime :P Sure, I am just reminding not to make the mistake twice. I'm interested in challenges in support - not querying users for information in every request :p > > Denis > -- DI (FH) Michael Friedrich mail: michael.friedr...@gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmi...@jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ icinga-users mailing list icinga-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/icinga-users
