OpenNMS: Indi­vi­du­elle Anpas­sung der Notifications

Bei verschie­denen wich­tigen Ereig­nissen verschickt OpenNMS Benach­rich­ti­gungen - unter anderem per E-Mail oder SMS. Diese Benach­rich­ti­gungen können indi­vi­dua­li­siert werden; in diesem Artikel zeigen wir Ihnen, wie das geht. Anmer­kung: Die hier beschrie­bene Indi­vi­dua­li­sie­rung wirkt sich nicht auf Events und Alarme aus, die auf der GUI darge­stellt werden.
In der Stan­dard­in­stal­la­tion von OpenNMS sind bereits neun Noti­fi­ca­tions defi­niert, die die gängigsten Fälle abde­cken, über die man Infor­miert werden möchte. Diese anzu­passen kann von Inter­esse sein, falls zusätz­liche Infor­ma­tionen hinzu­ge­fügt werden oder die Sprache des Benach­rich­ti­gungs­textes geän­dert werden soll. Durch eine Anpas­sung wird auch eine indi­vi­du­el­lere Benach­rich­ti­gung ermög­licht, so dass beispiels­weise bei Problemen von einem Router ein anderer Benach­rich­tungs­text versendet wird als bei Problemen mit einem Server. Außerem ist so auch die Benach­rich­ti­gung verschie­dener Perso­nen­kreise möglich.

So geht´s zur Konfiguration

Die Konfi­gu­ra­tion der Noti­fi­ca­tion wird über den Punkt “Confi­gure Noti­fi­ca­tions” auf der Admi­nis­tra­ti­ons­seite des Webin­ter­faces erreicht. Dort finden sich die Punkte “Confi­gure Event Noti­fi­ca­tion”, “Confi­gure Desti­na­tion Path” und “Confi­gure Path Outage”. Unter “Confi­gure Desti­na­tion Path” können verschie­dene Wege (Perso­nen­gruppen, Benach­rich­ti­gungs­dienste, Eska­la­tionen) einge­richtet werden, über die die Noti­fi­ca­tions versandt werden können. Die genaue Einrich­tung wird an dieser Stelle nicht im Detail beschrieben. Unter “Confi­gure Event Noti­fi­ca­tion” finden sich die bereits vorkon­fi­gu­rierten Norifications.abbildung-1
Hier können bestehende Noti­fi­ca­tions durch einen Klick auf den Button “Edit” bear­beitet oder neue Noti­fi­ca­tions über “Add New Event Noti­fi­ca­tion” erstellt werden. Da die Anpas­sung analog zur Erstel­lung der Noti­fi­ca­tions geschieht, beschränkt sich das Beispiel auf die Erstellung.

Erstel­lung einer Noti­fi­ca­tion - Teil 1

Der erste Schritt bei der Erstel­lung einer Noti­fi­ca­tion ist die Auswahl eines Events, da dieses für das Auslösen der Noti­fi­ca­tion verant­wort­lich ist. Da OpenNMS mehr als 1.700 Events besitzt, hilft hier die Suche weiter.abbildung-2
In diesem Beispiel wird das “nodeDown”–Event gewählt, indem der entspre­chende Eintrag markiert wird. Mit “Next »>” wird eine Seite aufge­rufen, auf der Filter defi­niert werden können, mit denen fest­ge­legt werden kann, für welche Geräte oder Services die aktu­elle Noti­fi­ca­tion versendet werden soll. abbildung-3 abbildung-4
Die Haupt­kon­fi­gu­ra­tion des Filters findet in der Zeile “Current Rule” mit einem regu­lären Ausdruck statt.
Einige Beispiele für die Leis­tungs­fä­hig­keit der Filter:
• Der Stan­dard­filter „IPADDR IPLIKE *.*.*.*“ bzw. „IPADDR != 0.0.0.0“steht für eine belie­bige 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ä­sen­tieren 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 Inter­faces auszu­wählen, für die die Noti­fi­ca­tion gesendet werden soll. Diese Methode der Filte­rung wird aller­dings etwas proble­ma­tisch, sobald es sich um viele, nicht zusam­men­hän­gende IP-Adressen handelt. Auch, wenn häufig neue Geräte hinzu­kommen und entfernt werden, muss der Filter immer wieder ange­passt werden. In diesen Fällen bietet sich die Nutzung von “Surveil­lance Cate­gorys” an.

Exkurs: Surveil­lance Categories

Surveil­lance Cate­go­ries stellen frei defi­nier­bare Gruppen dar, in denen Geräte zusam­men­ge­fasst werden können; sie können beliebig viele Geräte enthalten. Ein Gerät kann zu beliebig vielen Surveil­lance Cate­gorys gehören. Beispiels­weise können die Kate­go­rien “Router” und “Swit­ches” ange­legt werden, denen die entspre­chenden Geräte zuge­wiesen werden. Wird weiterhin eine Kate­gorie “Back­bone” ange­legt, in die nur die zentralen Router und Swit­ches aufge­nommen werden, ergibt sich bereits eine recht große Varia­ti­ons­mög­lich­keit der Filter.
Beispiele für das Filtern mit Surveil­lance Categories:
• „catin­c­Router“ - Alle Geräte in der Kate­gorie Router
• „catin­c­Router & catin­c­Back­bone“ - Nur Geräte, die den beiden Kate­go­rien Router und Back­bone angehören
• „catin­c­Router | catincS­witch“ - Alle Geräte, die mindes­tens einer der beiden Kate­go­rien angehören
• „catincS­witch & (cate­go­ry­Name != Back­bone)“ - Alle Switche, die keine zentralen Kompo­nenten sind
Die Verwen­dung von Surveil­lance Cate­go­ries kann die Erstel­lung von Filtern verein­fa­chen und diese gleich­zeitig auch lesbarer machen.

Verschie­dene Services auf einem Interface

Auch wenn verschie­dene Services auf ein und demselben Inter­face unter­schied­lich behan­delt werden sollen, bietet OpenNMS eine komfor­table Filter­mög­lich­keit. Die Abbildung abbildung-5
zeigt ein Beispiel­setup, in dem der Service HTTPS für die Geräte in der Kate­gorie “VoIP-Telefon” geson­dert benach­rich­tigt werden sollen. Wie hier zu sehen ist, geben die beiden Auswahl­fenster “Service” und “Not Service” nur die Services dar, die auf den bereits gefil­terten Geräten zur Verfü­gung stehen. Durch Auswahl eines oder mehrerer Dienste werden diese dem Filter hinzugefügt.

Erstel­lung einer Noti­fi­ca­tion - Teil 2

 
Sind im Filter die gewünschten Geräte, Inter­faces und Services für die Noti­fi­ca­tion ausge­wählt, öffnet “Skip results vali­da­tion »>” direkt die Konfi­gu­ra­tion des Nach­rich­ten­textes; alter­nativ gibt “Vali­date rule results »>” eine Liste aus, die alle Interface–Service-Kombinationen anzeigt, für die die Noti­fi­ca­tion versendet wird. abbildung-6
Auf letzten Seite der Notification–Konfiguration wird neben der Fest­le­gung der Benach­rich­ti­gungs­texte auch die Zustel­lung in Form des “Desti­na­tion Path” ausge­wählt. Der “Desti­na­tion Path” regelt, wer mit welcher Verzö­ge­rung über welches Kommu­ni­ka­ti­ons­mittel benach­rich­tigt wird und ermög­licht so erst eine erfolg­reiche Benach­rich­ti­gung. Da die Einrich­tung des “Desti­na­tion Path” stark mit der Verwal­tung von Nutzer, Gruppen und Rollen zusam­men­hängt, soll an dieser Stelle nicht detail­liert auf das Vorgehen einge­gangen werden. Nur soviel: Pro Noti­fi­ca­tion kann (und muss) immer nur ein “Desti­na­tion Path” ange­geben werden.

Einrich­tung der Benachrichtigungstexte

Die Boxen für die Benach­rich­ti­gungen 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 Benach­rich­ti­gung über Kurz­nach­rich­ten­dienste wie z.B. SMS enthält.
Der große Vorteil ist hier die Verwen­dung von Platz­hal­tern. In diesem Beispiel wird nur der Platzhaler “%node­label%” verwendet, der durch den Namen des Gerätes ersetzt wird. Die Para­meter können auch genutzt werden um beispiels­weise in E-Mail-Benach­rich­ti­gungen auto­ma­tisch einen Link auf die OpenNMS-Seite des ausge­fal­lenen Gerätes in OpenNMS einzu­betten. Dieser würde - ange­nommen, OpenNMS wäre unter der Domain “example.com” erreichbar - wie folgt lauten:
http://example.com/opennms/element/node.jsp?node=%nodeid%
Bei der Verwen­dung von Platz­hal­tern ist aller­dings darauf zu achten, dass diese sich auf die Infor­ma­tionen in dem Event beziehen, das die Noti­fi­ca­tion auslöst. Dies führt beispiels­weise dazu, dass bei der Benach­rich­ti­gung eines “nodeDown”–Events kein “%inter­face%” genutzt werden kann, bei einem “nodeLostService”–Event hingegen schon. Bei Events, die aus Syslog oder SNMP–Traps gene­riert werden, können Infor­ma­tionen, die in den Traps enthalten aber nicht als vorge­ge­bene Platz­halter verfügbar sind, mit “%parm[<Parametername>]%” oder “%parm[<Parameterposition>]%” abge­fragt werden. Dies ermög­licht unter anderem die Verwen­dung von “VarBinds” in den Notifications.
Für die Verwal­tung der Benach­rich­ti­gung muss diese noch einen Namen erhalten, unter dem diese gespei­chert werden soll. Die Konfi­gu­ra­tion wird mit “Finish »>” abge­schlossen. Zu beachten ist, dass alle neu erstellten Noti­fi­ca­tions im Alar­mie­rungs­status “Off” erzeugt werden - neue Noti­fi­ca­tions müssen erst akti­viert werden. Wurde eine bestehende Noti­fi­ca­tion ange­passt, behält diese ihren Akti­vie­rungs­status. Übri­gens: Versandte Noti­fi­ca­tions werden von OpenNMS doku­men­tiert und können über den Menü­ein­trag “Status > Noti­fi­ca­tions” einge­sehen werden.
abbildung-7abbildung-8
 
Weitere Infor­ma­tionen zu den Filtern in OpenNMS gibt´s im OpenNMS-Wiki - oder Sie fragen einfach uns!
 
Autor: Andreas Fuchs

Schreibe einen Kommentar

Cookie Einstellungen
Diese Website verwendet Cookies, um die bestmögliche Funktionalität zu gewährleisten. Mehr lesen

Akzeptiere alle Cookies Speichern