Mit Version 18 des bekannten IT-Monitoring-Tools OpenNMS ist die Überwachung von Business Services eingeführt worden – bislang war die Sicht auf die Geräteebene und die Services an sich beschränkt. Die Business Services stellen Dienste wie z.B. einen Webshop oder DNS dar, die aus mehreren, teils verschiedenen Services aufgebaut sind, die auf unterschiedlichen Devices betrieben werden können. Auch Infrastruktur-Komponenten können zu einem Business Service zählen.
Während die einzelnen Services zuvor schon überwacht werden konnten, ermöglicht nun der Business Service Monitor eine Berücksichtigung und Darstellung der Abhängigkeiten der Services, so dass es mit diesem einfacher ist, die Zusammenhänge verschiedener Ausfälle zu erkennen und die eigentliche Ursache leichter zu ermitteln. Probleme wie der Ausfall eines Page Sequence Monitors, der das Login in einem Webshop prüft, können durch den Ausfall eines Datenbank-Services auf einem anderen Server verursacht worden sein. Solche Zusammenhänge sind häufig nicht offensichtlich und nur bestimmten Mitarbeitern bekannt, was die schnelle Behebung von Ausfällen erschweren kann. Das Abbilden in Form eines Business Services innerhalb von OpenNMS kann hier Abhilfe schaffen, da jeder Mitarbeiter mit Zugriff auf das Monitoring so die Abhängigkeiten visualisieren kann.
Beispielkonfiguration zum Business Service Monitor
Die folgende Konfiguration eines DNS-Services, der aus drei unabhängigen Servern besteht, soll einen kurzen Einblick in die Möglichkeiten des Business Service Monitors bieten. Diese Beispielkonfiguration entspricht nicht den tatsächlichen Gegebenheiten und beinhaltet einige Freiheiten bezüglich der Sinnhaftigkeit der Konfiguration, um das Beispiel plastischer zu gestalten.
Die Konfiguration der Business Services befindet sich auf auf der Administrationsseite von OpenNMS. In einem frisch aufgesetzten System ist diese Seite noch recht leer. Das Anlegen eines neuen Business Service erfolgt über den Button New Business Service.
Der Dialog Business Service Edit stellt neben der Angabe des Servicenamens unter anderem eine Auswahl der Reduce Functions bereit.
Es gibt drei Functions:
1. Highest Severity
Benutzt zur Alarmierung den höchsten Schweregrad (Severity) aller ausgefallenen Teildienste.
2. Threshold
Benutzt den Schweregrad, dessen Häufigkeit den vorgegebenen Schwellwert überschreitet und am häufigsten vorkommt. Ein Schwellwert von 0.3 (30 Prozent) würde bedeuten, dass zwei von sechs Teildiensten ausfallen müssen, damit der Business Service ausfällt. Dies kann zur Berücksichtigung von Redundanzen eingesetzt werden. Zudem ist auch eine Gewichtung der einzelnen Teildienste möglich, so dass beispielsweise der Ausfall des primären Service schneller oder sofort zum Ausfall des Business Service führt, währenden hierfür der gleichzeitige Ausfall von mehreren Backupservices erforderlich wäre.
3. Highest Severity Above
Hier wird der höchste Schweregrad über einem vorgegebenen Schweregrad verwendet. So können Ausfälle mit dem Schweregrad „Warning“ und niedriger ignoriert werden, während alle höheren Ausfälle mit dem schwersten aufgetretenen Schweregrad verarbeitet werden.
Um den Business Monitor zu definieren, müssen diesem die Services, aus denen er besteht, zugewiesen werden. Diese werden mittels Add Edge aufgenommen.
Die Bezeichnung Edge stammt daher, dass die Service hier nicht als solches aufgenommen werden, sondern ihre Beziehungen untereinander. Es gibt drei Arten von Edges, die erstellt werden können:
1. Child Service
Hier wird auf ein anderen Business Service Monitor verwiesen, der bereits erstellt wurde. So können komplexe Business Services leichter modelliert werden, da man diese aus kleineren Business Services zusammensetzen kann.
2. IP Service
Hiermit werden einzelne Services aufgenommen. Hierbei werden auch grundlegende Abhängigkeiten berücksichtigt. Wenn beispielsweise der Service DNS auf dem Interface 192.168.0.15 aufgenommen wird, wird im Business Monitor nicht nur der Ausfall des DNS-Services, sondern auch der Ausfall des Interfaces oder des Nodes berücksichtigt, was sonst einzeln konfiguriert werden müsste, da OpenNMS diese Ausfälle unterschiedlich handhabt.
3. Reduction Key
Dies dient zur Angabe eigener Reduction Keys, um spezielle Alarme, die beispielsweise durch SNMP-Traps oder Thresholding erzeugt werden, im Business Service Monitor zu berücksichtigen.
Für jeden Edge gibt es zudem eine Mapping-Funktion, mit der angegeben werden kann, wie der Schweregrad eines Alarms bei der Verarbeitung berücksichtigt werden soll. Man hat die Wahl zwischen „Identity“, „Increase“, „Decrease“, „SetTo“ und „Ignore“. Für das obenstehende Beispiel wird zuerst der Business Service Monitor DNS1 eingerichtet, da dieser Server den DNS-Service auf zwei Interfaces anbietet und der Aufbau einer BSM – Hierarchie dargestellt werden soll. Für den Service DNS1 wird „Reduce Functions Threshold“ mit einer Gewichtung von 0.55 verwendet, sodass beide DNS-Services ausfallen müssen, bevor der Business Service ausfällt.
Die beiden Teildienste wurden als IP Service aufgenommen und die Mapping–Funktion „Identity“ gewählt, da hier der Schweregrad der Alarme für die Verarbeitung nicht geändert werden soll. Somit ist der erste Business Service, der in diesem Fall nur die Redundanz des DNS-Services auf zwei unterschiedlichen Interfaces eines Servers darstellt, vollständig definiert.
Jetzt wird der Business Service Global-DNS definiert, der den DNS-Service als ein Zusammenwirken des DNS1 – Service und der DNS-Services zweier weiterer Server darstellt. Hierzu wird der entsprechende Service mit „Reduce Function Threshold“ und einem Schwellenwert von 0.4 definiert, sodass der Monitor erst anschlägt, wenn zwei DNS-Server ausfallen.
Nach der Definition der Service Monitore ist nun auf der Administrations-Seite zu sehen, dass der Service DNS1 unter dem Service „Global DNS“ eingeordnet wurde. Eine genauere Abhängigkeitsstruktur ist hier nicht zu erkennen – diese steht später unter in der „Business Service“-Ansicht bereit, die interessanterweise als Unterkategorie der Topology Map implementiert wurde. Um die erstellten Business Monitore zu aktivieren, ist ein Reload des Deamons über den Button auf der Konfigurationsseite erforderlich.
Die „Business Service“-Ansicht der Topology Map
Nach dem Reload des Deamons kann man auf die Topology Map wechseln und dort unter „View“ die „Business Service“–Ansicht wählen.
Analog zur Topology Map befindet sich immer mindestens ein Business Service im Fokus, von dem aus die Ansicht – je nach eingestelltem Detailgrad – erzeugt wird. In der folgenden Abbildung ist der „Global DNS“-Monitor mit sämtlichen Details ausgewählt. Dort erkennt man deutlich die hierarchische Struktur sowie die Abhängigkeiten der Services voneinander.
Ein interessantes Merkmal ist der „nodeDown“-Service des DNS1, der automatisch beiden Interfaces zugeordnet wird – ein Kennzeichen für seinen Einfluss auf den Business Service. Wird ein Service auf der Map markiert, so werden am linken Rand Statusinformationen über den aktuellen Zustand angezeigt.
Der BSM-Monitor verfügt zudem über einen Simulationsmodus, der über den Menüpunkt Simulate aktiviert werden kann. Im Simulationsmodus können Services markiert und ein Ausfall durch Setzen eines entsprechenden Schweregrades simuliert werden, was die Auswirkungen eines solchen Ausfalls auf den Business Service aufzeigt.
Markiert man einen ausgefallenen Service und wählt aus dem Kontextmenü Impact Analysis aus, so wird ein neuer Graph erstellt, der den Einfluss des ausgefallenen Services auf die aktuelle Situation darstellt.
Diese Funktion kann beim Auslegen der Infrastruktur helfen, da hiermit der Einfluss eines Ausfalls auf den gesamten Business Service veranschaulicht werden kann, was bei Entscheidungen über redundante Auslegungen einzelner Dienste hilfreich ist.
Um die Auswirkungen eines „reellen“ Ausfalls zu zeigen, wurde dieser durch das Setzen von Routen herbeigeführt. Wie in der folgenden Abbildung zu sehen ist, existiert nun auf der Startseite von OpenNMS eine neue Box, die alle aktuellen Business Services mit Problemen anzeigt.
Folgt man dem Link eines ausgefallenen Services, so wird man auf die Darstellung desselben geleitet, sodass man die Ursache für dessen Ausfall recht zügig ermitteln kann.
Wie alle anderen Funktionen von OpenNMS nutzt auch der Business Service Monitor Events für die Kommunikation, sodass hierfür auch Benachrichtigungen eingerichtet werden können.
Bei Fragen zur Konfiguration und Einrichtung sowie allgemeinem Beratungsbedarf zu OpenNMS stehen wir Ihnen gerne zur Verfügung – sprechen Sie uns einfach an!
Autor: Andreas Fuchs
