33.2 Netzwerkmonitoring mit Nagios

Nagios (www.nagios.org) erfüllt als Nachfolger des populären NetSaint alle Anforderungen, die wir im letzten Abschnitt an ein Netzwerkmonitoringtool gestellt haben:

• Überwachen von Rechnern und Diensten
  Man kann diverse Dienste (z. B. HTTP, SMTP, POP3, FTP, ...) sowie auch ganze Rechner (über ICMP) überwachen. Außerdem kann man auch Ressourcen wie Festplattenplatz, CPU-Auslastung oder den Speicherverbrauch kontrollieren.
• Flexibles Benachrichtigungssystem
  Natürlich kann man auch konfigurieren, wer wie kontaktiert werden soll, wenn Probleme auftreten. Dazu gehört neben der obligatorischen E-Mail-Benachrichtigung auch der Support von SMS-Nachrichten oder von anderen benutzerdefinierten Möglichkeiten.

Die verschiedenen Benutzer des Systems kann man außerdem in unterschiedlichen Kontaktgruppen organisieren, auf die man die unterschiedlichen Problemfälle verteilen kann.

• Pluginsystem und proaktive Problemlösung
  Über ein einfaches Pluginsystem kann man selbst Servicechecks schreiben, die dann von Nagios regelmäßig ausgeführt beziehungsweise überprüft werden.

Außerdem kann man mittels Event-Handlern auch einfache Maßnahmen zur proaktiven Problemlösung definieren.

• Webinterface
  Neben den erwähnten Möglichkeiten der E-Mail-Benachrichtigung kann man den Status der überwachten Systeme auch über ein Webinterface betrachten.

Open Source!

Gehen wir also näher auf die Software ein. Nagios steht unter der GNU General Public License und ist damit als freie Software für jeden verfügbar. Als Voraussetzungen für die Installation genügen bereits ein einfacher Linux-Rechner mit Webserver (am besten Apache) sowie die GD-Bibliothek, die aber auch bei jeder Distribution mit dabei sein sollte. Nachdem es installiert – und vor allem konfiguriert – worden ist, kann man sich mit Nagios nicht nur über aufgetretene Probleme informieren lassen, sondern sich auch schöne Statistiken ansehen.

Abbildung 33.1 Netzwerkmonitoring mit Nagios

Nur haben die Götter vor die Grafik leider die Konfiguration gesetzt, die bei einem Netzwerk-Monitoringsystem natürlich nicht von selbst erfolgen kann. Aus diesem Grund wollen wir uns an dieser Stelle etwas näher mit dieser Thematik auseinandersetzen, da die Maßnahmen, die sich aus den Meldungen ergeben, wieder vollkommen in den Aufgabenbereich eines Systemadministrators fallen.

Da die Konfiguration also naturgemäß recht komplex werden kann, verweisen wir für Detailfragen wieder einmal auf die Webseite des Projektes, www.nagios.org, und auf die dort verlinkte ausführliche Dokumentation.

33.2.1 Installation

Beginnen wir also mit der Installation. Am besten laden Sie sich die aktuellste Version von der Webseite herunter und entpacken die Dateien in einem Verzeichnis Ihrer Wahl. Anschließend sollten Sie einen eigenen Benutzer samt Gruppe für die Software und das spätere Installationsverzeichnis – am besten /usr/local/nagios – anlegen.

Listing 33.14 Die eigentliche Installation vorbereiten

# tar -xzf nagios-1.1.tar.gz
# mkdir /usr/local/nagios
# adduser nagios

Quelltext konfigurieren

Als Nächstes kann man in dem entpackten Verzeichnis das configure-Skript aufrufen, bei dem

man einige Parameter nicht vergessen sollte:

Listing 33.15 Die Software vor dem Übersetzen an das eigene System anpassen

../configure --prefix=prefix --with-cgiurl=cgiurl    \
  --with-htmurl=htmurl --with-nagios-user=user       \
  --with-nagios-grp=group

• Mit »prefix« gibt man das Installationsverzeichnis an; normalerweise ist dies /usr/local/nagios.
• Mit »cgiurl« wird die URL angeben, unter der man später die CGI-Skripte ansprechen will, normalerweise /nagios/cgi-bin [Fn. Achtung: Am Ende der URL darf kein Slash stehen!].
• Analog gibt die »htmlurl« die URL der späteren HTML-Seiten an, normalerweise /nagios/.
• Schließlich sollte man den eben angelegten Benutzer samt dessen Gruppe (standardmäßig ist beides »nagios«) angeben.

Quelltext übersetzen

Als Nächstes kann man die Software übersetzen und die entsprechenden Dateien an ihren zukünftigen Platz im Dateisystem verschieben. Falls gewünscht, kann man sich auch ein Initskript erstellen lassen:

Listing 33.16 Übersetzen, installieren und Initskript erstellen

# make
# make install
# make install-init

Möchte man auch noch einen Satz von Standard-Konfigurationsdateien installieren, die man dann später nur noch anpassen muss, reicht es aus, make erneut zu bemühen:

Listing 33.17 Beispielkonfiguration installieren

# make config
# make install-config

Verzeichnisstruktur

Wechselt man nun mit cd /usr/local/nagios in das Installationsverzeichnis von Nagios, kann man sich dort die Verzeichnisstruktur der Software näher ansehen:

Installieren der Plugins

Wie bereits aus der Tabelle zur Verzeichnisstruktur ersichtlich ist, müssen als Nächstes die Plugins separat heruntergeladen und ins Verzeichnis libexec/ installiert werden.

Plugins für Servicechecks

Diese Plugins sind dabei entweder Skripte oder zu kompilierende Binarys, die die Service- und Hostchecks erst durchführen. Natürlich können Sie so, wenn Sie sich bereits fertige Skripte oder Codes als Vorbild nehmen, auch eigene Plugins für Nagios schreiben.

Das Webinterface

Nachdem wir die Software übersetzt und die Plugins installiert haben, ist als Nächstes das Webinterface an der Reihe. Es muss dem Webserver – in unserem Beispiel wollen wir auf den viel genutzten Apache eingehen – »gesagt« werden, wo die CGI-Skripte und die HTML-Dateien zu finden sind. Immerhin haben wir diese ja nicht in die DocumentRoot, also das »Stammverzeichnis des Webservers« installiert.

Webserver vorbereiten

Beginnen wir dazu mit dem Alias für die CGI-Skripte. Die folgenden Zeilen bewirken, dass wir die URL /nagios/cgi-bin ansprechen können, wobei in Wirklichkeit auf die Skripte in /usr/local/nagios/sbin zugegriffen wird. Dieses Verzeichnis wird beim Kompilieren durch den Parameter --cgiurl angegeben:

Listing 33.18 Den Alias für die CGI-Skripte setzen

ScriptAlias /nagios/cgi-bin/ /usr/local/nagios/sbin/
<Directory "/usr/local/nagios/sbin/»
    AllowOverride AuthConfig
    Options ExecCGI
    Order allow,deny
    Allow from all
</Directory>

Als Nächstes müssen wir noch die --htmlurl /nagios auf das Verzeichnis share/ unserer Installation umleiten:

Listing 33.19 Den Alias für die Nagios-HTML-Dateien setzen

Alias /nagios/ /usr/local/nagios/share/
<Directory "/usr/local/nagios/share»
    Options None
    AllowOverride AuthConfig
    Order allow,deny
    Allow from all
</Directory>

Nun kann man Apache mit dem Befehl

Listing 33.20 Apache neu starten

# apachectl restart

neu starten und bereits versuchen, das Webinterface über http://localhost/nagios/ anzusprechen. Natürlich werden noch keine Informationen angezeigt, da das Monitoring erst noch konfiguriert werden muss; das Webinterface kann man aber schon betrachten.

Passwortschutz

Meistens ist es ganz sinnvoll, den Zugriff auf die Nagios-Software per htaccess zu beschränken. Um diesen Schutz zu konfigurieren, muss man zuerst im share/- und sbin/-Verzeichnis der Nagios-Installation eine .htaccess-Datei mit folgendem Inhalt anlegen:

Listing 33.21 Die .htaccess-Datei

AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
require valid-user

Mit dem Kommando htpasswd kann man nun die Datei /usr/local/nagios/etc/htpasswd.users mit dem -c-Switch anlegen und mit Benutzernamen und Passwörtern füllen:

Listing 33.22 Den User »nagiosadmin« hinzufügen

htpasswd -c /usr/local/nagios/etc/htpasswd.users     \
  nagiosadmin

Möchte man weitere Nutzer hinzufügen, so entfällt die Option -c, und man gibt als einziges Argument den anzulegenden Benutzernamen an.

33.2.2 Konfiguration

Nach der Installation läuft Nagios zwar bereits, aber ein Monitoring findet noch nicht statt. Dazu muss das System erst korrekt konfiguriert werden, was in diesem Abschnitt besprochen werden soll. Am besten beginnen wir dazu mit einem Überblick über die wichtigsten der zahlreichen Konfigurationsdateien:

Hauptkonfiguration

• etc/nagios.cfg
  In der Hauptkonfigurationsdatei kann man alle möglichen Einstellungen für Nagios vornehmen, wie beispielsweise, wo die restlichen Konfigurationsdateien zu finden sind, welche Logfiles angelegt werden sollen oder wie sich das Monitoring bezüglich der einzelnen Checks genau verhalten soll.
• etc/cgi.cfg
  In dieser Konfigurationsdatei kann man zahlreiche Einstellungen für die CGIs treffen, so zum Beispiel, welche Nagios-Benutzer auf welche Funktionen Zugriff erhalten, falls eine Authentifizierung verwendet wird.
• Resource Files
  Neben den beiden Hauptkonfigurationsdateien gibt es weitere Dateien, die man dann über etc/nagios.cfg einbinden kann. Ein Typ dieser zusätzlichen Konfigurationseinstellungen sind die Resource Files (meist nur etc/resource.cfg), in denen man sensible Informationen wie Logins für eine Datenbank oder auch Makros speichern kann. Aus Sicherheitsgründen sind diese Informationen den CGIs nicht zugänglich.

Objekte definieren

• Object Configuration Files
  Diese Dateien bindet man ebenfalls über die nagios.cfg ein, und hier endlich definiert man das eigentliche Monitoring. Für Nagios ist es egal, ob Sie einen Service (Dienst) oder einen zu überwachenden Rechner definieren, allerdings teilt man die recht umfangreichen Optionen meist auf mehrere Dateien auf:
• etc/hosts.cfg
  Hier definiert man die zu überwachenden Rechner samt Namen und IP-Adressen. Dazu benötigt man die weiter unten erklärten host-Objekte.
• etc/services.cfg
  Hier kann man die zu überwachenden Dienste definieren, die zwei wichtige Eigenschaften besitzen: den Rechner(n), auf dem sie laufen, sowie den Befehl beziehungsweise das Plugin, das für den Check verwendet werden soll.
• etc/commands.cfg
  Die bei den Servicedefinitionen benötigten Dienste kann man auch als Objekte anlegen, was einem die Angabe der genauen Syntax bei jedem einzelnen zu konfigurierenden Dienst ersparen kann.
• etc/contacts.cfg
  Hier kann man einzelne Benutzer samt E-Mail-Adresse oder anderer Benachrichtigungsmethoden eintragen sowie angeben, bei welchen Dringlichkeitsstufen verschiedener Events sie kontaktiert werden sollen.
• etc/*groups.cfg
  Ob Rechner oder Kontakte: Beides kann und sollte man auch zu Gruppen zusammenfassen, um die Administration komplexer Netzwerke zu vereinfachen. Diese Gliederung ist vor allem für das Benachrichtigungssystem sinnvoll.
• Weitere Objekttypen
  Es gibt noch viele weitere Objekttypen, die gerade für komplexe bis sehr komplexe Netzwerke interessant werden können. Für eine Dokumentation zu diesen Features seien Sie erneut auf die Webseite verwiesen, da weitere Details den Rahmen des Buches sprengen würden.

Denken Sie allerdings daran, dass die eben vorgestellten Dateien nicht unbedingt genau so auf Ihrem Nagios-Server vorhanden sein müssen – schließlich können Sie in der nagios.cfg flexibel einstellen, woher Ihre Objektdefinitionen kommen sollen.

Im Folgenden wollen wir weniger die Konfiguration von Nagios selbst (über die nagios.cfg beziehungsweise die cgi.cfg) erläutern, da diese standardmäßig recht sinnvoll und im Allgemeinen weniger interessant ist, sondern stattdessen lieber auf die umfangreichen Objektdefinitionen eingehen, die das Monitoring Ihres Netzwerks erst ermöglichen. Aus diesem Grund seien Sie erneut auf die Webseite des Projekts samt zugehöriger Dokumentation verwiesen, falls Fragen zur Konfiguration offen bleiben sollten.

Hostobjekte

Rechner definieren

Prinzipiell kann man in jeder Object-Configuration-Datei host-Objekte definieren, meist wird dazu jedoch die etc/hosts.cfg genutzt. Möchte man nun einen neuen Rechner zur Überwachung hinzufügen, kann man dort eine entsprechende Definition ablegen:

Listing 33.23 Ein Host-Objekt

define host{
  host_name                     Rechnername
  alias                         Alias
  address                       IP
  (parents                      Rechnernamen)
  (check_command                Kommando)
  max_check_attempts            #
  notification_interval         #
  notification_period           timeperiod
  notification_options          [d,u,r]
}

Man gibt dem Objekt mit dem Rechnernamen zuerst einen eindeutigen Bezeichner, auf den man sich dann in der weiteren Konfiguration von Nagios auch beziehen kann. Das Alias dagegen wird verwendet, um den Rechnernamen über das Webinterface anzuzeigen.

Es folgt natürlich die obligatorische IP-Adresse. Wenn sich irgendwelche anderen Systeme wie zum Beispiel Router zwischen dem Host und dem Monitoringsystem befinden, werden diese im optionalen Parameter parent angegeben.

Ist ein Rechner an?

Das check-Kommando ist recht wichtig, um zu überprüfen, ob der Host noch »up« ist. Meist gibt man hier das standardmäßig in der commands.cfg definierte Kommando check-host-alive an, das schlicht einen Ping auf den Rechner versucht. Lässt man diesen Parameter weg, wird das System nicht überprüft und immer als »up« angenommen.

Als Nächstes muss man angeben, wie oft im Fehlerfall überprüft werden soll, bevor eine Nachricht abgeschickt beziehungsweise der Rechner als »down« deklariert wird. In so einem Fall werden entsprechende Kontakte alle notification_interval Minuten wieder informiert.

Eine timeperiod ist auch ein Objekt, über das man definieren kann, in welchem Zeitraum ein Rechner oder ein Dienst überwacht werden soll. Meist gibt man hier den in der etc/timeperiods.cfg definierten Zeitraum 24x7 an, der den Rechner ohne Unterbrechung kontrolliert.

Zum Schluss kann man noch einstellen, wann ein Admin benachrichtigt werden soll: wenn der Rechner »down« (d) geht, wenn er »unreachable« (u) ist, also ein Parent »down« geht und der Rechner nicht mehr zu erreichen ist, und/oder wenn er wieder »up« (r, engl. recover) ist.

Es gibt noch eine ganze Reihe weiterer möglicher Optionen, die wir aber nicht näher betrachten wollen.

Hostgruppen

Verknüpfung mit Kontakten

Was in der Definition zu einzelnen Rechnern noch fehlte, war natürlich die Verknüpfung mit entsprechenden Kontaktpersonen, die im Problemfall informiert werden sollen. Dazu fasst man nämlich mehrere Rechner zu einer »Gruppe« zusammen, indem man wieder einen Objektnamen samt Alias vergibt und der Gruppe eine Kontaktgruppe sowie natürlich ein bis mehrere durch Komma getrennte Mitglieder zuordnet. Die Mitglieder sind dabei ihrerseits wieder Hostobjekte.

Listing 33.24 Hostgruppen

define hostgroup{
  hostgroup_name                Gruppenname
  alias                         Alias
  contact_groups                Kontaktgruppen
  members                       Mitglieder
}

Durch diese auf den ersten Blick komplexe Struktur kann man sehr sinnvolle und realitätsnahe Konfigurationen für das Monitoring schaffen. Und dies ist schließlich das Ziel, das wir mit der Software verfolgen.

[zB]Um letzte Fragen zu klären, wollen wir uns aber einmal ein kurzes Beispiel eines Hostobjekts sowie einer dazugehörigen Hostgruppe ansehen:

Listing 33.25 Host samt Hostgruppe

define host{
  host_name                     fileserver
  alias                         Data Store
  address                       192.168.1.1
  check_command                 check-host-alive
  max_check_attempts            5
  notification_interval         30
  notification_period           24x7
  notification_options          d,u,r
}
define hostgroup{
  hostgroup_name                servers
  alias                         Serverraum #1
  contact_groups                linux-admins
  members                       fileserver,mailserver
}

Diese Konfiguration sollte mit den Erläuterungen der Objekttypen eigentlich selbsterklärend sein. Das einzige, was Sie nicht verwundern sollte, ist die hier nicht weiter definierte Kontaktgruppe linux-admins. Da wir auf Kontaktgruppen erst später eingehen, haben wir diese Definition hier nämlich noch offengelassen.

Serviceobjekte

Serverdienste definieren

Bereits angesprochen wurden auch die Serviceobjekte. Das Wort »Service« bezeichnet dabei nicht nur klassische Dienste wie HTTP, FTP oder POP3, sondern auch jede andere »messbare« Eigenschaft eines Rechners.

So kann man über Serviceobjekte auch den Plattenplatz, die Anzahl momentan eingeloggter Benutzer, die Prozessorauslastung oder was auch immer überprüfen. Allerdings sollte man immer darauf achten, nicht zu viele Informationen zu sammeln, damit das Wichtige nicht untergeht.

Listing 33.26 Serviceobjekte in der etc/services.cfg

define service{
  host_name                     Rechnername
  service_description           Beschreibung
  check_command                 Kommando
  max_check_attempts             #
  normal_check_interval          #
  retry_check_interval           #
  check_period                  timeperiod
  notification_interval         #
  notification_period           timeperiod
  notification_options          [w,u,c,r]
  contact_groups                Kontaktgruppen
}

Der Rechnername bezieht sich auf ein host-Objekt, auf dem dieser Dienst läuft beziehungsweise dessen Zustand überwacht werden soll. Ansonsten ist vor allem wieder das Kommando wichtig, bei dem oft auf eines der mitgelieferten Plugins zurückgegriffen wird.

Ähnlich wie die bereits erläuterten notification-Optionen verhalten sich auch die check-Optionen. So kann man über check_period kontrollieren, wann das Monitoring stattfinden soll (z. B. 24x7), oder mittels interval festlegen, wie regelmäßig die Überprüfungen wiederholt werden sollen.

Wann informieren?

Zu den notification_options ist noch eine weitere Option – (w) für Warnungen – hinzugekommen. Schließlich gibt es für Dienste drei Zustände: »ok«, »warning« und »critical«, während es mit »up« und »down« für Rechner an sich nur zwei messbare Zustände gibt.

Über die Option contact_groups kann man wie bei den Hostgruppen eine oder mehrere Kontaktgruppen angeben, die im Problemfall benachrichtigt werden.

Kontakte und Kontaktgruppen

Verantwortliche angeben

Daher wollen wir als Nöchstes auch schon dieses Feature behandeln. Zu einem Kontakt gehört wie immer bei Nagios der Objektname, der »richtige« Name als Alias sowie natürlich neben den bereits bekannten Benachrichtigungsoptionen eine – optionale – E-Mail-Adresse.

Listing 33.27 Kontakte in der etc/contacts.cfg

define contact{
  contact_name                  Kontakt
  alias                         Alias
  host_notification_period      timeperiod
  service_notification_period   timeperiod
  host_notification_options     [d,u,r,n]
  service_notification_options  [w,u,c,r,n]
  service_notification_commands notify-by-email
  host_notification_commands    host-notify-by-email
  (email                        E-Mail)
}

Natürlich gibt es auch für Kontakte noch weit mehr als die hier aufgeführten Optionen und damit mehr Möglichkeiten, wie eine Benachrichtigung erfolgen kann. Somit ist die E-Mail-Adresse als eine Kontaktoption unter vielen auch nicht zwingend für dieses Objekt erforderlich.

Um einen Kontakt nun aber mit einem Hostgruppen- oder Serviceobjekt verknüpfen zu können, benötigt man eine Kontaktgruppe. Auch wenn in einer solchen Gruppe nur ein einziger Kontakt steht, ist sie notwendig, damit man den Kontakt in Nagios nutzen kann:

Listing 33.28 Kontaktgruppe in der etc/contactgroups.cfg

define contactgroup{
  contactgroup_name             Kontaktgruppe
  alias                         Alias
  members                       Mitglieder
}

[zB]Die Mitglieder einer solchen Gruppe sind natürlich wieder die entsprechenden Objektnamen, die durch Kommata getrennt werden. Aber sehen wir uns dazu ein einfaches Beispiel an:

Listing 33.29 Ein Beispiel

define contact{
  contact_name                  jploetner
  alias                         Johannes Plötner
  service_notification_period   24x7
  host_notification_period      24x7
  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                         jploetner@localhost
}
define contactgroup{
  contactgroup_name             admins
  alias                         Administratoren
  members                       jploetner, swendzel
}

Dieses Beispiel sollte eigentlich selbsterklärend sein. Man definiert zuerst den Kontakt und fügt ihn schließlich einer Kontaktgruppe hinzu.

Kommandodefinition

Plugins integrieren

Wir haben bei den Host- und den Serviceobjekten bereits auf die Kommandos Bezug genommen, mit denen diese entsprechend überwacht wurden. Dort konnte man entweder direkt einen Befehl eingeben oder eben auf ein definiertes Kommandoobjekt Bezug nehmen.

Ein solches Kommandoobjekt definiert man wie folgt:

Listing 33.30 Kommandodefinition in der etc/commands.cfg

define command{
  command_name          Kommando
  command_line          Kommandozeile
}

[zB]Dabei kann man in der Kommandozeile auch Makros nutzen, die mit einem Dollarzeichen beginnen müssen. Ein Beispiel soll diesen Sachverhalt verdeutlichen:

Listing 33.31 Ein Beispiel

define command{
  command_name           check_pop
  command_line           /usr/local/nagios/libexec/  \
    check_pop -H $HOSTADDRESS$
}

In diesem Beispiel wird das Kommando check_pop definiert, das ein gleichnamiges Skript im libexec/-Verzeichnis mit dem entsprechenden Rechnernamen als Argument aufruft.

Wenn die Plugins installiert wurden, dann hat man schon eine ganze Reihe sinnvoller Kommandos zur Verfügung. Im Folgenden soll eine kleine Übersicht über die wichtigsten Skripte und Programme gegeben werden. Für eine ausführliche Übersicht sei Ihnen aber immer noch die Dokumentation der Plugins selbst ans Herz gelegt.

33.2.3 Plugins

Wie bereits angedeutet, besitzt Nagios selbst keinerlei Möglichkeiten, irgendeinen Dienst oder Rechner zu überwachen. Die Software verlässt sich voll und ganz auf die Plugins, die diese »Intelligenz« zur Verfügung stellen.

Die Intelligenz

Bekanntermaßen unterscheidet Nagios allerdings zwischen Hostchecks und Servicechecks, die beide auf dieselbe Pluginarchitektur zurückgreifen. Der einzige Unterschied besteht darin, dass bei einem Hostcheck bei jedem Nicht-OK-Wert bei der Rückgabe angenommen wird, dass der Rechner »down« ist.

Dass man die Plugins schließlich über Kommandodefinitionen einbindet, die man dann in den Host- und Serviceobjekten angeben kann, sollte mittlerweile auch klar sein.

check_tcp

Portscan

Dieses Plugin ist eines der einfachsten und gleichzeitig wichtigsten. Mit ihm kann man nämlich überprüfen, ob ein Port auf einem entfernten Rechner offen oder geschlossen ist. Aus dieser Information kann man dann den Rückschluss ziehen, ob der entsprechende Dienst läuft oder abgestürzt ist.

Ruft man das Plugin auf der Kommandozeile ohne Parameter auf, so wird ein Hilfetext mit allen verfügbaren Parametern ausgegeben:

Listing 33.32 Die Parameter des Plugins

# ./check_tcp
No arguments found
Usage: check_tcp -H host -p port [-w warn_time]
  [-c crit_time] [-s send_string] [-e expect_string]
  [-q quit_string] [-m maxbytes] [-d delay]
  [-t to_sec] [-v]

In einer Kommandodefinition könnte man das Plugin also zum Beispiel wie folgt ansprechen:

Listing 33.33 Beispiel: check_tcp

define command{
  command_name                  check_port_cups
  command_line                  $USER1$/check_tcp -H \
    $HOSTADDRESS$ -p 631
}

[zB]In dem Beispiel wollen wir also einen Check definieren, der einen laufenden CUPS-Server überprüft. Dazu nutzen wir zwei Makros: Das in der etc/resource.cfg definierte $USER1$-Makro spart uns die Angabe des vollständigen Pfadnamens zum Pluginverzeichnis, und zur Laufzeit von Nagios wird das Makro $HOSTADDRESS$ durch die Adresse des zu überprüfenden Rechners ersetzt.

In einem Serviceobjekt könnte man nun wie folgt den CUPS-Server überwachen lassen:

Listing 33.34 CUPS-Server überwachen

define service{
  host_name                     printserver,testserver
  service_description           CUPS
  check_command                 check_port_cups
  ...
}

check_ping

Rechnerstatus berechnen

Für Hostchecks möchte man natürlich am liebsten ICMP-Echo-Pakete mittels ping verschicken. Zu diesem Zweck gibt es das Plugin check_ping, das meist wie folgt als Kommando definiert wird:

Listing 33.35 check-host-alive

define command{
  command_name                  check-host-alive
  command_line                  $USER1$/check_ping   \
    -H $HOSTADDRESS$ -w 3000.0,80 % -c 5000.0,100 % -p 1
}

Das check-host-alive-Kommando ist uns aber schon in der Definition der Hostobjekte begegnet, wo wir es als sinnvolles Standardkommando zur Überprüfung des Hoststatus vorgestellt hatten.

NRPE und NSCA

Richtig interessant wird Nagios allerdings erst, wenn Erweiterungen wie NRPE beziehungsweise NCSA ins Spiel kommen. Diese Dienste laufen auf dem zu überwachenden Rechner und können Nagios diverse Informationen wie noch verfügbare Plattenkapazität, Prozessorauslastung oder Speicherauslastung mitteilen.

Aktive vs. passive Checks

Mit NRPE kann man dabei aktive Checks realisieren: Man installiert auf dem Clientsystem – die Software gibt es für Windows und Unix – den NRPE-Dienst und auf dem Nagios-Server das check_nrpe-Plugin. Entsprechend konfiguriert, überprüft Nagios nun über das Plugin regelmäßig den Status des Systems.

Setzt man dagegen NCSA ein, so kann man passive Checks realisieren. Dies ist zum Beispiel nützlich, wenn das zu überwachende System hinter einer Firewall sitzt. Mit dieser Software baut nämlich der Client regelmäßig selbst die Verbindung zu der auf dem Nagios-Server laufenden Software auf.

Wie Sie sehen, kann man mit Nagios sehr komplexe Monitoringstrukturen umsetzen. Da das Thema aber recht verwickelt ist, wollen wir es bei diesem Einblick in die Thematik belassen und Sie ein letztes Mal auf die verfügbare Dokumentation verweisen.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.