OpenNMS 19.0.1: Neuig­keiten, Weiter­ent­wick­lungen und kleine Helfer

Das Team hinter der beliebten IT-Moni­to­ring-Soft­ware OpenNMS war in letzter Zeit sehr aktiv und hat kurz hinter­ein­ander die Horizon-Versionen 18.0.4 (9. Februar), 19.0.0 (13. Februar) und 19.0.1 (22. Februar) veröf­fent­licht. Die Version 18.0.4 dient als Abschluss der 18er-Version und enthält ausschließlich Bugfixes. Die 19.0.0 kommt hingegen mit einigen internen Neue­rungen wie dem Upgrade des Jetty–Webservers auf die Version 9.4. Die Umfang­reichste Neue­rung ist die Einfüh­rung der OpenNMS-Minions, die nun endlich produktiv einge­setzt werden können. Die Einfüh­rung der Minions hat zudem zu inter­es­santen Neben­ef­fekten geführt, unter anderem ist jetzt auch das Über­wa­chen von über­lap­penden IP-Adress­be­rei­chen möglich. Wir haben uns die aktu­elle Version einmal näher angeschaut.

Allge­meine Neuerungen

Die ersten Neue­rungen der neuen OpenNMS-Version fallen gleich beim Aufruf der Start­seite ins Auge: Hier wurde die GeoMap inte­griert, die eine Über­sicht über die Stand­orte eines Netz­werks bietet. Für das inten­si­vere Arbeiten mit der Map ist diese - in gewohnter Weise - unter dem Menü­punkt “Maps” zu finden. Eine weitere Neue­rung, die hier im Quick-Search-Bereich bereits erkennbar ist, ist die bessere Inte­gra­tion von IPv6 in das Bedienkonzept.

Unter dem Menü­ein­trag „Status – Trend“ ist jetzt ein Trend Chart zu finden, der den zeit­li­chen Verlauf der Ausfälle und Alarme von Diensten, Nodes und Busi­ness Services protokolliert.

Auch in “Maps” gab es Anpas­sungen des Layouts - beispiels­weise sind die Bedien­ele­mente in der Topo­logy Map nun linear aufgereiht.

Eine weitere Neue­rung ist die Verla­ge­rung der Berech­ti­gungs­ver­wal­tung in die Webober­fläche. Während es in der 18er Version noch notwendig war, die Datei „magic-users.properties“ mit einem Editor zu bearbeiten, um einem Nutzer Berech­ti­gungen zu erteilen oder zu entziehen, ist die Berech­ti­gungs­ver­wal­tung nun bequem über die Ober­fläche zu erledigen.

Eine klei­nere Neue­rung im Bedien­kon­zept ist, dass das “Node-Disco­very” nun auch für eine einma­lige Aufnahme aller Nodes in einem Netz­werk zu Verfü­gung steht, was für eine schnelle Erst­auf­nahme sehr prak­tisch ist - oder, wenn kein dauer­haftes Disco­very gewünscht ist.

Nütz­liche Helfer­lein: Minions

Die “Minions” wurden schon vor einiger Zeit ange­kün­digt und haben es mit der Version 19.0.0 offi­ziell in OpenNMS geschafft. Der Zweck der Minions ist das einfa­chere Erwei­tern des Über­wa­chungs­be­rei­ches. Wollte man zuvor ein Netz­werk an einem anderen Standort über­wa­chen, welcher beispiels­weise mittels Fire­walls vor direkten Zugriff geschützt wurde, so musste man sich mittels NAT oder dem Aufbau von Tunneln behelfen, was zu einem größeren Set von Fire­wall-Regeln führen konnte. Mit der Verwen­dung der Minions muss nur noch eine Verbin­dung von Minion und OpenNMS–Installation auf einer über­sicht­li­chen Anzahl von Ports (in der Regel der Port der Webprä­senz von OpenNMS und der Port 61616) einge­richtet werden. Die Minions über­nehmen das Polling und die Data­collec­tion vor Ort und über­mit­teln die Daten an den OpenNMS–Server, der auch die zentrale Verwal­tung der Minions übernimmt.
Nach­fol­gend soll die Instal­la­tion und Konfi­gu­ra­tion der Minions sowie deren Verwen­dung anhand eines Beispiels vorge­stellt werden, das sich an der Anlei­tung aus der OpenNMS–Dokumentation anlehnt.

Anwen­dungs­bei­spiel

Instal­la­tion und Konfiguration

Zuerst muss in OpenNMS ein Nutzer ange­legt werden, der den Minions den Zugriff auf OpenNMS erlaubt. Für das Beispiel wurde über die Webober­fläche der Nutzer „minion“ mit dem Pass­wort „minion“ ange­legt und diesem die Rolle „ROLE_MINION“ zuge­wiesen. Damit die Minions mit OpenNMS kommu­ni­zieren können,  muss noch die Schnitt­stelle für den Acti­veMQ broker so einge­richtet werden, dass diese auch von außen erreicht werden kann. Hierfür muss im etc–Verzeichnis von OpenNMS die Datei „opennms-activemq.xml“ mit einem Editor geöffnet und die Kommen­tar­zei­chen um die Zeile
„<trans­port­Con­nector name=“openwire” uri=“tcp://0.0.0.0:61616?useJmx=false&amp;maximumConnections=1000&amp;wireformat.maxFrameSize=104857600”/>“
entfernt werden. Nach einem Neustart von OpenNMS ist dessen Konfi­gu­ra­tion hier abgeschlossen.
Die Minions selbst sind momentan nur für den Einsatz unter Red Hat Linux und CentOS verfügbar, daher wird an dieser Stelle die Instal­la­tion für ein CentOS 7 und OpenNMS Horizon 19.0.1 beschrieben.
Als ersten Schritt bindet man das Repo­si­tory von Horizon ein und instal­liert den Minion mit „yum –y install opennms-minion“.

Die Instal­la­tion bringt ca. 437 MB an Dateien mit, die unter „/opt/minion/“ abge­legt werden. Um den Minion bei System­start auto­ma­tisch hoch­zu­fahren werden mittels „systemctl enable minion“ die entspre­chenden Verknüp­fungen ange­legt. „systemctl start minion“ startet ihn sofort.
Die Konfi­gu­ra­tion erfolgt am einfachsten über die Shell auf die man sich mittels „ssh –p 8201 Admin@127.0.0.1“ und dem Pass­wort „admin“ verbinden kann.

Nach dem Einloggen muss die Verbin­dung zu OpenNMS einge­richtet werden, was über httpd_url und broler-url geschieht. Sofern nicht von der Stan­dard­kon­fi­gu­ra­tion abge­wi­chen wird, können diese aus dem Beispiel über­nommen und die IP oder der Domain­namen des OpenNMS-Servers einge­tragen werden. Die Option „loca­tion“ hat eine beson­dere Bedeu­tung, da OpenNMS damit fest­legt, über welchen Weg ein Node über­wacht wird; dieser Wert sollte daher eindeutig sein. Die Loca­tion „Default“ wird allen Nodes zuge­wiesen, die direkt von OpenNMS über­wacht werden, und ist daher bereits vergeben. Nachdem man die Konfi­gu­ra­tion mit „config:update“ über­nommen hat, setzt man noch den Nutzer und das Pass­wort für den Zugriff auf OpenNMS.

Nach einem Neustart des Minion-Dienstes sollte sich dieser bereits mit OpenNMS verbinden - die passenden Fire­wall­kon­fi­gu­ra­tionen vorausgesetzt.

Über­prü­fung der Verbindung

Die Verbin­dung lässt sich auch über die Shell des Minion prüfen:

Um die Verbin­dung in OpenNMS zu sehen, kann man auf der Admi­nis­tra­ti­ons­seite im Bereich „Distri­buted Moni­to­ring“ den Punkt „Manage Minions“ wählen.

Wenn sich der Minion erfolg­reich mit OpenNMS verbinden konnte, sieht man einen entspre­chenden Eintrag. Dort wird auch die Loca­tion, die bei der Konfi­gu­ra­tion des Minion ange­geben wurde, angezeigt.

Betrachten man nun Provi­sio­ning Requi­si­tions, so ist dort eine Requi­si­tion namens „Minions“ hinzu­ge­kommen. Diese nimmt alle Minions auf und sorgt für die Über­wa­chung von deren Erreich­bar­keit, indem diesen der Service „Minion-Heart­beat“ zuge­ordnet wird.

Das Node­label, mit dem die Minions zuerst aufge­nommen werden, entspricht ihrer ID, die für die Kommunikation mit OpenNMS notwendig ist. Dieser Wert kann aller­dings ange­passt werden.

Anlegen eines Nodes

Nun folgt ein Beispiel für das Anlegen eines Nodes mittels einer Provi­sio­ning Requi­si­tion, der über ein Minion über­wacht wird. Hierbei ist zu erwähnen, dass die Zuord­nung zu den Minions über die Loca­tion statt­findet und nicht von den Requi­si­tions abhängt. Es ist also weiterhin möglich, alle Router in einer und alle Server in einer anderen Requi­si­tion zu verwalten, unab­hängig von ihrer Loca­tion. Das Anlegen und Verwalten einer Requi­si­tion erfolgt somit wie bisher auch - und auch das Anlegen des Nodes ist fast iden­tisch, aller­dings gilt es ein paar Dinge zu beachten.

Das Feld „Loca­tion“ ist in der Konfi­gu­ra­tion eines Nodes neu hinzu gekommen. Dieses Feld ist optional - wird dort nichts einge­tragen, wird die Über­wa­chung durch den OpenNMS–Server selbst vorge­nommen. Soll ein Minion die Über­wa­chung über­nehmen, trägt man hier die Loka­tion ein, die diesem zuge­ordnet ist. Der nächste Punkt, den es zu beachten gilt, ist die Angabe der Inter­faces bzw. der IP–Adressen. Hier muss man für die Über­wa­chung über einen Minion immer bedenken, dass dieser der Ausgangs­punkt der Über­wa­chung ist. Dies bedeutet zum einen, dass man von Nodes die internen Adressen angeben kann, zum anderen aller­dings auch, dass Frei­gaben für den Zugriff auf Nodes (beispiels­weise für SNMP) auf die Adresse des Minions einge­richtet werden müssen. Auch wenn die Konfi­gu­ra­tion der Minions zum Empfang oder zur Weiter­lei­tung von SNMP-Traps und Syslog-Nach­richten in diesem Beispiel nicht beschrieben ist, muss hier auch berück­sich­tigt werden, dass bei den Nodes der Minion als Empfänger einge­tragen wird, auch wenn die eigent­liche Verar­bei­tung von OpenNMS vorge­nommen wird. Das Konzept der Loka­tion zieht sich durch das gesamte OpenNMS: So kann unter anderem das Node Disco­very so einge­richtet werden, dass es neue Geräte an verschie­denen Loka­tionen auto­ma­tisch erkennt.

Fazit zu OpenNMS 19.0.1

Die Minions und das ange­passte Bedien­kon­zept sind bereits jetzt recht über­zeu­gend. So können auf recht einfache Weise neue Stand­orte in die Über­wa­chung einge­bunden werden, wobei auch Data­collec­tion möglich ist. Aller­dings hat die Inte­gra­tion der Minions größere Umstruk­tu­rie­rungen erfor­dert, so dass leider noch eine Reihe von Bugs vorhanden ist. Das Release 19.0.1 hat zwar bereits einige der Bugs behoben - aller­dings ist die Verän­de­rung recht tief­grei­fend, so dass mit dem Auftreten von weiteren Fehlern gerechnet werden muss. Der Autor rät daher von einem Upgrade einer produk­tiven Instal­la­tion auf die Version 19.0.1 zurzeit noch ab.
Wir sind erfah­rene Spezia­listen für OpenNMS - Ihre Fragen beant­worten wir daher gerne auch persön­lich. Spre­chen Sie uns einfach an!
 
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