Seite 3: Grundkonfiguration

Inhaltsverzeichnis

Grundlegendes zur Konfiguration

Die grundlegenden Bausteine der Nagios-Konfiguration sind Contacts, Hosts und Services. Contacts sind Personen, die Benachrichtigungen erhalten können, also meistens die Administratoren. Die zu überwachenden Systeme werden als Hosts konfiguriert, egal ob es sich um Server, Switches oder andere Geräte handelt, Hauptsache, sie haben eine IP-Adresse. Um einen Dienst (wie einen Webserver) oder einen Betriebsparameter (zum Beispiel die Systemauslastung) überwachen zu können, muss er als Service definiert werden. Das Format der Konfigurationsdateien heißt in Nagios-Lingo "Template-Based Object File".

Dabei ist es dem Nagios-Daemon relativ egal, in welchen Dateien diese Objekte konfiguriert sind. Zum Start benötigt er die Hauptkonfigurationsdatei nagios.cfg, in der die restlichen Konfigurationsdateien eingelesen werden. Das hat den Vorteil, dass man die Dateien aufteilen kann, wie es den eigenen Anforderungen entspricht. Ein gängiges Schema, das auch in den folgenden Beispielen verwendet wird, ist in dieser Tabelle dargestellt.

Kommentare in den Dateien leitet wie üblich ein "#" ein. Die Objekte der Konfiguration wie Contacts und Hosts können ihre Eigenschaften von Vorlagen erben. Dazu gehören auch Templates, unvollständig definierte Objekte, die man als Basis für die eigentlichen Konfigurationsobjekte benutzt. Dabei überschreiben in den abgeleiteten Objekten gesetzte Parameter die der Templates. Eine Definition wird mit der Direktive register 0 zum Template erklärt. Zusätzlich kann man von jedem registrierten Konfigurationsobjekt weitere Objekte ableiten. Eine gute Idee ist es, die Beispieldateien für spätere Betrachtung einmal komplett in Sicherheit zu kopieren. Beim anschließenden Bearbeiten sollten die Templates (erkennbar am register 0) erhalten bleiben und alle anderen Beispieldefinitionen angepasst oder auskommentiert werden.

First Contact

Nach der Installation befindet sich in dem Verzeichnis /usr/local/nagios/etc/ eine Handvoll Konfigurationsdateien. Für die folgenden Beispiele müssen die Dateien checkcommands.cfg-sample, misccommands.cfg-sample, resource.cfg-sample, cgi.cfg-sample und nagios.cfg-sample um das -sample erleichtert werden, so dass sie auf .cfg enden. Die Beispielkonfiguration bringt die beiden Dateien minimal.cfg-sample und bigger.cfg-sample mit, die eine sehr knappe und eine deutlich ausführlichere Konfiguration enthalten. Um die Konfigurations-Objekte auf einzelne Dateien zu verteilen, kann man die entsprechenden Teile aus den Beispielen als Vorlage in die neuen Dateien kopieren und anpassen.

Als ersten Schritt muss der Administrator mindestens einen Contact, Host und Service so eintragen, wie sie in seinem Netz tatsächlich existieren. Zunächst sollte er einen oder mehrere Kontakte in die neu anzulegende Datei contacts.cfg eintragen. Das sieht beispielsweise so aus:

define contact{   contact_name                  aadmin   alias                         Andi Admin   service_notification_period   workhours   host_notification_period      workhours   service_notification_options  w,u,c,r   host_notification_options     d,u,r   service_notification_commands notify-by-email   host_notification_commands    host-notify-by-email   email                         aadmin@example.com}

Den contact_name benutzt Nagios nur intern, er muss daher nicht mit einem User-Account übereinstimmen. Als alias trägt man sinnvollerweise den vollen Namen dieses Kontakts ein. Die service_notification_period und die host_notification_period legen fest, in welchen Zeiträumen Nagios Benachrichtigungen an diesen Kontakt verschickt.

Die Buchstaben w, u, c und r in den service_notification_options stehen für "Warning", "Unknown", "Critical" und "Recover" und legen fest, bei welchen Statusänderungen eines Service der Kontakt eine Nachricht erhält. Ein n (none) sorgt hier dafür, dass Nagios nie eine Nachricht schickt. Entsprechend legt der Parameter host_notification_options fest, ob der Kontakt von Statusänderungen eines Hosts erfährt. Möglich sind d(own), u(nreachable), r(ecovery) und n(one). So lässt sich beispielsweise festlegen, dass der Chef nur von kompletten Server-Ausfällen erfährt, während der Web-Admin über seinen Dienst auf dem Laufenden bleibt.

Die beiden _commands (vordefiniert in misccommands.cfg) legen fest, auf welchem Weg Nagios eine Nachricht an diesen Contact absetzt. Damit der Versand per E-Mail funktioniert, muss das lokale Mail-System eingerichtet sein, was sich relativ einfach mit dem YaST-Modul "Netzwerkdienste->Mail Transfer Agent" erledigen lässt.

In der Datei contactgroups.cfg werden die Kontakte zu Gruppen zusammengefasst; jede Gruppe erhält einen Namen und einen Alias. Als members werden die Kontakte aus der contacts.cfg mit ihrem contact_name eingetragen:

define contactgroup{   contactgroup_name  linux_admins   alias              Die Linux-Kenner   members            aadmin}

Ein Host, ein Host!

Jetzt wird die Datei hosts.cfg angelegt und der Nagios-Server als erstes zu überwachendes System konfiguriert. Am einfachsten kopiert man die beiden define host-Blöcke aus der Datei minimal.cfg-sample. Der erste Block ist das Template generic-host, das einige allgemein übliche Schalter setzt. Der zweite Block leitet dann mit einer use-Direktive einen konkreten Host ab. In die Parameter host_name, alias und address gehören ein Nagios-interner Kurzname, ein Langname sowie die Loopback-Adresse des Servers, in die contact_groups auf eine oder mehrere existierende Kontaktgruppen:

define host{   use generic-host   host_name      nagios   alias          Nagios-Server   address        127.0.0.1   check_command  check-host-alive   contact_groups linux_admins...

Alle Host-Definitionen enthalten übrigens eine Direktive check_command check-host-alive, die festlegt, wie der Status eines Hosts überprüft wird. Typischerweise geschieht dies mit einem Ping. Wie die Kontakte fasst man auch die Hosts in Gruppen zusammen, hier in der neuen Datei hostgroups.cfg. In members kommen die host_names der Mitglieder:

define hostgroup{   hostgroup_name linux-boxes   alias          Linux-Server   members        nagios}

Zum Schluss muss mindestens ein Service definiert werden. Als erster Check bietet sich der Test der Netzwerkverbindung an, was zwar auf demselben Host nicht sehr spannend, dafür aber leicht einzurichten ist. Analog zum Erstellen der hosts.cfg werden in die neue Datei services.cfg die ersten beiden define service-Blöcke aus minimal.cfg-sample kopiert. Damit erhält man ein Template und die Definiton eines Service "PING". Den host_name dieses Blocks ändert man auf den Namen des Nagios-Servers aus hosts.cfg. Um einen Check auf mehreren Hosts auszuführen, trägt man als host_name einfach mehrere durch Kommata getrennte Hostnamen ein, ein "*" sorgt dafür, dass Nagios alle definierten Hosts prüft. Außerdem gibt es den Parameter hostgroup_name, mit dem Host-Gruppen angegeben werden können. Die in contact_groups eingetragenen Kontaktgruppen erhalten Benachrichtigungen über den Status dieses Service, hier wird die in contactgroups.cfg definierte Kontaktgruppe eingetragen.

Um die grundlegende Konfiguration fertigzustellen, werden noch die Definitionen der Zeiträume für Checks und Benachrichtigungen benötigt. Am besten verwendet man hier die Beispiele aus bigger.cfg-sample und kopiert sie in eine neue Datei timeperiods.cfg. Die in der Abbildung rechts aufgeführten Dateien escalations.cfg und dependencies.cfg sind optional. In escalations.cfg kann man später Eskalationen definieren, durch die ab einer bestimmten Anzahl von Benachrichtigungen eine andere oder weitere Kontaktgruppen benachrichtigt werden. In dependencies.cfg werden Abhängigkeiten definiert.

Jetzt muss der Nagios-Daemon noch dazu gebracht werden, die neuen Konfigurationsdateien zu benutzen. Dazu wird in nagios.cfg der cfg_file= Eintrag für minimal.cfg gelöscht oder auskommentiert und die Kommentarzeichen vor den entsprechenden Einträgen für die benutzten Dateien entfernt. Ob man escalations.cfg und dependencies.cfg als leere Dateien anlegt oder die Zeilen in nagios.cfg auskommentiert lässt, ist dabei ganz egal.

Mit dem Befehl /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg prüft der gewissenhafte Admin nun die Konfiguration. Syntaktische oder inhaltliche Fehler werden dabei gnadenlos angekreidet. Wenn dann ein Things look okay – No serious problems were detected during the pre-flight check das OK gibt, ist der Moment gekommen, mit einem beherzten /etc/init.d/nagios start den Nagios-Server in Gang zu setzen. Das Startskript testet vorher zur Sicherheit auch mit nagios -v die Konfiguration. Jetzt ist der Nagios-Server ohne Murren gestartet und man sieht und hört … nichts. Solange keiner der Checks fehlschlägt und alle Hosts erreichbar sind, verhält sich Nagios vollkommen still. Um sich vom erfolgreichen Start zu überzeugen, kann man einen Blick in die Logdatei /usr/local/nagios/var/nagios.log werfen.