Netzwerkmonitoring mit OpenNMS
Wachstumsorientiert
Veröffentlicht in Ausgabe 10/2021 - PRAXIS
Administratoren sehen sich in der Praxis einer großen Bandbreite verfügbarer Monitoringumgebungen gegenüber. Während IT-Verantwortliche bei kommerziellen Lösungen davon ausgehen, dass diese alle notwendigen Funktionen bereitstellen, stehen quelloffene eher für den Einsatz bei speziellen Aufgaben. Der Platzhirsch beim Open-Source-Netzwerkmonitoring ist Nagios, doch ist auch dieses Werkzeug nicht immer die erste Wahl. Nagios ist tendenziell eher dort zuhause, wo es eine begrenzte Anzahl von Servern zu überwachen gilt, bei denen durchaus auch noch manuelle Eingriffe zu bewerkstelligen sind. OpenNMS [1] hingegen wendet sich primär an Unternehmen mit einer gewissen Größe, die ein skalierbares Monitoring benötigen.
Neben dem Einsatzbereich unterscheiden sich Nagios und OpenNMS in weiteren Punkten. So ist Nagios in C programmiert, OpenNMS hingegen in Java. Administratoren, die OpenNMS ausreizen wollen, benötigen somit solide Java-Kenntnisse. Nagios macht hingegen auf älterer Hardware eine bessere Figur, insbesondere gilt es als deutlich performanter. Unterschiede zeigen sich auch bei der Datensammlung. Hier agiert Nagios eher sparsam und beschränkt sich auf wenige Daten, während OpenNMS out-of-the-box über ein umfangreicheres Datenerfassungssystem verfügt. Administratoren, die Nagios entsprechend aufbohren wollen, müssen hierfür einen Spezialisten wie beispielsweise Kakteen einbinden. Ein weiterer zentraler Unterschied zeigt sich bei der Host- und Service-Erkennung: Nagios muss mitgeteilt werden, was überwacht werden soll, während OpenNMS über eine eigene Erkennungsfunktion verfügt.
OpenNMS im Überblick
OpenNMS erlaubt Ihnen, alle Komponenten in lokalen und entfernten Netzwerken zu visualisieren und zu überwachen. Es vereint umfassende Fehler-, Leistungs-, Verkehrsüberwachung und Alarmgenerierung. Dabei profitieren Sie grundsätzlich von der Skalierbarkeit sowie der einfachen Integration in Kerngeschäftsanwendungen und -workflows. Die Monitoringumgebung bündelt die OpenNMS-Kernplattform Minion (verteilte Fernüberwachung), Sentinel (Skalierbarkeit) und Newts (Zeitreihendatenbank) mit weiteren bekannten Open-Source-Werkzeugen, die die gewonnenen Informationen speichern und darstellen:
Administratoren sehen sich in der Praxis einer großen Bandbreite verfügbarer Monitoringumgebungen gegenüber. Während IT-Verantwortliche bei kommerziellen Lösungen davon ausgehen, dass diese alle notwendigen Funktionen bereitstellen, stehen quelloffene eher für den Einsatz bei speziellen Aufgaben. Der Platzhirsch beim Open-Source-Netzwerkmonitoring ist Nagios, doch ist auch dieses Werkzeug nicht immer die erste Wahl. Nagios ist tendenziell eher dort zuhause, wo es eine begrenzte Anzahl von Servern zu überwachen gilt, bei denen durchaus auch noch manuelle Eingriffe zu bewerkstelligen sind. OpenNMS [1] hingegen wendet sich primär an Unternehmen mit einer gewissen Größe, die ein skalierbares Monitoring benötigen.
Neben dem Einsatzbereich unterscheiden sich Nagios und OpenNMS in weiteren Punkten. So ist Nagios in C programmiert, OpenNMS hingegen in Java. Administratoren, die OpenNMS ausreizen wollen, benötigen somit solide Java-Kenntnisse. Nagios macht hingegen auf älterer Hardware eine bessere Figur, insbesondere gilt es als deutlich performanter. Unterschiede zeigen sich auch bei der Datensammlung. Hier agiert Nagios eher sparsam und beschränkt sich auf wenige Daten, während OpenNMS out-of-the-box über ein umfangreicheres Datenerfassungssystem verfügt. Administratoren, die Nagios entsprechend aufbohren wollen, müssen hierfür einen Spezialisten wie beispielsweise Kakteen einbinden. Ein weiterer zentraler Unterschied zeigt sich bei der Host- und Service-Erkennung: Nagios muss mitgeteilt werden, was überwacht werden soll, während OpenNMS über eine eigene Erkennungsfunktion verfügt.
OpenNMS im Überblick
OpenNMS erlaubt Ihnen, alle Komponenten in lokalen und entfernten Netzwerken zu visualisieren und zu überwachen. Es vereint umfassende Fehler-, Leistungs-, Verkehrsüberwachung und Alarmgenerierung. Dabei profitieren Sie grundsätzlich von der Skalierbarkeit sowie der einfachen Integration in Kerngeschäftsanwendungen und -workflows. Die Monitoringumgebung bündelt die OpenNMS-Kernplattform Minion (verteilte Fernüberwachung), Sentinel (Skalierbarkeit) und Newts (Zeitreihendatenbank) mit weiteren bekannten Open-Source-Werkzeugen, die die gewonnenen Informationen speichern und darstellen:
- Apache Kafka oder ActiveMQ als Nachrichtenbroker.
- PostgreSQL als Datenbank.
- Elasticsearch als Such- und Analysemaschine.
- Apache Cassandra zur Zeitreihendatenspeicherung.
- Grafana und Kibana für die Dashboard-Erstellung.
Die Kernaufgabe von OpenNMS besteht in der Sammlung von Daten zu den Netzwerkgeräten, Schnittstellen und Diensten. Es speichert die erfassten Metriken für einen längeren, definierbaren Zeitraum. Beim Erreichen beziehungsweise Unterschreiten von Grenzwerten gibt OpenNMS Alarme aus.
OpenNMS spielt seine Stärken insbesondere in verteilten Umgebungen aus, da es für die Überwachung von lokalen und Remote-Netzwerken taugt. Sie sind dabei nicht auf reine Datenerfassung beschränkt, sondern können auch Fehler beheben, Trends analysieren und etwaige Probleme bei der Kapazitätsverwaltung und Netzwerkoptimierung vorhersehen. Wie Nagios verfügt OpenNMS über eine modulare und ereignisgesteuerte Architektur. Entwicklung und Design von OpenNMS folgen dem von der ISO entwickelten FCAPS-Modell, das die Standardfunktionalitäten von Netzwerkmanagementanwendungen definiert und grundsätzlich die Abdeckung der folgenden Aufgabenbereiche vorsieht: Fehlermanagement, Konfigurationsmanagement, Rechnungsführung, Leistungs- und Sicherheitsmanagement. Die unterschiedlichen Aufgaben beim Netzwerkmanagement bewältigt OpenNMS über verschiedene Daemons.
Zwei Varianten verfügbar
OpenNMS wird seit geraumer Zeit in den Versionen Horizon und Meridian angeboten. Bei beiden handelt es sich um Open-Source-Varianten – sprich, beide basieren auf derselben Open-Source-
Codebasis mit jeweils einem eigenen Release-Zyklus und verfügbaren Support-Optionen. Für alle Unternehmen, die OpenNMS zunächst evaluieren wollen, ist Horizon die richtige Wahl, denn hier stehen der Machbarkeitsnachweis und das Testen der Überwachungsplattform im Fokus. Grundsätzlich stehen auch in Horizon nach einem schnellen Release-Zeitplan neue Funktionen zur Verfügung, allerdings werden etwaige Sicherheitspatches lediglich monatlich und alle Feature-Updates vierteljährlich vorgenommen. Der Support ist primär auf das Community-Forum und den Chat-Support begrenzt.
OpenNMS Meridian ist für IT-Verantwortliche interessant, die OpenNMS produktiv einsetzen wollen. Um in den Genuss von neuesten Sicherheitspatches und Feature-Updates zu gelangen, ist der Abschluss eines Abonnements notwendig. Dieses kommt mit professionellem Support für OpenNMS daher. Die Installation vereinfacht sich durch die Verfügbarkeit von RPMs für Red Hat Enterprise Linux und CentOS. Beide Varianten unterliegen der AGPLv3.
OpenNMS in Betrieb nehmen
Die Inbetriebnahme von OpenNMS gestaltet sich ein wenig umständlich, weil die Entwickler in der Open-Source-Variante keine RPM-Pakete und kein ISO-Image bereitstellen. Leider wurde auch die Online-Demo eingestellt, die die problemlose Evaluierung erlaubte. OpenNMS ist für den Betrieb auf einem RHEL- oder CentOS-System konzipiert (beide in Version 7 und 8). Grundsätzlich setzt OpenNMS die Verwendung eines PostgreSQL-Servers voraus. Neben dem Datenbankserver sind eine leere Datenbank, die die Monitoringumgebung als Speicher verwendet, und ein OpenNMS-User anzulegen. Weiterhin müssen Sie über die Host-Konfiguration sicherstellen, dass der Datenbankserver für OpenNMS verfügbar ist.
Anschließend können Sie sich der Installation und Konfiguration von OpenNMS widmen. Im ersten Schritt fügen Sie das Repository hinzu und importieren den GPG-Schlüssel:
sudo dnf -y install https://yum.opennms.org/repofiles/opennms-repo-stable-rhel8.noarch.rpm
sudo rpm --import https://yum. opennms.org/OPENNMS-GPG-KEY
Die Installation von OpenNMS inklusive aller Abhängigkeiten erledigen Sie per:
sudo dnf -y install opennms
Um die Trend- und Vorschaufunktionen zu verwenden, ist zusätzlich die Installation des R-Pakets notwendig:
sudo dnf -y install epel-release
sudo dnf -y install R-core
Nach der Installation sollten Sie den Zugriff auf das OpenNMS-Repository wieder deaktivieren, damit es während des Betriebs nicht zu unerwünschten Upgrades kommt:
sudo dnf config-manager --disable opennms-repo-stable-*
Verifizieren Sie als Nächstes die Verzeichnisstruktur mit Hilfe des "tree"-Befehls:
sudo dnf -y install tree
tree /opt/opennms -L 1
In einer korrekten Verzeichnisstruktur finden Sie unter "/opt/opennms" die Ordner "bin", "contrib", "data", "deploy", "etc", "jetty-webapps", "lib", "logs" (inklusive "/var/log/opennms"), "share" mit "/var/opennms" und schließlich "system".
Der nächste Schritt dient der Einrichtung der Umgebung. Dazu konfigurieren Sie zunächst den Zugriff auf die PostgreSQL-Datenbank:
sudo vi /opt/opennms/etc/opennms-datasources.xml
In der XML-Datei "opennms-datasources.xml" hinterlegen Sie die Zugangsdaten für die zuvor angelegte PostgreSQL-Datenbank, Listing 1 zeigt die Details. In der XML-basierten Zugangskonfiguration bestimmen Sie den Datenbanknamen, den Benutzernamen samt Passwort und den PostgreSQL-User mit administrativen Datenbankrechten.
Listing 1: Zugangsdaten für PostgreSQL-Datenbank in opennms-datasources.xml
<jdbc-data-source name="opennms"
database-name="opennms"
class-name="org.postgresql.Driver"
url="jdbc:postgresql://localhost:5432/opennms"
user-name="<OpenNMS-Benutzername>"
password="<OpenNMS-Passwort>" />
<jdbc-data-source name="opennms-admin"
database-name="template1"
class-name="org.postgresql.Driver"
url="jdbc:postgresql://localhost:5432/template1"
user-name="<PostgresSQL-Benutzername>"
password="<PostgreSQL-Passwort>" />
Als Nächstes ist das Zusammenspiel mit der Java-Umgebung "/opt/opennms/etc/java.conf" zu konfigurieren:
sudo /opt/opennms/bin/runjava -s
Initialisieren Sie die Datenbank und bestimmen Sie die Systembibliotheken in "/opt/opennms/etc/libraries.properties":
sudo /opt/opennms/bin/install -dis
Dass OpenNMS automatisch bei jedem Systemstart ausgeführt wird, stellen Sie mit folgendem Befehl sicher:
sudo systemctl enable --now opennms
Der nächste Schritt dient dazu, den Zugriff auf die Web-GUI zu ermöglichen. Außerdem is ein Neustart der Firewall erforderlich:
sudo firewall-cmd --permanent --add-port=8980/tcp
sudo systemctl
reload firewalld
Wollen Sie auch SNMP-Traps oder Syslog-Nachrichten empfangen, müssen Sie die Host-Firewall für den eingehenden Datenverkehr anpassen. Der SNMP-Trap-Daemon hört auf 162/UDP, der Syslog-Daemon auf 10514/UDP. Der SNMP-Trap-Daemon ist standardmäßig aktiviert, der OpenNMS-Syslog-Daemon ist deaktiviert.
Damit ist die OpenNMS-Umgebung eingerichtet und Sie greifen über die URL "http://<IP-Adresse-des-OpenNMS-Systems>:8980/opennms" auf das Webinterface zu. Der Standardbenutzer ist "admin", das Kennwort lautet ebenfalls "admin". Das Passwort sollten Sie nach dem ersten Login im Hauptnavigationsmenü mit "Admin / Change password" neu definieren.
Knoten definieren
Die nächsten Schritte dienen der Konfiguration der zu überwachenden Systeme. Um eine erste Serverkonfiguration für das Monitoring hinzuzufügen, führen Sie den Befehl "Admin / Add Node" aus. In dem zugehörigen Dialog geben Sie die relevanten Knoteninformationen wie die Bezeichnung, die IP-Adresse, den Community-String, den Gerätebenutzername und das Kennwort an. Nach dem Sichern dieser Einstellungen finden Sie diese in der Knotenverwaltung. Mit einem Klick auf die Schaltfläche "Label" präsentiert Ihnen OpenNMS den Knotenstatus, die Benachrichtigung und die registrierten Ereignisse.
Die Hauptkomponente des Service-Monitor-Framework trägt die Bezeichnung Pollerd. Sie prüft, ob ein Dienst oder ein Gerät verfügbar ist, und ermittelt dessen Latenz. Pollerd ist insbesondere für das Verfolgen des Status einer Management-ressource oder einer Anwendung für Verfügbarkeitsberechnungen zuständig. Der Dienst misst auch die Servicequalität und ermittelt Korrelationen von Knoten- und Schnittstellenausfällen basierend auf einem kritischen Dienst. Dazu greift Pollerd auf Daten zurück, die auf Service-Monitoren basieren. In der Praxis können Sie beispielsweise zwei Dienste mit der Bezeichnung "HTTP" und "HTTP-8080" definieren, die beide mit dem HTTP-Service-Monitor verknüpft sind, aber einen anderen TCP-Port-Konfigurationsparameter verwenden.
Die Verfügbarkeit berechnet sich über die letzten 24 Stunden und zeigt sich in den Überwachungsansichten, SLA-Kategorien und der Knotendetailseite. Die Antwortzeiten finden Sie als Ressourcendiagramme der IP-Schnittstelle auf der Knotendetailseite. Die Konfigurationsparameter des Service-Monitors sind auf der "Service"-Seite ersichtlich, indem Sie auf den Service-Name und dort auf "Node Detail Page" klicken. Die Service-Übersicht enthält auch Zeitstempel, die den letzten Zeitpunkt angeben, zu dem der Service abgefragt und als aktiv (Last Good) oder Down (Last Fail) befunden wurde. Mit diesen Feldern prüfen Sie, ob Pollerd die Dienste wie erwartet abfragt. Erkennt ein Service-Monitor einen Ausfall, sendet Pollerd ein Ereignis, das einen Alarm triggert. Sie können Ereignisse auch dazu verwenden, Benachrichtigungen an Administratoren zu generieren.
Über das Webinterface sind rudimentäre Anpassungen der Pollerd-Konfiguration möglich. Um die Potenziale des Services zu erschließen, sind Anpassungen der XML-basierten Konfiguration in "/etc/ poller-configuration.xml" notwendig. Grundsätzlich können Sie auch eigene Events in "/etc/events/opennms.events. xml" definieren.
Überwachung kritischer Dienste
Das Monitoring von IP-Netzwerken ist grundsätzlich ressourcenintensiv, insbesondere dann, wenn Sie eine große Dienstzahl im Blick behalten wollen. Ist ein Dienst offline oder nicht erreichbar, verbringt das Überwachungssystem die meiste Zeit damit, auf Wiederholungen und Zeitüberschreitungen zu warten.
Um die Effizienz des gesamten Systems zu steigern, betrachtet OpenNMS alle Dienste auf einer Schnittstelle als ausgefallen, wenn der kritische Dienst nicht reagiert. Standardmäßig ist ICMP ein solcher kritischer Dienst. Bei Abfragen kommen dazu die Statusinformationen "nodeLostService", "interfaceDown" und "nodeDown" zum Einsatz. Ein "nodeDown" ist für alle kritischen Dienste die Ausgabe, wenn alle Dienste auf einem Knoten ausfallen. OpenNMS verzichtet auf das Testen anderer Dienste auf weiteren IP-Interfaces. Daher registriert es auch keine Ereignisse, wenn diese Dienste nicht erreichbar sind.
Die Konfiguration der Funktion "Critical Service" erfolgt in der Pollerd-Konfigurationsdatei "poller-configuration.xml". Standardmäßig ist dieses Feature aktiviert, Sie können es aber anpassen. So lässt sich beispielsweise die Zahl der Threads oder das kritische Protokoll ändern, wie Listing 2 zeigt.
Listing 2: Pollerd-Konfiguration anpassen
<poller-configuration threads = "30"
pathOutageEnabled = "false"
serviceUnresponsiveEnabled = "false">
<node-outage = "on"
pollAllIfNoCriticalServiceDefined = "true">
<critical-service-name = "ICMP" />
</node-outage>
Mit der Option "pollAllIfNoCriticalServiceDefined" bestimmen Sie, wie OpenNMS bei Knoten ohne kritische Dienste verfährt. Setzen Sie diese Option auf "true", fragt OpenNMS alle Dienste ab, mit "false" untersucht es den ersten Dienst auf dem Netzwerknoten, bis der Dienst wiederhergestellt ist. Erst dann wird die Abfrage der weiteren Dienste fortgesetzt.
Performancemanagement
OpenNMS sammelt standardmäßig Leistungsdaten mit dem Collectd-Daemon. Dabei ist Collectd für die Datensammlung auf Entitäten (Knoten, Schnittstellen et cetera) unter Verwendung von Managementagenten und protokollspezifischen Kollektoren wie SNMP, HTTPS, JM und JDBC zur Ermittlung von Leistungsmetriken zuständig. Jeder Kollektor besitzt eine eigene Konfiguration.
Die Monitoringumgebung verwendet standardmäßig SNMP und OpenNMS-JVM zur Eigenüberwachung. Damit die Datenerfassung funktioniert, ist eine korrekte Konfiguration des SNMP-Community-String notwendig, dessen Standardwert "public" lautet. Um einen anderen Community-String zu verwenden, passen Sie ihn über das Webinterface an. Führen Sie dazu den Befehl "Admin / Configure OpenNMS" aus und wählen im Abschnitt "Provisioning" die Option "Configure SNMP Community Names by IP Address". Unter "v1/v2c specific parameters" nehmen Sie die Änderung vor.
Zur Erfassung von Leistungsdaten über die Protokolle HTTPS, JMX und JDBC sind Anpassungen der Collectd-Konfiguration notwendig. Diese finden Sie im Verzeichnis "/etc/collectd-configuration.xml". Die einfachste Konfiguration sieht wie folgt aus:
<collectd-configuration threads="50">
Um weitere Werkzeuge für das Sammeln von Daten zu verwenden, müssen Sie die XML-basierte Konfiguration entsprechend erweitern. Hier ein Beispiel für die Integration von Cassandra:
<package name="cassandra-via-jmx" remote="false">
<filter>IPADDR != '0.0.0.0'
</filter>
Geschäftsprozesse im Blick
OpenNMS beschränkt sich nicht nur auf die Überwachung von relevanter Hard- und Software, sondern spielt seine Stärken beim Monitoring von Geschäftsprozessen aus. Das sogenannte Business Service Monitoring (BSM) geht noch einen Schritt weiter: Die BSM-Komponenten ermöglichen Ihnen die Überwachung und Modellierung von High-Level-Business-Services. Diese Funktionen sind dazu gedacht, kritische Probleme schnell zu identifizieren.
Damit können Sie unternehmenskritische CRM- und ERP-Systeme genauso überwachen wie einen eigenen Online-Shop. Hinter solchen Systemen stecken immer Datenbanksysteme. Daher genügt es, den Status der Datenbanken zu überwachen. Konkret wird auf jedem Datenbankserver ein SQL-Dienstmonitor konfiguriert. Um die Gesamtfunktionalität abzudecken, kommt ein Page Sequence Monitor (PSM) zum Einsatz, der die Workflows im Blick behält.
Die BSM-Funktionen decken verschiedene Aufgaben ab: Der Business-Service-Monitoring-Daemon steuert den Zustand aller Geschäftsprozesse, der Business-Service-Editor dient dem Erstellen, Aktualisieren oder Löschen von Prozessen und die Topologie-Ansicht stellt die Business-Service-Hierarchie visuell dar. Außerdem steht eine ReST-basierte API zum Erstellen, Lesen, Aktualisieren oder Löschen von Geschäftsprozessen zur Verfügung.
Ein Highlight der BSM-Funktionen stellt die Simulationsfunktion dar. Auf Grundlage der Netzwerktopologie und eingeschränkter Funktionalität ist eine genaue Validierung der genutzten Business-Service-Hierarchien möglich. Die Simulation ist in der Business-Service-Ansicht der Topologie-Benutzeroberfläche verfügbar. Dort aktivieren Sie im Menü "Simulate" die Option "Simulation Mode". Mit dem Auswahlmenü "Severity" bestimmen Sie den Schweregrad der Beeinträchtigung innerhalb der Simulation.
Fazit
Administratoren haben beim Netzwerkmonitoring oftmals die Qual der Wahl. Doch die Open-Source-Gemeinde hält für nahezu jede Anforderung das geeignete Werkzeug parat. Mit OpenNMS steht Ihnen ein vorzüglicher Spezialist zur Verfügung, der nicht zuletzt wegen seiner modernisierten Web-GUI alles bietet, was größere IT-Infrastrukturen erfordern. Dabei profitieren Sie insbesondere von der hohen Skalierbarkeit und Flexibilität bei der Überwachung der IT.
(jp)
Link-Codes
[1] OpenNMS: https://sourceforge.net/projects/opennms/