Nagios - Automatische Überwachung einer IT-Infrastruktur, Teil 3
Aufbau einer einfachen Konfiguration
Konfiguration
Bei der weiteren Konfiguration ist man weitgehend auf sich allein gestellt. Ein Konfigurationswerkzeug wird nicht mitgeliefert. Zwar gibt es Projekte, die eine mehr oder weniger komfortable Konfiguration (meist webbasiert) erlauben, aber das Nagios-Projekt selbst empfiehlt, sich erst einmal mit der textbasierten Konfiguration vertraut zu machen. Zunächst wird man sich daher einmal die Datei README.Debian in /usr/share/doc/nagios2 ansehen.
Minimalkonfiguration
Prinzipiell haben wir zwei Möglichkeiten: Wir ändern die vorhandene Konfiguration schrittweise ab, oder wir bauen eine ganz neue Konfiguration schrittweise auf. Letzteres ist für das Verständnis und die Klarheit der Konfiguration sinnvoller, daher räumen wir die vorhandene Konfiguration beiseite und legen ein neues Verzeichnis an:
cd /etc/nagios2 mv conf.d conf.d.old mkdir conf.d cd conf.d
Wo sollen wir beginnen? Ein kurzes Studium der Dokumentation zeigt uns, dass Nagios Dienste (Services) überwacht, die Hosts oder Hostgruppen zugeordnet sind. Hosts können in beliebig vielen Hostgruppen Mitglied sein. Services können zwar für jeden Host separat definiert werden, dabei wird es aber schnell dazu kommen, dass man immer wieder dieselbe Konfiguration hinschreibt, in der jeweils nur der Hostname anders ist. Wir beginnen daher mit der Konfiguration von Hostgruppen. Es gibt übrigens auch Servicegruppen, doch diese dienen nur zur Strukturierung der Anzeige und sind daher für uns zunächst ohne Belang.
Für unser Beispiel wollen wir vier Rechner verwenden: krakatau, stromboli, kilauea und rabaul. Krakatau ist hierbei der Server, der aber zugleich auch Client ist, denn er soll sich selbst in der gleichen Weise überwachen wie die anderen Rechner. Daneben wollen wir noch einen Default-Router namens gw überwachen (dies könnte z.B. der DSL-Router sein).
Die Einteilung dieser Hosts in Hostgruppen erfolgt am besten anhand der Gemeinsamkeiten und Unterschiede der Hosts. Krakatau und stromboli sind virtuelle Maschinen, während kilauea und rabaul reale Rechner sind. Da auf realen Rechnern reale Hardware wie Festplatten und Sensoren überwacht werden können, bietet es sich an, die Hostgruppen Virtual Hosts und Physical Hosts zu definieren. Alle vier Rechner sind Debian-Systeme, was es nahelegt, eine Gruppe Debian zu definieren, bei deren Mitgliedern man beispielsweise den Status der Paketverwaltung prüfen kann. Außerdem ist krakatau ein Webserver, was Anlass zu einer Gruppe HTTP Servers gibt.
Um die Konfiguration übersichtlich zu halten und einen möglichst einfachen Service definieren zu können, wollen wir uns zunächst auf die Hostgroup HTTP Servers beschränken und auch gleich den zugehörigen Service HTTP definieren. Beides schreiben wir in eine gemeinsame Datei. Da alle Dateien, die sich im Verzeichnis conf.d befinden, eingelesen werden, spielt es keine Rolle, wie wir sie nennen. Auch die Reihenfolge der Definitionen ist gleichgültig. Wichtig ist nur, dass wir einen sinnvollen Namen verwenden und in Zukunft auch konsistent bleiben. Naheliegend wäre hg-http-servers.cfg (mit hg für hostgroup). Das führt zu folgender Datei.
hg-http-servers.cfg
define hostgroup {
hostgroup_name HTTP Servers
alias HTTP-Server
}
define service {
hostgroup_name HTTP Servers
service_description HTTP
check_command check_http
use generic-service
}
Nun ist eine Erklärung der Syntax angebracht. Wie man sieht, besteht die Datei aus zwei Definitionen. Hostgroups beginnen mit define hostgroup, Services mit define service, und andere Objekte werden analog definiert, wie wir noch sehen werden. Die Definition ist in geschweifte Klammern eingeschlossen und enthält eine oder mehrere Zeilen, die jeweils aus Schlüsselwort und Wert bestehen.
Kommentare werden mit einem ; (Semikolon) eingeleitet und reichen bis zum Zeilenende. Am Anfang einer Zeile können Kommentare auch mit # begonnen werden. Leerzeichen in Namen (z.B. der Hostgruppe im Beispiel) sind erlaubt. Wenn ein Schlüsselwort mehrere Werte besitzt, werden sie durch Komma getrennt. Welche Schlüsselwörter in welcher Definition zulässig sind, ist in der Dokumentation zu finden, die nicht immer exakt ist.
In unserem Beispiel ist die Hostgroup-Definition absolut minimal. Normalerweise bräuchte man noch das Attribut members, in dem man die Hosts auflistet, die zur Gruppe gehören. Stattdessen kann man aber auch in jedem Host angeben, zu welchen Gruppen er gehört. Beide Methoden haben Vor- und Nachteile und können auch kombiniert verwenden, obwohl das wenig ratsam scheint. Wir haben uns hier für die Definition der Gruppenzugehörigkeit in den Hosts entschieden, wozu wir später noch kommen.
Die Definition des Service »HTTP« weist mehrere Besonderheiten auf. Zum einen ist in der Dokumentation nicht erwähnt, dass man anstelle eines host_name auch einen hostgroup_name angeben darf. Ohne diese Möglichkeit hätten Hostgroups allerdings wenig Sinn. Zum zweiten ist die service_description nichts anderes als der Name des Service, der in anderen Definitionen referenziert werden kann und auch in der Web-Oberfläche so erscheint. Zum dritten geben wir das auszuführende Kommando mit dem Attribut check_command an. Es besteht hier nur aus dem Kommandonamen. Später werden wir noch sehen, wie wir dem Kommando Argumente mitgeben können. Das Kommando muss hier nicht näher definiert werden, da es ein Plugin von Nagios ist. Voraussetzung ist natürlich, dass das Plugin installiert ist. Wenn Plugins im Verzeichnis /usr/lib/nagios/plugins installiert werden, dann können Sie mit /usr/lib/nagios/plugins/check_http --help ansehen, ob das Plugin vorhanden ist und was es macht. Und zum Vierten geben wir nicht alle Attribute an, die laut Dokumentation zwingend benötigt werden. Stattdessen verwenden wir das Attribut use, das auf eine Definition »generic-service« verweist. Diese gibt es noch nicht, und wir müssen sie noch definieren.
