--0016360e3caa4f4c9f046f0df33b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Hi,
We make heavy use of escalations in our Nagios installation; a
behavior of Nagios that was annoying some of our users was that if
they specified 'r' in an escalation they would receive recovery
notifications for services recovering from states that were not
mentioned in the escalation definition (escalation_options field).
Example:
define serviceescalation {
hostgroup_name nagios_hosts
contact_groups admins
first_notification 1 ; notify right away (1st notification)
last_notification 0 ; notify until service changes state
notification_interval 240 ; default to 4 hour re-notify
escalation_period 24x7
service_description .*
escalation_options c,r
register 0
}
In this case we would receive recovery service escalations for
services returning to OK from WARNING when we never were sent a
WARNING escalation notification because it is not a state listed in
escalation_options. With the patch a recovery is only sent if the
previous state of the service was CRITICAL and an escalation
notification had been sent out because the escalation rule had
previously matched on CRITICAL.
I have added code to
int is_valid_escalation_for_service_notification(service *svc,
serviceescalation *se, int options)
in notifications.c to add this logic:
If escalation is of type recovery:
* If the escalation rule does not specify recovery, return FALSE
(original logic)
* If the escalation rule specifies one or more problem states
** If this is the first hit on this escalation rule, return FALSE as
no escalation was sent previously for a problem with this rule
** If the previous problem state of the service matching the
escalation is NOT listed in the escalation, return FALSE as we did not
previously send out an problem escalation for the state this service
is recovering from
This also allows the user to specify JUST 'r' in the
escalation_options field and have the escalation rule work as expected
.. recovery notifications will be sent as they match the rule
irregardless of any previous problem states.
Our users have found this to be a very useful patch and have liked the
reduced number of recovery escalation notifications being sent out at
2 AM :p for services they never received a problem escalation
notification alert for.
Patched against Nagios 3.0.3.
I have done my best to have the style of the code conform to the
coding style used in the rest of the file; my apologies if I did not
get the style right.
- Max
--0016360e3caa4f4c9f046f0df33b
Content-Type: application/octet-stream; name="notifications.c.patch"
Content-Disposition: attachment; filename="notifications.c.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fxbq5paz0
LS0tIGJhc2Uvbm90aWZpY2F0aW9ucy5jLm9yaWcJMjAwOS0wNy0xMSAwMDowMzozMy4wMDAwMDAw
MDAgLTA0MDAKKysrIGJhc2Uvbm90aWZpY2F0aW9ucy5jCTIwMDktMDctMTQgMTc6MTc6MjAuMDAw
MDAwMDAwIC0wNDAwCkBAIC04MjMsOCArODIzLDM2IEBACiAJCXJldHVybiBGQUxTRTsKIAogCS8q
IHNraXAgdGhpcyBlc2NhbGF0aW9uIGlmIHRoZSBzdGF0ZSBvcHRpb25zIGRvbid0IG1hdGNoICov
Ci0JaWYoc3ZjLT5jdXJyZW50X3N0YXRlPT1TVEFURV9PSyAmJiBzZS0+ZXNjYWxhdGVfb25fcmVj
b3Zlcnk9PUZBTFNFKQotCQlyZXR1cm4gRkFMU0U7CisJaWYoc3ZjLT5jdXJyZW50X3N0YXRlPT1T
VEFURV9PSyl7CisJCWlmIChzZS0+ZXNjYWxhdGVfb25fcmVjb3Zlcnk9PUZBTFNFKQorCQkJcmV0
dXJuIEZBTFNFOworCisJCS8qIElmIHRoZSBlc2NhbGF0aW9uIHNwZWNpZmllcyBvbmUgb3IgbW9y
ZSBhbGVydCBzdGF0ZXMgKG5vbi1vayksICAqLworCQkvKiBvbmx5IGFsbG93IHRoZSBlc2NhbGF0
aW9uIGlmIHRoZSBub24tb2sgc3RhdGUgZnJvbSB0aGUgcHJldmlvdXMgKi8KKwkJLyogc2Vydmlj
ZSBzdGF0ZSBpcyBsaXN0ZWQgaW4gdGhlIGVzY2FsYXRpb24gYW5kIGlmIHRoZSBlc2NhbGF0aW9u
ICovCisJCS8qIGlzIE5PVCB0aGUgZmlyc3QgZXNjYWxhdGlvbiAoYXMgdGhhdCB3b3VsZCBtZWFu
IHRoZXJlIHdhcyBubyAgICAqLworCQkvKiBub24tb2sgZXNjYWxhdGlvbiBzZW50IGJlZm9yZSB0
aGUgcmVjb3ZlcnkgZXNjYWxhdGlvbikuICAgICAgICAgKi8KKworCQlpZiAoKHNlLT5lc2NhbGF0
ZV9vbl91bmtub3duIT1GQUxTRSkgfHwgKHNlLT5lc2NhbGF0ZV9vbl93YXJuaW5nIT1GQUxTRSkg
fHwgKHNlLT5lc2NhbGF0ZV9vbl9jcml0aWNhbCE9RkFMU0UpKXsKKwkJCQorCQkJLyogSWYgdGhl
IHJlY292ZXJ5IG
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]