Um einen Rechner mit meheren Diensten zu überwachen sind in Nagios folgende Schritte nötig: Anlegen des Rechners in der hosts.cfg, Definieren der zu überwachenden Dienste in der services.cfg. Sind die Dienste in der services.cfg noch nicht angelegt müssen die Überwachungskommandos in der Datei checkcommands.cfg definiert werden. Für eine Benachrichtigung per E-Mail oder anderen Mitteln sind die Dateien contacts.cfg und contactgroups.cfg zu pflegen. Ausführlich Informationen zu den Konfigurationsdateien finden sich auf der offiziellen Projektseite.
Nagios bietet die Möglichkeit vor dem Start die Konfiguration zu testen. Von dieser Funktion habe ich immer ausführlich Gebrauch gemacht. Die Pflege in einer großen Konfigurationsdatei bei älteren Nagios Versionen war schon unübersichtlich, die Aufteilung auf mehrere Dateien verbessert die Lage nicht unbedingt. Man überlegt oft wie man den Dienst oder das Checkkommando benannt hat. Nagios weigert sich auch bei kleinen Unstimmigkeiten in den Konfigurationsdateien zu starten. Wird ein Host entfernt müssen wiederum mindestens alle oben genannten Konfigurationsdateien nach Einträgen zu dem entsprechenden Host durchforstet und diese entfernt werden. Es lohnt sich oft die Konfiguration über die das Nagios-Portal anzusehen. Dort werden alle Konfigurationsparameer in Zusammenhang gebracht und dargestellt.

Hyperic HQ bietet die Konfiguration über ein Webinterface und über eine sogenannte Shell. Das Webinterface ist modern und mit zahlreichen AJAX-Elementen komfortabel gestaltet. Das Hinzufügen von Rechner und Diensten erfolgt automatisch wie im ersten Teil beschrieben.

Hyperic Shell

Der Agent entdeckt dabei die auf dem Rechner laufenden Diensten und versucht weitgehend automatisch eine automatische Konfiguration der Überwachung. Bei einigen Diensten muss noch manuell eingegriffen werden, z.B. müssen zur Überwachung von Datenbanken ein DB-Nutzer und ein Passwort eingetragen werden. Im Webinterface sind die Alerts einzurichten. Auf den ersten Blick ist die Einrichtung von Alerts in Hyperic HQ wesentlich aufwendiger und flexibler als in Nagios. In Hyperic HQ können viele verschiede ne Parameter darüber entscheiden, ob eine Benachrichtigung erfolgt (Verfügbarkeit, Metriken, Verzögerung der Benachrichtigung, Priorität etc.). Nagios erkennt Zustände nur als “warning”, “critical” oder “ok” und pro Dienst kann immer nur eine Metrik ausgewertet werden, die aussagen soll ob der Dienst in Schwierigkeiten ist. Ein Beispiel: Nagios kann mittels check_http übrprüfen ob ein Apache seine Webseiten ausliefert. Ein anderes Plugin kann messen wieviele Requestes pro Sekunde auf den Server kommen. Hyperic HQ kann feststellen wieviele Seiten pro Minute ausgeliefert werde oder wieviele Bytes pro Sekunde geliefert werden und dann bei einem entsprechenden Schwellwert Alarm schlagen. Fazit

Für ein Fazit ist es zu früh

Mit Hyperic gelingt es wesentlich schneller Rechner und Dienste zu überwachen als mit Nagios. Dies wird vor allem durch die “Auto Discovery” von Diensten erreicht. Die Konfiguration von Nagios ist fehleranfällig, komplex und wird schnell unübersichtlich. Auf viele spezielle Dinge von Nagios wie Gruppierung von Diensten und Rechnern, die grafische Darstellung der Topologie der Systeme usw. bin ich noch nicht eingegangen und das Webinterface von Hyperic hat sich mir auch noch nicht vollständig erschlossen

Fortsetzung folgt.

Beide System verfolgen den folgenden Ansatz: Auf den zu überwachenden Systemen sind kleine Hilfsprogramme genannt Plugins (bei Nagios) und ein bzw. ein Agent (Hyperic) installiert. Diese senden die Daten an einen zentralen Server. Dort werden die Daten gesammelt, ausgewertet und grafisch dargestellt. Bei Problemen erfolgt eine Benachrichtigung an die Verantwortlichen.

Runde 1: Installation des Servers

Bei Nagios ist Handarbeit angesagt, verwendet man nicht die Version die der Linux-Distribution beiliegt. Es muss der Apache mit CGI konfiguriert werden, die Nagios-Quellen müssen übersetzt und installiert werden und schliesslich Nagios an den Apache angebunden werden. Weiterhin sollten auf dem Nagios-Server die Plugins übersetzt werden.

Hyperic liegt als tar-Archiv vor und besteht wohl unter der Haube aus einem JRE, JBoss und einer Postgresql-Laufzeitumgebung. Die Installation von Hyperic läuft automatisch. Das Installtionsskript macht einen robusten Eindruck und verfügt auch über einen Upgrade-Modus, der auch funktioniert. Die Installation ist nach wenigen Minuten erledigt. Der Hyperic Server weigert sich unter dem User root zu laufen.

Runde 2: Installation der Plugins / Agents

Bei Nagios hat man entweder die Möglichkeit die mitgelieferten Plugins der Linux-Distribution zu verwenden oder sich die Plugins selbst zu kompilieren. Diese sind aber oft veraltet und so empfiehlt es sich die Plugins selbst zu erstellen. Aber auch das ist mit einigem Aufwand verbunden, da Compiler und viele Entwicklungsbibliotheken dafür benötigt werden. Ein weiterer Schitt besteht darin, den Dienst NRPE (Nagios Remote Plugin Executor) einzurichten. Dieser Dienst kommuniziert mit dem Nagios-Server und führt die Kommandos (Plugins) auf dem Client aus.

Für Hyperic ist ein Agent-Paket zu installieren (Größe ca. 47 MB). Nach dem Entpacken führt man ein Skript aus. Dies fragt nun einzelne Parameter ( IP-Adresse HQ Server, User-ID etc) ab, erstellt ein einzigartiges Token und verbindet sich mit dem Hyperic Server. In der Weboberfläche wird der neue Client dann angenommen und “inventarisiert”. Das alles passiert in wenigen Minuten. Dabei werden auch die wichtigsten Dienste auf dem Client erfasst. Einige Dienste erfordern das der Agent als “root”-Benutzer gestartet wird.

Fortsetzung folgt.