ADMIN 03/14 stellt Erste-Hilfe-Tipps zu Windows-Rettung, Backup und Recovery bei Datenbanken vor und verrät wie man Linux-Systeme vollständig sichert und ... (mehr)

Benachrichtigungen

Bis hierher wurde eine automatische Synchronisation zwischen OCS und OpenNMS konfiguriert. Dabei kann OCS kontrollieren, welche Server in OpenNMS automatisch zu importieren sind. In OpenNMS wird über die Requisition ein Monitoring-Profil bestehend aus Service-Detektoren für Web-, Mail- oder Datenbank-Server angewendet. Außerem braucht man noch Benachrichtigungen für das NOC- und Entwicklungsteam. Um Mails zu versenden, muss OpenNMS mit einem Mailserver kommunizieren. Die Grundkonfiguration zum Mailversand sind im OpenNMS-Wiki im Abschnitt Notification Tutorial [6] detailliert beschrieben.

Beim Import hatten wir bereits festgelegt, dass das OCS-Attribut »Environment« als gleichnamige Surveillance-Category den OpenNMS-Nodes zuzuweisen ist. Diese Surveillance-Category verwenden wir jetzt als Benachrichtigungsfilter.

In OpenNMS werden die beiden Teams Entwicklung und NOC über Gruppen abgebildet. Jeder der beiden Gruppen sind entsprechende OpenNMS-Benutzer des Teams zugeordnet. Die Kontaktinformation – darunter die E-Mail-Adresse des OpenNMS-Benutzers – lassen sich für die Benachrichtigung nutzen. Die Einrichtung der OpenNMS-Benutzer und -Gruppen zeigt Abbildung 8 . Sie lässt sich über die Weboberfläche im Administrationsbereich »Admin | Configure Users, Groups and On-Call Roles« durchführen.

Abbildung 8: OpenNMS-Benutzer und -Gruppen für die Benachrichtigung.

Der nächste Schritt erstellt zwei Pfade für die Benachrichtigung. Das geschieht im Administrationsbereich der Weboberfläche unter »Admin | Configure Notifications | Configure Destination Paths« . Dort werden zwei Pfade – wie in Abbildung 9 unter Punkt (1) gezeigt  – erzeugt. Der neu erstellte Pfad wird bearbeitet und als Ziel wird die Benutzergruppe NOC ausgewählt.

Abbildung 9: Anlegen des Benachrichtigungspfades für das NOC.

Die Konfiguration »Initial Delay« (2) legt fest, wie lange eine Benachrichtigung bei einer aufgetretenen Störung zurückgehalten wird, bevor OpenNMS die E-Mail an die Gruppe versendet. Beim Bearbeiten des Pfades ist darauf zu achten, dass als Benachrichtigungskommando der Wert »javaEmail« (4) ausgewählt ist.

Im letzten Schritt wird die eigentliche Benachrichtigung konfiguriert. Jede Störung erzeugt ein Ereignis in OpenNMS. Ereignisse werden durch einen Bezeichner – die UEI – identifiziert. Für dieses Beispiel konfiguriert der Admin eine Benachrichtigung für ein »nodeLostService« -Ereignis. Das wird erzeugt, wenn beispielsweise ein Server über das Netzwerk mittels ICMP noch erreichbar ist, jedoch ein Service wie HTTP nicht mehr reagiert. Dazu wird über das Hauptmenü im Administrationsbereich unter »Admin | Configure Notification | Configure Event Notifications« die Benachrichtigung für »nodeLostService« bearbeitet. Danach wird angezeigt, für welchen Ereignis-Bezeichner (UEI) die Benachrichtigung angelegt wurde. Der Admin bestätigt die Vorauswahl mit »Next« und wird daraufhin aufgefordert, anzugeben, für welche Systeme und Services die Benachrichtigung gelten soll.

Abbildung 10 zeigt unter Punkt (1), welcher Filter für die Produktivumgebung eingetragen wird. Die hier gezeigte Regel »catincProduction« verwendet das Prefix »catinc« . Dieses Prefix steht für "category include" und ist equivalent zu »categoryname == 'Production'« . Wichtiger Hinweis: Leerzeichen und deutsche Umlaute sollte man in Surveillance-Categories vermeiden. Die Filter und Regelauswertungen können an manchen Stellen Probleme verursachen. Mit der Auswahl »Validate rule results« lässt sich anzeigen, auf welche Systeme die Filterregel anzuwenden sind. Der Assistent wird dann durch Auswählen von »Skip results validation« fortgesetzt.

Abbildung 10: Benachrichtigungsfilter und Ziel auswählen.

Die Abbildung 10 zeigt unter Punkt (2), dass sich die Bezeichnung von »nodeLostService« auf »NOC: nodeLostService« geändert hat. Damit sieht man in der Benutzeroberfläche, dass diese Benachrichtigung für das NOC-Team gedacht ist. Unter »Choose a Path« wählt man den zuvor angelegten Benachrichtigungspfad »NOC-Team« aus.

Falls gewünscht, kann der eigentliche Benachrichtigungstext hier geändert werden. Ein Textgerüst kann mit Variablen wie zum Beispiel »%nodelabel%« gefüllt werden. Diese Variablen füllen sich dann bei einer Störung mit Werten für ein konkretes System. Sicherheitshalber sollte man überprüfen, dass die Benachrichtigung unter »Admin | Notification Status« auf »On« gesetzt ist. Es könnten auch einzelne Benachrichtigungen deaktiviert sein. Deshalb sollte man unter dem Punkt »Admin | Configure Notifications | Configure Event Notifications« den Punkt »NOC: nodeLostService« aktivieren. Für die Benachrichtigung an das Entwicklungsteam wird eine zweite Benachrichtigung für das Ereignis »nodeLostService« nach dem gleichen Schema erzeugt. Wie in Abbildung 10 dargestellt, ist als Filterregel lediglich »catincStage« einzutragen. Für die Benachrichtigung selbst ist als Name »Dev: nodeLostService« verwendbar. Zum Schluss wird noch der Zielpfad für die Benachrichtigung auf »Development-Team« gesetzt.

Fazit

Das Zusammenspiel der beiden Anwendungen OCS und OpenNMS zeigt, dass freie Anwendungen sehr gut von offenen Schnittstellen profitieren können. Über das hier demonstrierte Beispiel hinaus wäre es unter anderem auch denkbar, beim Ausrollen der beteiligten Systeme mit Puppet [7] oder Chef [8] die OCS-Attribute bereits bei der Installation der OCS-Agenten setzen zu lassen.

Wer interessiert ist, Anwendungsfälle wie den hier vorgestellten direkt mit anderen Anwendern und Entwicklern zu besprechen, der ist auf der OpenNMS User Conference [9] vom 8. bis 11. April 2014 an der Universität in Southampton herzlich willkommen. Es werden dort neben vielen Anwendern von OpenNMS auch etliche Entwickler von OCS Inventory und OpenNMS anwesend sein und Rede und Antwort stehen.

Infos

  1. Christian Pape and Ronny Trommer, Durchleuchtet: VMware-Monitoring mit OpenNMS. ADMIN-Magazin 2/2013, S. 98.
  2. OpenNMS-Installation: http://www.opennms.org/wiki/Tutorial_Installation
  3. OCS: http://wiki.ocsinventory-ng.org/index.php/Documentation:Server
  4. OCS-Integration: http://www.opennms.org/wiki/OCS_Integration
  5. Provisioning: http://www.opennms.org/w/images/c/ca/ProvisioningUsersGuide.pdf
  6. Notifications: http://www.opennms.org/wiki/Tutorial_Notifications
  7. Puppet: http://puppetlabs.com
  8. Chef: http://www.getchef.com
  9. OpenNMS-Conference: http://www.opennms.eu

Der Autor

Die Autoren Ronny Trommer und Markus Neumann sind Gründungsmitglieder des gemeinnützigen Vereins OpenNMS Foundation Europe. Die Entwicklung wurde im OpenNMS-Projekt im Rahmen des Google Summer of Code 2013 initiiert und von Markus Neumann als Mentor begleitet. Ronny Trommer ist nebenberuflich als Dozent im Fachbereich Angewandte Informatik an der Hochschule Fulda mit dem Schwerpunkt Integrated Networking tätig.

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Netzwerkmonitoring mit OpenNMS

Im großen Pool der Open-Source-Anwendungen, die sich dem Monitoring verschreiben, will sich OpenNMS durch enorme Skalierbarkeit absetzen. So sollen sich zehntausende Endpunkte an eine Instanz anbinden lassen. Derart auf größere Infrastrukturen ausgerichtet, erlaubt die Software Service-Monitoring, Eventverarbeitung, Sammeln von Performancedaten, Topologie-Erkennung und Visualisierung der Überwachung.
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023