Hi,
Better format your content, you can use back ticks and code blocks to encapsulate configuration, logs, etc. - check the howto here: Create topics and master Markdown formatting (linked in the FAQ as well).
Discourse needs a little learning, I can highly recommend to do the discobot tutorial, you should find a message in your inbox 
That’s a good starting point. Now you’ll know that Icinga doesn’t have any notification objects configured.
Not Notification objects are there
So why is that? You’ll know that you’re using apply rules to generate notification objects for hosts and services.
This generation depends on a pattern match, a boolean expression, which must evaluate to true. Let’s inspect the notification apply rule first.
apply Notification “mail-icingaadmin” to Service {
//....
assign where host.vars.notification.mail
}
The expression will be true, if the host has a custom attribute in vars which is named notification. This is a dictionary, as it also contains a sub key called mail.
Now let’s inspect the host object, does it provide such a custom attribute …
object Host “www4” {
address = “www4”
check_command = “hostalive”
}
Obviously no, it doesn’t.
This is the explanation why no notification objects for services are generated.
Making it work for services
You’re defining the notification custom attribute on the service level instead. This is totally fine, but for now this is just additional information never used anywhere.
Modify the service notification apply rule to actually use the provided details.
- Fetch the values from
service.vars.notification.mail into usersanduser_groups`
- Ensure that the
assign where expression matches on service.vars.notification.mail
apply Notification “mail-icingaadmin” to Service {
import “mail-service-notification”
user_groups = service.vars.notification.mail.groups
//TODO: The same applies for users, try that
// Important: Evaluate this apply rule for all services which provide the notification details.
assign where service.vars.notification.mail
}
Can you improve this for host defaults and service exceptions?
Yes, and you definitely should once the above works.
So, how can we make this more simple to only manage the defaults on the host level, while creating exceptions on the service objects?
Coming back to the notification apply rule. With using conditions, you can check whether the service provides the details and assign the values.
Additionally, the assign where expression needs to be modified to match both, services and hosts with a logical OR condition. Otherwise Icinga won’t recognize this.
apply Notification “mail-icingaadmin” to Service {
import “mail-service-notification”
// Prefer the service object details for notifications
if (service.vars.notification.mail) {
user_groups = service.vars.notification.mail.groups
} else { // Use the host defaults if none specified in the service
user_groups = host.vars.notification.mail.groups
}
//TODO: The same applies for users, try that
// Important: Evaluate this apply rule for all services AND hosts which provide the notification details.
assign where service.vars.notification.mail || host.vars.notification.mail
}
That’s too complicated
Yeah, the DSL allows for many advanced techniques. If you prefer to not use apply rules and attribute fetching from hosts/services, you can also create simple notification objects.
From your example, this looks like this:
object Notification "mail-icingaadmin" {
host_name = "www4"
service_name = "http"
groups = [ "icingaadmins" ]
//...
}
Typing and copying this everything can become hard, that is why apply rules are here to make this more reliable and generic. Decide whatever fits best. You can always refactor the configuration later on after making it work.
Cheers,
Michael
