|Anonymous | Login | Signup for a new account||2013-05-21 02:53 EDT|
|Main | My View | View Issues | Change Log | Roadmap|
|Viewing Issue Simple Details|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000098||[Nagios Core] Notifications||feature||have not tried||2009-10-01 19:43||2012-04-21 09:40|
|Summary||0000098: $NOTIFICATIONRECIPIENTS$ contains addresses which are disabled by host/service_notification_options|
When a host or service has contacts with varying host_notification_options or service_notification_options values, all contacts are listed with $NOTIFICATIONRECIPIENTS$, even when notifications will not be sent to all contacts.
I include $NOTIFICATIONRECIPIENTS$ in my notification commands, however, it is often misleading. A new variable to hold filtered recipients would be sufficient.
|Tags||No tags attached.|
|Attached Files||0001-reduce-notification-load-fix-NOTIFICATIONRECIPIENTS-.patch [^] (15,191 bytes) 2011-11-07 12:32|
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.
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.
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>
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.
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.
|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|
|Mantis 1.1.7[^] Copyright © 2000 - 2008 Mantis Group|