[PATCH] reduce notification load; fix $NOTIFICATIONRECIPIENTS$ macro
Posted: Tue Nov 01, 2011 12:05 pm
This is a multi-part message in MIME format.
--------------000401070005030605080606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
hi,
recently we've been debugging on team icinga in the middle of
notifications and macros, and while investigating on a users problem,
we've digged a bit deeper into the notification viability checks,
resulting in deeper analysis of an Opsview patch to reduce the
notification load significantly by moving the viability checks from the
actual notification into the creation of the contacts notified, passing
only a list of 'qualified' contacts to the actual notification logic.
the only thing to remark over here is that the checks against the valid
notification_period now happen sooner, and not actually when the
notification is sent to each contact.
while implementing that patch into current code (needs some macro
passing with current code), we did remember nagios bug #98 where the
$NOTIFICATIONRECEIPIENTS$ macro is demanded to be only populated with
the actual contacts to be notified, but not all of those assigned to the
host/service. while this is considered to be a real bug, further
investigation showed that thanks to the viability checks before calling
add_notification(), contacts won't be added to that macro as the macro
logic happens within that function too.
so by applying the attached git patch, you will a. reduce notification
load and b. fix the $NOTIFICATIONRECEIPIENTS$ macro holding all
contacts, but not the viable contacts.
since the code remains actually the same on icinga and nagios in this
stage, the tests can be found at the icinga dev tracker as usual.
https://dev.icinga.org/issues/1744
https://dev.icinga.org/issues/2023
kudos to Opsview Team for their initial patch as well as Icinga
Development Team for the further analysis on the macro bug.
feel free to apply, matches against latest HEAD.
kind regards,
Michael
--
DI (FH) Michael Friedrich
Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria
email: [email protected]
phone: +43 1 4277 14359
mobile: +43 664 60277 14359
fax: +43 1 4277 14338
web: http://www.univie.ac.at/zid
http://www.aco.net
Lead Icinga Core& IDOUtils Developer
http://www.icinga.org
--------------000401070005030605080606
Content-Type: text/x-diff;
name="0001-reduce-notification-load-fix-NOTIFICATIONRECIPIENTS-.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0001-reduce-notification-load-fix-NOTIFICATIONRECIPIENTS-.pa";
filename*1="tch"
From 34d71eb4a947051cc0a1251745b8829245cd2e7d Mon Sep 17 00:00:00 2001
From: Michael Friedrich
Date: Tue, 1 Nov 2011 13:35:20 +0100
Subject: [PATCH] reduce notification load; fix $NOTIFICATIONRECIPIENTS$ macro
#98
1) currently, the list of contacts to be notified is created
and finally on the notification actually happening, the
viability checks happen. this will cause heavy load on systems
with many contacts configured, looping even for the contacts
who won't pass the notification viability tests.
in order to solve that, a patch by Opsview Team was taken into
account, moving the viability checks directly into the notification
list creation before adding a contact to the list.
note: the check against the timeperiod will happen on list creation,
not an actual notification being sent. but that's a minor flaw.
2) while moving the viability checks on list creation, this will
cause that not *all* contacts of the host/service will be added to
the list, but just those actually receiving the notification. the
macro $NOTIFICATIONSRECEIPIENTS$ gets populated in add_notification()
and will therefore hold only those contacts being viable for a
notification.
note: this fixes #98 on the bug tracker.
for further analysis and tests, please refer over here
https://dev.icinga.org/issues/1744
https://dev.icinga.org/issues/2023
kudos to Opsview Team for their initial patch, this has been
reworked into current macro threadsafety logic with some proper
inline co
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
--------------000401070005030605080606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
hi,
recently we've been debugging on team icinga in the middle of
notifications and macros, and while investigating on a users problem,
we've digged a bit deeper into the notification viability checks,
resulting in deeper analysis of an Opsview patch to reduce the
notification load significantly by moving the viability checks from the
actual notification into the creation of the contacts notified, passing
only a list of 'qualified' contacts to the actual notification logic.
the only thing to remark over here is that the checks against the valid
notification_period now happen sooner, and not actually when the
notification is sent to each contact.
while implementing that patch into current code (needs some macro
passing with current code), we did remember nagios bug #98 where the
$NOTIFICATIONRECEIPIENTS$ macro is demanded to be only populated with
the actual contacts to be notified, but not all of those assigned to the
host/service. while this is considered to be a real bug, further
investigation showed that thanks to the viability checks before calling
add_notification(), contacts won't be added to that macro as the macro
logic happens within that function too.
so by applying the attached git patch, you will a. reduce notification
load and b. fix the $NOTIFICATIONRECEIPIENTS$ macro holding all
contacts, but not the viable contacts.
since the code remains actually the same on icinga and nagios in this
stage, the tests can be found at the icinga dev tracker as usual.
https://dev.icinga.org/issues/1744
https://dev.icinga.org/issues/2023
kudos to Opsview Team for their initial patch as well as Icinga
Development Team for the further analysis on the macro bug.
feel free to apply, matches against latest HEAD.
kind regards,
Michael
--
DI (FH) Michael Friedrich
Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria
email: [email protected]
phone: +43 1 4277 14359
mobile: +43 664 60277 14359
fax: +43 1 4277 14338
web: http://www.univie.ac.at/zid
http://www.aco.net
Lead Icinga Core& IDOUtils Developer
http://www.icinga.org
--------------000401070005030605080606
Content-Type: text/x-diff;
name="0001-reduce-notification-load-fix-NOTIFICATIONRECIPIENTS-.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0001-reduce-notification-load-fix-NOTIFICATIONRECIPIENTS-.pa";
filename*1="tch"
From 34d71eb4a947051cc0a1251745b8829245cd2e7d Mon Sep 17 00:00:00 2001
From: Michael Friedrich
Date: Tue, 1 Nov 2011 13:35:20 +0100
Subject: [PATCH] reduce notification load; fix $NOTIFICATIONRECIPIENTS$ macro
#98
1) currently, the list of contacts to be notified is created
and finally on the notification actually happening, the
viability checks happen. this will cause heavy load on systems
with many contacts configured, looping even for the contacts
who won't pass the notification viability tests.
in order to solve that, a patch by Opsview Team was taken into
account, moving the viability checks directly into the notification
list creation before adding a contact to the list.
note: the check against the timeperiod will happen on list creation,
not an actual notification being sent. but that's a minor flaw.
2) while moving the viability checks on list creation, this will
cause that not *all* contacts of the host/service will be added to
the list, but just those actually receiving the notification. the
macro $NOTIFICATIONSRECEIPIENTS$ gets populated in add_notification()
and will therefore hold only those contacts being viable for a
notification.
note: this fixes #98 on the bug tracker.
for further analysis and tests, please refer over here
https://dev.icinga.org/issues/1744
https://dev.icinga.org/issues/2023
kudos to Opsview Team for their initial patch, this has been
reworked into current macro threadsafety logic with some proper
inline co
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]