Hi all,
just stumbled upon a “bunch of problems” in a customers system.
The system is “constantly” sending messages for checks that have already sent a notification.
And it looks like the checks that are in a non-ok state are behaving like volatile checks:
As you can see the switch from critical to unknown directly becomes a hard state as well as vice versa AND it’s triggering a re-renotification.
Is this normal behavior?
volatile was set to false in the service template.
template Service "generic-service" {
max_check_attempts = "3"
check_interval = 5m
retry_interval = 1m
enable_notifications = true
enable_active_checks = true
enable_passive_checks = false
enable_event_handler = true
enable_flapping = true
enable_perfdata = true
volatile = false
}
notification interval is set to 0, so no re-notifications.
Notification rule is build to send 24/7 two three different contacts. Two of those contacts are limited to a non-office-hours time period.
Checked via API: Attribute no_more_notifications is set to true so there normally shouldn’t be any more notifications for this problem.
apply Notification "alle-Servicechecks" to Service {
import "mail-service-notification2"
period = "24x7"
assign where match("*", service.name) && ! match("*cpu*", service.name) && service.vars.nrpe_command != "check_backupexec_backups" && !(service.vars.snmp_storage_name == "Physical Memory" || service.vars.snmp_storage_name == "Virtual Memory" || service.name == "Linux-Updates" || service.name == "LDAPS-Events")
users = [ "User24/7", "User1_non_work", "User2_non_work" ]
}
I just changed the notification rules to be separate for the 24/7 and non-workhours users, to be able to delay notifications for the latter.
Maybe this will also fix this strange behavior, will check in the next couple of days.
Any other ideas were to look are apprechiated 
Cheers
