Systemmonitoring mit OpenNMS

© © Rolf-Handke_pixelio.de

Unter den Augen des Wächters

Wer große Netzwerke monitoren will, braucht leistungsstarke Software. Eine noch nicht so sehr bekannte, aber vielversprechende Alternative dafür ist das freie OpenNMS.
Beinahe enzyklopädisch behandelt unser Schwerpunkt-Artikel über IPSEC verschlüsselte Verbindungen zwischen Linux, Windows, BSD, Solaris, Cisco- sowie ... (mehr)

Wie auch immer sich die Administratoren anstrengen mögen, irgendwann produzieren Netze, Server und Services unweigerlich Fehler. Diese Fehler sind teils offensichtlich (ein Lüfter fällt aus), teils subtil (eine DNS-Änderung verhindert den E-Mail-Versand). Würde man die eigentliche Ursache kennen (root cause), gestaltete sich die Fehlersuche einfach. Das aber ist häufig nicht der Fall. Noch schwieriger wird die Sache, wenn der Admin 1000, 10 000 oder 100 0000 Maschinen betreut.

In diesen Fällen kann OpenNMS [1] helfen. Es macht sich besonders bezahlt, wenn es um große und heterogene Netzwerke geht. Natürlich bewältigen auch die bekannten kommerziellen Produkte wie IBM Tivoli oder HP System Manager den Job, aber das ist keine freie Software und deshalb kann man dort auf Probleme stoßen, wenn man versucht, sie den eigenen Bedürfnissen anzupassen.

Installation

Auf den ersten Blick ist OpenNMS ein Monitoring-Tool wie Nagios, das, einmal aufgesetzt, eine sehr große Anzahl an Geräten überwacht (bis zu Hunderttausende Devices) und zum Beispiel via Handy Alarm schlägt, wenn irgendwo etwas ausfällt. Darüber hinaus fungiert OpenNMS gleichzeitig als Monitoring-Plattform, über der sich bei Bedarf einerseits spezielle eigene Applikationen errichten lassen – die andererseits aber auch schon eine gebrauchsfertig vorkonfigurierte Lösung darstellt, sodass man nicht bei null beginnen muss, wenn man nicht will.

Abbildung 1: Ein Netzwerk mit einer Reihe von Fehlermeldungen.

OpenNMS besteht aus verschiedenen Hauptkomponenten: einer Backend-Datenbank (PostgreSQL), einer javabasierten Engine für die Schwerstarbeit (Monitoring, Alarmierung) und einem in Java geschriebenen Web-Frontend für die Administration des Systems, das Betrachten von Berichten und so weiter. Bei der Installation hilft ein sehr ausführlicher Installation Guide [2] . Im Grunde geht es darum, zuerst PostgreSQL und Java zu installieren, danach OpenNMS und dann alles nach Wunsch zu konfigurieren, sodass es beim Booten automatisch startet.

Als Erstes sollte die passende Version ausgewählt werden. Vier stehen zur Auswahl: Stable, Unstable, Testing und Snapshot. Hinter Stable verbirgt sich natürlich das letzte stabile Release, Unstable ist die aktuellste Entwicklerversion. Testing ist ein nächtlicher Snapshot des nächsten Stable-Release und Snapshot ein Snapshot der kommenden Entwicklerversion (den man wählen sollte, wenn man das Allerneueste sucht).

Diese Versionen kann man aus verschiedenen Quellen beziehen. So ist der Sourcecode herunterladbar und lässt sich übersetzen, es gibt aber natürlich auch Pakete im RPM-, DPKG- oder Solaris Paketformat. Unter MacOS kann man OpenNMS via Fink installieren. Für Windows kann man das OpenNMS-Jar-File herauspicken. Für eine Linux-Distribution, die RPM verwendet, ist die einfachste Methode, das Stub-RPM herunterzuladen, das die Repository-Informationen enthält.

http://yum.opennms.org/repofiles/opennms-repo-snapshot-fc12.noarch.rpm

Der Dateiname für die stabile Version für Fedora 11 wäre dann »opennms-repo-stable-fc11.noarch.rpm« und so weiter. Nach diesem Schritt kann man OpenNMS einfach mit

yum install opennms

installieren. Nach Aussagen der OpenNMS-Entwickler soll ein normaler Server mit ausreichend RAM für die Java-Applikationen und die Datenbank in der Lage sein, auch Zehntausende Clients zu überwachen. Zwei Server, die sich bei einem Ausfall gegenseitig ersetzen können, sollten also in den allermeisten Fällen ausreichen.

Die Konfiguration

Im Anschluss an die Installation kann sich der Admin über das Webinterface an Port 8980 einloggen. Nach dem Ändern des Admin-Passworts wählt er den Menüpunkt »Admin | Configure Discovery« an, wo individuelle Services und URLs oder ganze Adressbereiche auswählbar sind, die danach gescannt und überwacht werden. Alternativ kann die Datei »discovery-configuration.xml« händisch editiert oder durch ein Skript generiert werden. Dabei lassen sich auch Adressbereiche ausklammern, um zu vermeiden, dass OpenNMS fremde Server überwacht.

Sind die Informationen im Webinterface zusammengestellt, startet »Save and Restart Discovery« einen Prozess, in dessen Verlauf OpenNMS jeden Host aus dem vorgegebenen Bereich nach üblichen Diensten (DNS, HTTP, Filesharing) absucht und die Fundstücke in einer Datenbank hinterlegt. OpenNMS unterstützt auch SNMP und fragt auf diesem Wege eine Fülle von Informationen bei Geräten ab. Bei einem SNMP-fähigen Gerät mit Leseberechtigung für die Öffentlichkeit wird OpenNMS dann übrigens den per SNMP hinterlegten Gerätenamen anstelle des DNS-Namens oder der IP-Adresse verwenden.

Ist auf die beschriebene Weise eine Geräteliste zusammengekommen, lassen sich die Devices kategorisieren. Wird das Gerät produktiv benutzt oder für Entwicklung oder Tests? Ist es ein Router, Switch oder Server? Der Admin kann auch eigene Kategorien anlegen (zum Beispiel "Datenbankserver") oder ein Gerät mehreren Kategorien zuordnen.

Alternativ kann man über »Admin | Category | Show« eine Kategorie auswählen und dann dort aus einer Liste verfügbarer Hosts wählen. Für jeden Host muss der Admin dann die Asset-Informationen ausfüllen, zu denen normalerweise Dinge wie die Seriennummer, das Betriebssystem, der Standort, Herstellerangaben, Authentifizierungsinformationen oder Kommentare gehören. Glücklicherweise muss man das nur einmal tun und kann diese Informationen später sichern und exportieren.

Ähnliche Artikel

comments powered by Disqus
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