Neulich beim Kunden, sollte folgendes Szenario zur Benachrichtigung umgesetzt werden. Der Weg, also ob Mail, Slack oder Telegram, soll vom Benutzer abhängig sein, je nach dessen Vorliebe. Ist beim Benutzer eine Mailadresse gesetzt, wird er auch per Mail informiert. Soll die Benachrichtigung hingegen via Telegram bzw. Slack erfolgen, muss der notwendige Empfangs-Hook über ein User-Custom-Attribute angegeben werden.
Wer zu benachrichtigen ist, wird am Host-Objekt angegeben. Die zu benachrichtigen Benutzer können hierbei in einer Liste (host.vars.notification.user) oder über die Mitgliedschaft in einer Gruppe, die ebenfalls am Host in einer Liste (host.vars.notification.groups) angegeben werden, zu gewiesen.
Sei ein Benutzer admin Mitglied der Gruppen icingaadmins und linuxadmins. Soll bei folgendem Host
object Host "localhost" {
import "generic-host"
address = "127.0.0.1"
vars.notifiction = {
groups = [ "icingaadmins", "linuxadmins", "vips" ]
}
}
für den Benutzer admin, aber keine doppelten Nachrichten versandt werden, kann dies zunächst mit dieser Regel umgesetzt werden:
apply Notification "mail-admin to Host {
import "mail-host-notification"
users = [ "admin" ]
assign where "admin" in host.vars.notification.users || f("admin", host.vars.notification.groups)
}
Über den ersten Teil der assign-Regel wäre das Vorhandensein von admin in der Liste der zu benachrichtigen Benutzer am Host abgehandelt. Der zweite Teil ist eine selbstdefinierte Funktion die ein true zurück liefert, sofern der Benutzer mindestens einer der Gruppen aus der Liste angehört.
function f(user,groups) {
if (typeof(groups) == Array) {
for (grp in groups) {
if (grp in get_user(user).groups) {
return true
}
}
}
return false
}
Nun möchte man nicht für jeden Benutzer am Icinga-System eine solche Notification definieren, zumal die Services noch nicht berücksichtigt sind, dann wären deren für jeden Benutzer, immer gleich zwei Notification-Definitionen. Notifications werden vom Config-Compiler immer nach den User- und Usergroup-Objekten ausgewertet, somit kann die Notification zu ein Notification-for, die eine Schleife über alle bekannten Benutzer führt, umgewandelt bzw. erweitert werden:
apply Notification for (user in get_objects(User)) to Host {
import "mail-host-notification"
users = [ user.name ]
assign where user.name in host.vars.notification.users || f(user.name, host.vars.notification.groups)
ignore where ! get_user(user.name).email
}
Die abschließende ignore-Klausel stellt sich, dass keine Notification für Benutzer erzeugt wird, die keine Mailadresse angegeben haben. Sollen nun die selben Benutzer, nicht nur für den Host, sondern auch über Probleme bei den zum Host gehörigen Services benachrichtigt werden, ist das ganze nur noch eine Fingerübung:
apply Notification for (user in get_objects(User)) to Service {
import "mail-service-notification"
users = [ user.name ]
assign where user.name in host.vars.notification.users || f(user.name, host.vars.notification.groups)
ignore where ! get_user(user.name).email
}
Äquivalente Notifications lassen sich damit auch für die alternativen Benachrichtigungswege Slack, Telegram und weitere erstellen.
Kein DSL verfügbar? Die Problematik ist immer die gleiche: Einen Solarpark, ein Lager, ein Büro oder einfach nur ein Standort ohne kabelgebundenen Internetanschluss mit Internet zu versorgen ist nicht immer einfach. Der Breitbandkabelausbau in Deutschland ist zwar in den letzten Jahren gut voran gekommen, jedoch sind noch lange nicht alle weißen Flecken auf der Karte abgedeckt.
