Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #1367] add notifications to stalking hosts/services, not only logging/event handlers #601
This issue has been migrated from Redmine: https://dev.icinga.com/issues/1367
Created by mfriedrich on 2011-03-30 21:48:55 +00:00
currently stalked hosts/services match
if this is true, it is then decided,
if this matches, this event is being logged.
if stalking event handlers are enabled, you can use an event handler assigned to the host/service.
but what if you wan't to get notified about that? current example - snmp uptime. will always stay in a state, but the output will change. such things are interesting, even if they won't generate a normal alarm.
so by adding an
it should do the normal notification thingy and checkings. although it needs to be evaluated which things need to be set on the temp_service attributes to match a notification.
and it should be make a cfg option.
note aside stalking is enabled for HARD state, but what if it's always OK, and remains in SOFT state? it would be worthwile to test if soft states are also possible for stalking!
2011-11-01 10:42:13 +00:00 by mfriedrich 1762802
Updated by mfriedrich on 2011-10-25 09:11:25 +00:00
within the viability checks for the host/service notification, this must be passed and if so you could even control that by contact using a new notification_option - if this is set, the contact gets added to the notification list in memory and after that the notification is actually invoked.
if we make it a global option, we have to make sure that it passes everything else.
Updated by ares on 2011-10-31 07:31:15 +00:00
Any news? I'd vote +1 for this. We need this for raid array monitoring (when a service is acked because of 1 disk failure and another disk gets broken we must recieve a notification - based just on output change, not state change)
Updated by mfriedrich on 2011-10-31 08:33:58 +00:00
i'm still undecided if making it a config option like
or similar in icinga.cfg (like stalking event handlers), so that each would trigger, or do it the notification_options way and add a new option to allow such a filter just for chosen hosts or services.
stalking event handlers got one major advantage - you can already define an event handler. for a notification, the exact state must have been matched.
on the stalking side of life you have something like
and if stalking for that state enabled, the notification pattern like a normal notification for that host/service must match too.
so e.g. enabling stalking on critical service, the associated contacts receiving a notification then must be able to pass viability checks like normal. this is where a special contacts just for stalking might be needed. so adding that will require some doc updates then too.
and, that's bugs me the most - how to identify a stalking notification? populate the subject differently based on the host being stalked?
Updated by mfriedrich on 2011-10-31 18:14:16 +00:00
we're keeping the rest of the notifications safe,
using our own type, and NOTIFICATION_OPTION_NONE
Updated by mfriedrich on 2011-11-01 10:00:39 +00:00
furthermore, we can't actually pass the notification viability checks. stalking notification without any proper handling would result into the following
so in order to make this happen, we change the code in base/notifications.c a bit and handle NOTIFICATION_STALKING the same as NOTIFICATION_CUSTOM - it won't hit the place for checking if a NOTIFICATION_NORMAL either way.
Updated by mfriedrich on 2011-11-01 10:28:01 +00:00
how to test
install the testconfig from the wiki.
from the debuglog, it looks different than previous debug logs because we already changed the notification viability in the git tree with #1744
actually, the notification script would need a seperated handler on the notification type, so that STALKING could be wrapped somehow. problem would remain that the core can't keep current and previous checkoutput putting that into a macro being available on notifications.
disabled icinga.cfg feature
don't stalk on OK
so the first service will notify (and also log the ALERT because stalking enabled), but the second just stays calm
this can be tested with all states, the code is merely the same for triggering as the event handlers, it just needs it globally enabled in icinga.cfg because it's an opt-in feature next to the normal stalking logging.
Updated by mfriedrich on 2011-11-01 10:43:53 +00:00
possible todos - how to filter assigned contacts for that host/service for stalking notifications.
Updated by mfriedrich on 2011-11-06 10:16:09 +00:00
discussed that with my colleague, and the initial implementation will make that notification dependant on enabling stalking, and stalking notifications overall. the main problem with notification_options will be the filter for "ok", and various other logic might need to be different. so we'll leave that as it is for now. for further discussions, please open a new issue with new ideas/questions.