Hosts

Das Herzstück einer Nagios-Installation bilden die zu überwachenden Hosts und Services. Für ein Web-Interface ist es nicht ganz einfach, alle möglichen Konfigurationsoptionen übersichtlich darzustellen. NagiosQL-Projektgründer Martin Willisegger entschied sich 2008, eine neue Oberfläche für NagiosQL zu verwenden und bediente sich hierfür bei der unter der BSD-Lizenz stehenden, freien Yahoo User Interface Library, kurz YUI [6] . Mit Hilfe des Javascript-Framework ist es Willisegger gelungen, alle denkbaren Nagios-Host-Einstellungen mit Hilfe von verschachtelten Menüs und Pop-Ups übersichtlich darzustellen.

Eine der Stärken der neuen NagiosQL-Version ist das Template-Handling, also der Umgang mit Kontakt-, Service- und Hostvorlagen. Das Beispiel des Artikels benutzt Hostvorlagen zur Kennzeichnung des Betriebssystems: »Überwachung | Hostvorlagen« . Erstellen Sie eine Vorlage »Debian« und setzen Sie unter »Zusatzeinstellungen« das »Icon Bild, VRML Bild« auf »debian.png« und das »Statusbild« auf »debian.gd2« . Fertige Bilder gibt es zum Beispiel bei NagiosExchange [7] , sie lassen sich aber auch leicht selber erzeugen. Für die Erstellung von PD2-Bildern bietet Thomas Boutells GD-Bibliothek [8] mit »pngtogd2« einen einfachen Konverter. Es ist zusätzlich möglich, über Vorlagen auch Administratoren bestimmter Betriebssysteme über die zuständigen Kontaktgruppen zuzuweisen.

Die soeben erstellte Vorlage fügen Sie nun unter »Zusätzliche Vorlagen« bei der ersten Hostdefinition unter »Überwachung | Hosts« ein. Wie bereits vom Web-Interface gewohnt, füllen Sie die benötigten Felder (rot markiert) pflichtgemäß aus. Der Hostname muss nicht unbedingt ein auflösbarer Name sein, sondern ist frei wählbar. NagiosQL speichert jede Hostkonfiguration anhand des Hostnamens, daher sollten keiner Sonderzeichen oder Umlaute vorkommen. Abbildung 4 zeigt die Möglichkeit, vorgeschaltete Hosts zu definieren, der Beispiel-Host hängt beispielsweise an einem Switch, der wiederum an einer Firewall. Nagios nennt das Parent Hosts und unterscheidet über Parent und Child zwischen den Zuständen »UNREACHABLE« und »DOWN« . Fällt ein Host aus, ist der Zustand des von diesem abhängigen Host unbekannt, da dieser für Nagios unerreichbar ist.

Abbildung 4: Verschachtelte Hosts bildet NagiosQL über ein Pop-Up ab, mehrere Hosts lassen sich über die bekannten Tastenkombinationen auswählen.

Als Prüfbefehl kommt der bereits erstellte »check_host_alive« zum Einsatz, die Parameter »$ARGn$« sind überflüssig. Einen Haken bei »Aktiv« und weiter zum nächsten Tab »Prüfeinstellungen« . Dort definiert »Max. Prüfversuche« die Anzahl der fehlgeschlagenen Checks, bis eine Benachrichtigung verschickt werden soll. Gerade bei Pings kann es in instabilen Netzwerksegmenten zu kurzzeitigen Unterbrechungen kommen, die aber nicht immer zu einer Mitteilung führen sollen. Daher bietet sich ein Wert zwischen 3 und 5 an.

»Aktive Prüfungen« setzen Sie auf »ein« , »Passive Prüfungen« benötigen Sie vorerst nicht, daher genügt »aus« . Über die »Prüfperiode« legen wir den Zeitraum fest in dem dieser Host überprüft werden soll, im Allgemeinen ist hier »24x7« die richtige Wahl. Der nächste Tab führt uns zu den »Alarmeinstellungen« . Obwohl sowohl »Kontakte« als auch »Kontaktgruppen« als Pflichtfelder gekennzeichnet sind, ist nur eine Definition zwingend notwendig. Die »Meldungsdauer« ist die Zeitspanne in der Nachrichten für diesen Host verschickt werden sollen. Sollte hier zum Beispiel »24x7« stehen, aber beim Kontakt nur innerhalb der normalen Arbeitszeit definiert sein, so hat letztendlich immer die Kontaktdefinition das letzte Wort. Die verschiedenen Meldungsoptionen (d,u,r,f,s) werden über das integrierte Hilfesystem erläutert ( Abbildung 5 ).

Abbildung 5: Das integrierte Hilfesystem bietet eine umfangreiche Hilfe zu einzelnen Optionen.

Das Meldungsintervall legt fest, wie hartnäckig Nagios im Fehlerfall Benachrichtigungen verschickt. Nagios schickt im Abstand der hier angegebenen Minutenzahl eine Nachricht über ein akutes Problem – wenn nicht die allgemeinen »time units« in der Nagios-Konfiguration verändert wurden. Setzt man diesen Wert auf 0, verhält sich Nagios zurück und verschickt nur eine Benachrichtigung, aber keine weiteren Erinnerungen. Zu guter Letzt müssen die Meldungen noch eingeschaltet werden und die erste Hostüberwachung ist abgeschlossen.

Services

Ein Service ist innerhalb Nagios nicht unbedingt wörtlich als Dienst des Betriebssystems zu verstehen, sondern bezeichnet einen beliebigen Messpunkt eines Hosts. Der Fantasie sind kaum Grenzen gesetzt, denn Nagios erwartet lediglich einen Rückgabewert (0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN) und eine Statusmeldung (String) zu einem Service. Für das Beispiel des Artikels muss noch einmal das bereits erstellte »check_ping« herhalten, mit dem Sie unter »Alarmierung | Services« einen neuen Eintrag anlegen.

Der Konfigurationsname eines Services dient neben der Übersicht und Filtermöglichkeit vor allem als physische Name der Nagios-Konfigurationsdatei, die NagiosQL erstellt. Die Auswahl eines »Hosts« oder einer »Hostgruppe« ist wie bei der Alarmierung der Hosts als ein Entweder-Oder-Pflichtfeld zu verstehen. Die »Servicebeschreibung« ist der Name des Dienstes, der im Nagios-Interface erscheint. Die Ping-Prüfung soll im Beispiel »Verfuegbarkeit« heißen und den Prüfbefehl »check_ping« erhalten.

Im Gegensatz zur Hostüberprüfung mit »check_host_alive« müssen Sie für den Servicecheck die Schwellwerte des Ping-Plugins anpassen: »$ARG1$« steht für einen »WARNING« , »$ARG2$« für »CRITICAL« Wert. Für das Ping-Plugin gibt es zwei Faktoren, die durchschnittliche Antwortzeit (Round Trip Average Travel Time) in Millisekunden und Packet Loss in Prozent. Ein Beispieleintrag ist: »$ARG1$« = 100.0,20%, »$ARG2$« = 500.0,60%. Vergessen Sie nicht, den Serviceeintrag zu aktivieren, bevor Sie unter den »Prüfeinstellungen« die weiteren Details der Serviceüberprüfung festlegen. »Max. Prüfversuche« und »Prüfperiode« kennen Sie bereits von der Host-Konfiguration. Das »Prüfintervall« ist die Zeit zwischen den einzelnen Überprüfungen und sollte je nach Dringlichkeit des Services unterschiedlich bewertet werden.

Es ist empfehlenswert, Servicevorlagen für Prioritäten zu erstellen. Für hohe Prioritäten wie zum Beispiel bei »check_ping« sollte die »Prüfperiode« nicht über fünf (Minuten) liegen. Das »Wiederholintervall« definiert die Zeitspanne für Überprüfungen während eines Problems, hier sollten die Testintervalle deutlich kürzer sein, um im Fehlerfall Verzögerungen bei der Benachrichtigung zu vermeiden. Die restlichen Einstellungen sind analog zu den Hosteinstellungen. Lediglich die »Meldungsoptionen« unter den »Alarmeinstellungen« weichen aufgrund der unterschiedlichen Status etwas ab, hier hilft das integrierte Hilfesystem bei der Feinjustierung.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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 /2022