icinga2 - The Icinga 2 network monitoring daemon (version: r2.10.5-1)
I am member of two groups. There is one service, that has notification assigned to both of that groups. Result is that I get two notifications for that service.
If I remember correctly, wasnt there a mechanism to prevent notifications getting sent to the same person multiple times? Like a filter before sending?
Yes, while your user is in two groups, it is still only one user and so only should get one notification.
Just to ensure and because I had an similar issue in the past, there are not two different users with your mail address or a mailing list (probably the wrong term) containing your email as a second user?
Good idea, but no. Every user and every email address is unique.
What do you see in /var/log/icinga2/icinga2.log with the label
“informaton/Notification”?
Does it show the machine sending two notifications at the same time?
Does it show any difference between the reasons for those notifications being
sent?
Antony.
Another idea: Can you see the sending system in the email header? If notification feature is enabled somewhere else a different host like a satellite could be sending.
Yes, I do see two notifications being sent, the reason seems to be that two notification rules hit. My user is member of two groups that receive notification for a service.
Checking the group settings and the log it looks to me like Icinga is going though the groups and sends notifications - without checking if that user has got notification about this issue before.
object User "MY-USER" {
import "generic-user"
display_name = "THIS IS ME"
groups = [ "oncall", "sdm", "veeam-admins" ]
email ="MY EMAIL"
}
apply Notification "mail-bereitschaft" to Service {
import "mail-service-notification"
user_groups = [ "oncall" ]
states = [ Warning, Critical, OK, Unknown ]
interval = 12h
assign where service.vars.oncall
}
apply Notification "veeam-alert" to Service {
import "mail-service-notification"
user_groups = [ "veeam-admins","sdm" ]
interval = 0
assign where service.vars.veeam_alert
}
230835 [2021-06-10 06:14:51 +0200] information/Checkable: Checking for configured notifications for object 'HOST!Veeam Backup Success Percent'
230836 [2021-06-10 06:14:51 +0200] information/Notification: Sending 'Problem' notification 'HOST!Veeam Backup Success Percent!mail-bereitschaft' for user 'MY-USER'
230837 [2021-06-10 06:14:51 +0200] information/Notification: Sending 'Problem' notification 'HOST!Veeam Backup Success Percent!veeam-alert' for user 'USER1'
230838 [2021-06-10 06:14:51 +0200] information/Notification: Sending 'Problem' notification 'HOST!Veeam Backup Success Percent!veeam-alert' for user 'USER2'
230839 [2021-06-10 06:14:51 +0200] information/Notification: Sending 'Problem' notification 'HOST!Veeam Backup Success Percent!veeam-alert' for user 'USER3'
230840 [2021-06-10 06:14:51 +0200] information/Notification: Sending 'Problem' notification 'HOST!Veeam Backup Success Percent!veeam-alert' for user 'USER$'
230841 [2021-06-10 06:14:51 +0200] information/Notification: Sending 'Problem' notification 'HOST!Veeam Backup Success Percent!veeam-alert' for user 'MY-USER'
Also a good idea, but I got only one master configured to send notifications. Sadly, the header is being cleaned befroe it leaves the company, so I don’t see the details interesting to us.
You may have to split the notification rule into 2, each addressing only one contact group. Then perhaps also have the one rule being an escalation of the other (i.e. send notifications after differing initial wait intervals.) We’ve learnt over the years that it’s best to build your Icinga2 notification rules that way - addressing one contact or contact group, i.e. each rule being “made responsible” for that target, sort of.
Just make sure your notif. rules do not overlap in terms of addressees, time periods, intervals. They are apply rules, so the last one deployed “wins”…
P.S.: You may also want to have a look at dependencies. Perhaps there are too many mails being sent. 
P.P.S.: I just noticed that you have different interval times already. Maybe just make the “bereitschaft” rule an escalation one, that only triggers 10 minutes after the “veeam” one has done its stuff? (Once off, if I read that correctly.) Then the “veeam” guys have a chance to acknowledge the problem in the GUI before the “bereitschaft” guys get woken up…