[dev.icinga.com #1367] add notifications to stalking hosts/services, not only logging/event handlers #601
Comments
|
Updated by mfriedrich on 2011-04-29 12:57:36 +00:00
needs more investigation. |
|
Updated by mfriedrich on 2011-07-12 18:48:18 +00:00
|
|
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 stalking_notifications_for_hosts 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 15:21:38 +00:00 requires a new notification type to be sent then, define in icinga.h will be passed when calling host|service_notification() function |
|
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. icinga.cfg 1367.cfg
output 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 syslog icinga.debug 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. |
|
Updated by ares on 2011-12-19 12:10:03 +00:00 Just fyi we tested this and it works perfecly for our needs. Thank you very much. |
|
Updated by mfriedrich on 2011-12-19 20:38:24 +00:00 thanks for the feedback - very nice indeed that others can benefit too :-) |
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
Assignee: mfriedrich
Status: Resolved (closed on 2011-11-06 10:16:09 +00:00)
Target Version: 1.6
Last Update: 2011-12-19 20:38:24 +00:00 (in Redmine)
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!
Changesets
2011-11-01 10:42:13 +00:00 by mfriedrich 1762802
Relations:
The text was updated successfully, but these errors were encountered: