Bei verschiedenen wichtigen Ereignissen verschickt OpenNMS Benachrichtigungen – unter anderem per E-Mail oder SMS. Diese Benachrichtigungen können individualisiert werden; in diesem Artikel zeigen wir Ihnen, wie das geht. Anmerkung: Die hier beschriebene Individualisierung wirkt sich nicht auf Events und Alarme aus, die auf der GUI dargestellt werden.
In der Standardinstallation von OpenNMS sind bereits neun Notifications definiert, die die gängigsten Fälle abdecken, über die man Informiert werden möchte. Diese anzupassen kann von Interesse sein, falls zusätzliche Informationen hinzugefügt werden oder die Sprache des Benachrichtigungstextes geändert werden soll. Durch eine Anpassung wird auch eine individuellere Benachrichtigung ermöglicht, so dass beispielsweise bei Problemen von einem Router ein anderer Benachrichtungstext versendet wird als bei Problemen mit einem Server. Außerem ist so auch die Benachrichtigung verschiedener Personenkreise möglich.
So geht´s zur Konfiguration
Die Konfiguration der Notification wird über den Punkt „Configure Notifications“ auf der Administrationsseite des Webinterfaces erreicht. Dort finden sich die Punkte „Configure Event Notification“, „Configure Destination Path“ und „Configure Path Outage“. Unter „Configure Destination Path“ können verschiedene Wege (Personengruppen, Benachrichtigungsdienste, Eskalationen) eingerichtet werden, über die die Notifications versandt werden können. Die genaue Einrichtung wird an dieser Stelle nicht im Detail beschrieben. Unter „Configure Event Notification“ finden sich die bereits vorkonfigurierten Norifications.
Hier können bestehende Notifications durch einen Klick auf den Button „Edit“ bearbeitet oder neue Notifications über „Add New Event Notification“ erstellt werden. Da die Anpassung analog zur Erstellung der Notifications geschieht, beschränkt sich das Beispiel auf die Erstellung.
Erstellung einer Notification – Teil 1
Der erste Schritt bei der Erstellung einer Notification ist die Auswahl eines Events, da dieses für das Auslösen der Notification verantwortlich ist. Da OpenNMS mehr als 1.700 Events besitzt, hilft hier die Suche weiter.
In diesem Beispiel wird das „nodeDown“–Event gewählt, indem der entsprechende Eintrag markiert wird. Mit „Next >>>“ wird eine Seite aufgerufen, auf der Filter definiert werden können, mit denen festgelegt werden kann, für welche Geräte oder Services die aktuelle Notification versendet werden soll. 
Die Hauptkonfiguration des Filters findet in der Zeile „Current Rule“ mit einem regulären Ausdruck statt.
Einige Beispiele für die Leistungsfähigkeit der Filter:
• Der Standardfilter „IPADDR IPLIKE *.*.*.*“ bzw. „IPADDR != 0.0.0.0“steht für eine beliebige gültige IP-Adresse.
• „IPADDR IPLIKE 172.16.0.*“ steht für alle IP-Addressen im Subnetz 172.16.0.0/24
• „IPADDR IPLIKE 172.16.0.1-10“ repräsentieren die ersten 10 Adressen im Subnetz 172.16.0.0/24
• „IPADDR IPLIKE 172.16.0.1,5,12,20-30“ stellen die Adressen 172.16.0.1, 172.16.0.5, 172.16.0.12 und die Adressen 172.16.0.20 bis 172.16.0.30 dar
• „IPADDR IPLIKE 172.16-18.0.1,2,3“ sind die ersten drei IP-Adressen der Subnetze 172.16.0.0/16, 172.17.0.0/16 und 172.18.0.0/16
• „(IPADDR IPLIKE 172.16.0.*) & („IPADDR != 172.16.0.20)““ ist das gesamte 172.16.0.0/24 Netz ohne die IP-Adresse 172.16.0.20
• „(IPADDR IPLIKE 172.16.0.*) | ( (IPADDR IPLIKE 10.5.*.*) stellt das Subnet 172.16.0.0/24 und 10.5.0.0/16 dar
Mit diesen Filtern ist es recht einfach möglich, die Interfaces auszuwählen, für die die Notification gesendet werden soll. Diese Methode der Filterung wird allerdings etwas problematisch, sobald es sich um viele, nicht zusammenhängende IP-Adressen handelt. Auch, wenn häufig neue Geräte hinzukommen und entfernt werden, muss der Filter immer wieder angepasst werden. In diesen Fällen bietet sich die Nutzung von „Surveillance Categorys“ an.
Exkurs: Surveillance Categories
Surveillance Categories stellen frei definierbare Gruppen dar, in denen Geräte zusammengefasst werden können; sie können beliebig viele Geräte enthalten. Ein Gerät kann zu beliebig vielen Surveillance Categorys gehören. Beispielsweise können die Kategorien „Router“ und „Switches“ angelegt werden, denen die entsprechenden Geräte zugewiesen werden. Wird weiterhin eine Kategorie „Backbone“ angelegt, in die nur die zentralen Router und Switches aufgenommen werden, ergibt sich bereits eine recht große Variationsmöglichkeit der Filter.
Beispiele für das Filtern mit Surveillance Categories:
• „catincRouter“ – Alle Geräte in der Kategorie Router
• „catincRouter & catincBackbone“ – Nur Geräte, die den beiden Kategorien Router und Backbone angehören
• „catincRouter | catincSwitch“ – Alle Geräte, die mindestens einer der beiden Kategorien angehören
• „catincSwitch & (categoryName != Backbone)“ – Alle Switche, die keine zentralen Komponenten sind
Die Verwendung von Surveillance Categories kann die Erstellung von Filtern vereinfachen und diese gleichzeitig auch lesbarer machen.
Verschiedene Services auf einem Interface
Auch wenn verschiedene Services auf ein und demselben Interface unterschiedlich behandelt werden sollen, bietet OpenNMS eine komfortable Filtermöglichkeit. Die Abbildung 
zeigt ein Beispielsetup, in dem der Service HTTPS für die Geräte in der Kategorie „VoIP-Telefon“ gesondert benachrichtigt werden sollen. Wie hier zu sehen ist, geben die beiden Auswahlfenster „Service“ und „Not Service“ nur die Services dar, die auf den bereits gefilterten Geräten zur Verfügung stehen. Durch Auswahl eines oder mehrerer Dienste werden diese dem Filter hinzugefügt.
Erstellung einer Notification – Teil 2
Sind im Filter die gewünschten Geräte, Interfaces und Services für die Notification ausgewählt, öffnet „Skip results validation >>>“ direkt die Konfiguration des Nachrichtentextes; alternativ gibt „Validate rule results >>>“ eine Liste aus, die alle Interface–Service-Kombinationen anzeigt, für die die Notification versendet wird. 
Auf letzten Seite der Notification–Konfiguration wird neben der Festlegung der Benachrichtigungstexte auch die Zustellung in Form des „Destination Path“ ausgewählt. Der „Destination Path“ regelt, wer mit welcher Verzögerung über welches Kommunikationsmittel benachrichtigt wird und ermöglicht so erst eine erfolgreiche Benachrichtigung. Da die Einrichtung des „Destination Path“ stark mit der Verwaltung von Nutzer, Gruppen und Rollen zusammenhängt, soll an dieser Stelle nicht detailliert auf das Vorgehen eingegangen werden. Nur soviel: Pro Notification kann (und muss) immer nur ein „Destination Path“ angegeben werden.
Einrichtung der Benachrichtigungstexte
Die Boxen für die Benachrichtigungen lassen beliege Texte zu, wobei darauf geachtet werden sollte, diese nicht zu lang werden zu lassen. Dies gilt vor allem beim Feld „Short Message“, das den Text für die Benachrichtigung über Kurznachrichtendienste wie z.B. SMS enthält.
Der große Vorteil ist hier die Verwendung von Platzhaltern. In diesem Beispiel wird nur der Platzhaler „%nodelabel%“ verwendet, der durch den Namen des Gerätes ersetzt wird. Die Parameter können auch genutzt werden um beispielsweise in E-Mail-Benachrichtigungen automatisch einen Link auf die OpenNMS-Seite des ausgefallenen Gerätes in OpenNMS einzubetten. Dieser würde – angenommen, OpenNMS wäre unter der Domain „example.com“ erreichbar – wie folgt lauten:
http://example.com/opennms/element/node.jsp?node=%nodeid%
Bei der Verwendung von Platzhaltern ist allerdings darauf zu achten, dass diese sich auf die Informationen in dem Event beziehen, das die Notification auslöst. Dies führt beispielsweise dazu, dass bei der Benachrichtigung eines „nodeDown“–Events kein „%interface%“ genutzt werden kann, bei einem „nodeLostService“–Event hingegen schon. Bei Events, die aus Syslog oder SNMP–Traps generiert werden, können Informationen, die in den Traps enthalten aber nicht als vorgegebene Platzhalter verfügbar sind, mit „%parm[<Parametername>]%“ oder „%parm[<Parameterposition>]%“ abgefragt werden. Dies ermöglicht unter anderem die Verwendung von „VarBinds“ in den Notifications.
Für die Verwaltung der Benachrichtigung muss diese noch einen Namen erhalten, unter dem diese gespeichert werden soll. Die Konfiguration wird mit „Finish >>>“ abgeschlossen. Zu beachten ist, dass alle neu erstellten Notifications im Alarmierungsstatus „Off“ erzeugt werden – neue Notifications müssen erst aktiviert werden. Wurde eine bestehende Notification angepasst, behält diese ihren Aktivierungsstatus. Übrigens: Versandte Notifications werden von OpenNMS dokumentiert und können über den Menüeintrag „Status > Notifications“ eingesehen werden.
Weitere Informationen zu den Filtern in OpenNMS gibt´s im OpenNMS-Wiki – oder Sie fragen einfach uns!
Autor: Andreas Fuchs
