[dev.icinga.com #1744] reduce notification load by moving notification viability check into notification list creation #694
Comments
Updated by mfriedrich on 2011-08-23 08:51:45 +00:00
|
Updated by mfriedrich on 2011-10-17 13:07:56 +00:00
|
Updated by mfriedrich on 2011-10-21 16:15:40 +00:00 questions to step into, as the load reduce with creating the lists in the first place and not checking on each notification themselves...
|
Updated by mfriedrich on 2011-10-21 16:52:54 +00:00 if any, then those http://docs.icinga.org/latest/en/macrolist.html#macrolist-notificationrecipients a notification works like this: # a notification gets called from an event (hard state change or similar)
# within host_notification, the list of contacts gets created
# that creation steps through all contacts assigned to that host and adds the contact for that notification
# in add_notification, a new notification is created for that contact, and added to the global list in memory
# then the macro is being populated
# back in the host_notification from 2., after the list has been created for all contacts, the notification_list is checked and processed
# all other macros are calculated/processed and then the notify_contact_of_host function is called
# then checked if the viability is given for the contact
# checking a contact for viability looks like this
summary - a host will not be notified if
meaning to say - different notification_options will prevent a lot of notifications. |
Updated by mfriedrich on 2011-10-21 16:58:48 +00:00 now go figure - to decide if a contact gets notified, steps 1 - 9 must be done, even if not notified in the end then. so to speak the if you move 9. after 3. but before 4., those contacts won't be added to the notification list, the macro does not get populated and on the real notification happening a thinner list is being processed, removing longer lasting blockings from the core then. |
Updated by mfriedrich on 2011-10-21 17:40:43 +00:00
nagios bug #98 - http://tracker.nagios.org/view.php?id=98 . |
Updated by mfriedrich on 2011-10-21 18:05:43 +00:00 tests
hosts and services are at random with https://wiki.icinga.org/display/testing/Test+Config icinga.cfg
|
Updated by mfriedrich on 2011-10-21 18:27:16 +00:00 ah yes and testing the macro - let it print so wie see it in the debug output.
furthermore, start with a clean icinga core, retained data might suppress notifications. testing on debian sid with custom paths like packages have
|
Updated by mfriedrich on 2011-10-21 19:10:40 +00:00
test results without FIX
with FIX
|
Updated by mfriedrich on 2011-10-21 19:13:57 +00:00
so to summarize - the old behavior runs through every single contact getting adding to the notification lists, populating the macro and then refusing to actually send the notification for that host/service by the viability checks. the patches version does the checking once before adding to the notification list, saving us a lot of cpu cycles while fixing the macro bug as well. this needs further testing, please use the provided configs and/or test it with your own. will push to dev/core and test/core as well. |
Updated by mfriedrich on 2011-11-01 11:57:30 +00:00
|
This issue has been migrated from Redmine: https://dev.icinga.com/issues/1744
Created by mfriedrich on 2011-07-22 16:42:43 +00:00
Assignee: mfriedrich
Status: Resolved (closed on 2011-11-01 11:57:30 +00:00)
Target Version: 1.6
Last Update: 2011-12-03 11:30:13 +00:00 (in Redmine)
this makes sense as the list created once, but the viability checks always need to called a bit further. not even adding the contacts which should be notified in the first place makes sense.
Attachments
Changesets
2011-10-21 19:17:23 +00:00 by mfriedrich 365574b
Relations:
The text was updated successfully, but these errors were encountered: