Nagios Tracker - 0000098: $NOTIFICATIONRECIPIENTS$ contains addresses which are disabled by host/service_notification_options

Notes
(0000360) PMDubuc (reporter) 2011-10-13 16:19	This problem is still in Nagios 3.2.3. The documentation says the notification macro: $NOTIFICATIONRECIPIENTS$ is A comma-separated list of the short names of all contacts that are being notified about the host or service. Instead this macro contains all contacts for the host or service regardless of whether the particular notification is actually being sent to them. I have one contact for all services that only gets CRITICAL (c) notifications according to its service_notification_options setting, but the $NOTIFICATIONRECIPIENTS$ macro includes this contact along with others that get WARNING notifications when the WARNING notification is sent. This would imply that the critical only contact also got the notification but this isn't true.

(0000362) dnsmichi (reporter) 2011-10-21 13:56	this is due to the fact that the notification viability checks are done when the notifications are actually being sent, not when the notification list is created with looping and calling add_contact (which populates the macro itsself too). so i consider this a bug, not a feature.

(0000368) dnsmichi (reporter) 2011-11-07 12:32	i've sent a patch addressing that fix plus reducing the notification load to the nagios-devel mailinglists. -------- Original Message -------- Subject: [PATCH] reduce notification load; fix $NOTIFICATIONRECIPIENTS$ macro 0000098 Date: Tue, 01 Nov 2011 14:05:33 +0100 From: Michael Friedrich <michael.friedrich...univie.ac.at> To: nagios-devel...lists.sourceforge.net CC: nagios-users...lists.sourceforge.net 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 0000098 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

Issue History
Date Modified	Username	Field	Change
2009-10-01 19:43	MattHarrington	New Issue
2009-10-01 19:43	MattHarrington	Nagios Version	=> 3.0.6
2010-08-28 10:17	egalstad	Severity	minor => feature
2011-10-13 16:18	PMDubuc	Issue Monitored: PMDubuc
2011-10-13 16:19	PMDubuc	Note Added: 0000360
2011-10-21 13:56	dnsmichi	Note Added: 0000362
2011-11-07 12:32	dnsmichi	Note Added: 0000368
2011-11-07 12:32	dnsmichi	File Added: 0001-reduce-notification-load-fix-NOTIFICATIONRECIPIENTS-.patch
2012-04-21 09:40	estanley	Status	new => resolved
2012-04-21 09:40	estanley	Resolution	open => fixed
2012-04-21 09:40	estanley	Assigned To	=> estanley

Relationships