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 #1744] reduce notification load by moving notification viability check into notification list creation #694
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
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.
2011-10-21 19:17:23 +00:00 by mfriedrich 365574b
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
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 $NOTIFICATIONRECIPIENTS$ macro is wrong too - in 5. it gets calculated, but in 9 decided that the contact does not get notified. -> bug!
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 18:05:43 +00:00
hosts and services are at random with https://wiki.icinga.org/display/testing/Test+Config
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
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.