28    Monitoring – wissen, was läuft

Nagios ist noch immer der Platzhirsch des Monitorings und ist der geistige Urvater vieler verschiedener Monitoring-Lösungen, die sich aus Nagios heraus entwickelt haben. Dieses Kapitel führt Sie in die Installation, Denkweise und Konfiguration von Nagios und seinen verschiedenen Derivaten ein und zeigt die Überwachung von Serverdiensten und freiem Festplattenplatz am Beispiel eines Webservers. Eine kleine Einführung in Munin bietet den Blick über den Tellerrand.

Seit der ersten Veröffentlichung 1999 – damals noch unter dem Namen NetSaint, der wegen Markenrechtsansprüchen geändert werden musste – hat das Thema »Monitoring« in der IT stets an Stellenwert dazugewonnen. Im Gegensatz zu anderen Lösungen beeindruckte Nagios (bzw. NetSaint) schon damals durch seine Modularität. Es kümmert sich nur um seine zentralen Aufgaben und verlagert andere Arbeit an Plugins bzw. externe Programme. Die notwendigen Schnittstellen sind gleichzeitig so simpel gehalten, dass man mit etwas Programmiererfahrung Nagios um eigene Skripte erweitern kann und damit quasi alles überwachen kann, was man nur will.

Die Weiterentwicklung von Nagios stockte allerdings mit der Version 3 (»Nagios Core 3« als Abgrenzung zu den kommerziellen Varianten und anderen Add-ons), und so begannen andere Entwickler das Projekt voranzutreiben – allerdings teilweise unter anderem Namen.

Neben diesen direkten Abspaltungen oder Forks von Nagios gibt es weitere Projekte, die sich von Nagios (oder Icinga) inspirieren ließen. Keines davon hat allerdings nur annähernd die Aufmerksamkeit von Icinga, Check-MK oder Naemon auf sich ziehen können.

Alle genannten Systeme verwenden die sogenannten Plugins, um zu testen, ob gewisse Eigenschaften eines Rechners im Rahmen der Erwartungen sind. Diese Plugins wurden von den ursprünglichen Entwicklern bereits sehr früh vom Nagios-System getrennt, was zu einem neuen »Nagios Plugins«-Projekt mit anderen Entwicklern als Nagios führte. Lange Zeit existierten beide Projekte nebeneinander, wobei die Nagios Plugins eben auch von anderen Monitoring-Systemen genutzt wurden.

Es kam dann aber zu einer Meinungsverschiedenheit zwischen den Hauptentwicklern beider Projekte, was schließlich darin endete, dass es heute zwei Plugin-Projekte gibt: »Nagios Core Plugins« (www.nagios-plugins.org – programmiert und finanziert von »Nagios Enterprises, LLC«, der Firma des Nagios-Erfinders Ethan Galstad, die auch »Nagios Core« weiterentwickelt) und »Monitoring Plugins« (www.monitoring-plugins.org – mit den bisherigen Entwicklern).

28.1    Monitoring mit Naemon

Auch wenn die Zahl der entstandenen Monitoring-Lösungen fast unüberschaubar ist – die geistige Urheberschaft von Nagios bleibt oft kaum verborgen. Haben Sie Aufbau und Konfiguration von Nagios verstanden, werden Sie auch mit vielen anderen Lösungen und Erweiterungen keine Verständnisschwierigkeiten mehr haben und auch die Plugins sind i.d.R. sehr einfach oder gar ohne Änderung übertragbar.

Im folgenden zeigen wir Ihnen die Installation am Beispiel von Naemon, dem Nagios-Fork eines früheren Nagios-Core-Entwicklers. Naemon ist, das ist die Ironie der Geschichte, heute quasi noch das ursprünglichste Nagios und vielleicht mehr »Nagios« als das eigentliche heutige Nagios, von dem sich Naemon losgesagt hat.

Wann immer im folgenden von Naemon oder Nagios die Rede ist können Sie i.d.R. beide Namen gegeneinander austauschen. Je nach Projekt und Distribution heißen die inhaltlich identischen Installationspakete der Plugins bzw. deren Pfade darum mal nagios-plugins, mal naemon-plugins und manchmal auch monitoring-plugins. Verstehen Sie beide Begriffe Nagios und Naemon im folgenden also Synonym zueinander – auch Pfade heißen je nach Distribition mal /etc/nagios und mal /etc/naemon...

Da Naemon anders als Nagios-XI auf eine freie Community-Version setzt sind bequeme Installationspakete für gängige Distributionen bequem verfügbar. Sie finden eine Übersicht der unterstützten Distributionen nebst kurzen Installationsanleitungen und Repos auf: https://labs.consol.de/repo/stable/

Erster Start

Wenn Sie die Naemon-Pakete installiert haben sind Sie eigentlich schon direkt startklar, denn auch das Webfrontend im Apache-Webserver wurde bereits für Sie konfiguriert. Wenn das ohne Fehler geklappt hat, erscheint unter http://localhost/thruk/ eine Aufforderung, sich anzumelden, was mit dem bei der Installation angelegten Benutzer thrukadmin und dessen Passwort thrukadmin funktionieren sollte. Dieses Passwort sollten Sie alsbald über zu das Kommando htpasswd /etc/thruk/htpasswd thrukadmin ändern!

Um die – zugegeben sehr kleine – mitgelieferte Beispiel-Konfiguration bzw. deren Ergebnis zu sehen, klickt man in der linken Navigationsleiste auf Services.

28.1.1    Allgemeine Konfiguration

Im Verzeichnis /etc/naemon/ befinden sich die Hauptkonfigurationsdatei naemon.cfg. Diese enthält die Einstellungen für den naemon-Prozess, der das Monitoring an sich durchführt.

Die Web-Oberfläche Thruk wird im Verzeichnis /etc/thruk/ konfiguriert. Hier sind die vom klassischen Nagios-Web-Frontend geerbten Einstellungen in der Datei cgi.cfg, Thruk-spezifische Parameter in thruk.cfg (Defaults) bzw. thruk_local.cfg (vom Benutzer gewünschte Änderungen) abgelegt.

Aus /etc/naemon/naemon.cfg wird über die Option cfg_dir der Inhalt aller .cfg-Dateien im Verzeichnis /etc/naemon/conf.d nachgeladen, wo Sie sich auch eine eigene Struktur zur Verwaltung einer komplexeren Umgebung zusammenbauen können.

ubuntu@ubuntu:~# ls -la /etc/naemon/conf.d/
total 56
drwxrwsr-x 3 naemon naemon 4096 Sep 19 17:02 .
drwxr-xr-x 4 root   root   4096 Sep 19 17:02 ..
-rw-rw-r-- 1 naemon naemon 8375 Jul 16 09:21 commands.cfg
-rw-rw-r-- 1 naemon naemon 2155 Jul 16 09:21 contacts.cfg
-rw-rw-r-- 1 naemon naemon 5453 Jul 16 09:21 localhost.cfg
-rw-rw-r-- 1 naemon naemon 3708 Jul 16 09:21 printer.cfg
-rw-rw-r-- 1 naemon naemon 4058 Jul 16 09:21 switch.cfg
drwxrwsr-x 2 naemon naemon 4096 Sep 19 17:01 templates
-rw-rw-r-- 1 naemon naemon 3666 Jul 16 09:21 timeperiods.cfg
-rw-rw-r-- 1 naemon naemon 4971 Jul 16 09:21 windows.cfg

Listing 28.1    Mitgelieferte Konfiguration von Naemon, aufgeteilt in verschiedene Dateien

28.1.2    Konfiguration der Objekte

Naemon (Nagios) und seine Derivate kennen insgesamt 14 verschiedene Objekte, davon drei Gruppenobjekte und zwei veraltete. Im täglichen Betrieb benötigt man davon die Hosts (und Hostgroups) und die Services (eventuell Servicegroups). Deutlich seltener hat man mit Commands, Contacts (sowie Contactgroups) und Timeperiods zu tun.

Allen Objekten ist gemein, wie sie definiert werden. Ein neues Objekt beginnt immer mit dem Schlüsselwort define, daran schließen sich dann der Typ des Objekts (zum Beispiel host oder contactgroup) und eine öffnende geschweifte Klammer an. In den folgenden Zeilen werden den Attributen des Objekts Inhalte zugewiesen, bevor das Objekt mit einer schließenden geschweiften Klammer wieder beendet wird.

define host {
  host_name  localhost
  alias      localhost
  address    127.0.0.1
  use        linux-server
}

Listing 28.2    Definition des Hosts »localhost« in der mitgelieferten Konfiguration »localhost.cfg«

Im Unterordner /etc/naemon/conf.d/templates sind in cfg-Dateien verschiedene Templates definiert. Diese dienen vor allem dazu, immer wiederkehrende Attribute nur einmal zu setzen (und gegebenenfalls dann auch an einer Stelle ändern zu können) und ebenso die Konfiguration kürzer und somit übersichtlicher zu machen. Dabei ist der Wert, der im Template gesetzt wird, nicht fest, sondern kann in einem Template darüber oder beim Objekt selbst überschrieben werden.

Templates sind somit Segen und Fluch zugleich. Die kurze Konfiguration lässt sich wesentlich leichter überblicken, man sieht mehrere Objekte gleichzeitig auf einer Bildschirmseite. Auf der anderen Seite allerdings sind auch nicht mehr alle Attribute zu sehen und müssen somit in den einzelnen Templates nachgesehen werden. Die Templates sollten folglich immer aussagekräftige Namen tragen.

[+]  Von einem zu exzessiven Gebrauch von Templates (sowohl Anzahl allgemein als auch Stufen der Vererbung) muss also abgeraten werden, da es letztendlich dazu führen kann, dass man den Überblick verliert. Listing 28.3 zeigt ein einfaches Template, das über das Attribut use Attribute von einem anderen Template oder Template-Objekt (hier: generic-host) veerbt bekommt.

define host {
  name                   linux-server
  use                    generic-host
  check_command          check-host-alive
  check_period           24x7
  check_interval         5
  contact_groups         admins
  max_check_attempts     10
  notification_interval  120
  notification_options   d,u,r
  notification_period    workhours
  register               0
  retry_interval         1
}

Listing 28.3    Das Template »linux-server«, durch das »use«-Attribut abgeleitet von »generic-host«

Das Attribut register, insbesondere mit dem Wert 0, hat ebenfalls eine Sonderbedeutung. Dieses Objekt nutzt Nagios lediglich für die Vererbung und nicht zur Konfiguration eines konkreten Objekts (hier eines Hosts).

Wie in Listing 28.3 ebenfalls zu sehen ist, kann man auch Templates von anderen Templates ableiten. Das Template generic-host enthält ausschließlich nicht notwendige, voreingestellte oder später überschriebene Attribute, weswegen hier auf eine Auflistung verzichtet wird.

Host und Hostgroup

Schauen wir uns nun die Definition der zu überwachenden Hosts an. Das vordefinierte Hostobjekt localhost aus /etc/naemon/conf.d/localhost.cfg enthält direkt drei Attribute, die einen Host grundlegend identifizieren bzw. konfigurieren:

Unser Host localhost erbt aus dem Template linux-server nun folgende Attribute:

Einige weitere Attribute werden in diesem Beispiel nicht verwendet, werden aber in der Praxis häufig benutzt, so dass wir diese nicht vorenthalten möchten:

Zusätzlich wird die Hostgroup linux-server ebenfalls in der Datei localhost.cfg mit dem Inhalt aus Listing 28.4 definiert:

define hostgroup {
  hostgroup_name  linux-servers
  alias           Linux Servers
  members         localhost
}

Listing 28.4    Definition der Hostgroup »linux-servers«

Die Parameter haben dabei folgende Bedeutung:

Service und Servicegroup

Neben den zu überwachenden Hosts müssen auch die einzelnen Services definiert werden, die auf den Hosts überwacht werden sollen. Zur Veranschaulichung der Services sollen hier zwei genannt werden: Root Partition, ein lokaler Check, der den Füllstand (genauer den freien Speicherplatz) der root-Partition überwacht, und HTTP, der eine HTTP-Verbindung zu einem Host (hier localhost) öffnet und überprüft, ob auch mit HTTP geantwortet wird. Die entsprechenden Servicedefinitionen dafür ist in Listing 28.5 dargestellt:

define service {
  service_description            Root Partition
  host_name                      localhost
  use                            local-service
  check_command                  check_local_disk!20%!10%!
}

define service {
  service_description            HTTP
  host_name                      localhost
  use                            local-service
  check_command                  check_http!-u /thruk/
  notifications_enabled          0
}

Listing 28.5    Servicedefinitionen für einen »Partitions-« und einen »Webserver-Check«

Die Parameter haben dabei folgende Bedeutung:

Aus dem Template local-service erbt der Service weitere Attribute, die äquivalent zu denen bei den Hosts sind oder weggelassen werden können, weil sie voreingestellt sind.

Contact und Contactgroup

Ein Contact ist, als einzelner Contact oder über eine Contactgroup, beliebig vielen Hosts und Services zugewiesen. Dies hat zwei Folgen:

  1. Im Falle eines Ereignisses, zum Beispiel des Auftretens oder Verschwindens eines Fehlers, werden die verbundenen Contacts benachrichtigt.

  2. Im Web-Frontend sieht ein Contact die Hosts und Services, für die er als Contact oder via Contactgroup eingetragen wurde. Damit er sich dort einloggen kann, muss ihm auch ein Passwort in der htpasswd-Datei zugewiesen werden.

Der Contact naemonadmin wird in der Objektkonfiguration hinterlegt und dient als Vorlage für weitere Benutzer, welche vom Monitoring-System benachrichtigt werden sollen. Zum vollständigen Monitoring-Benutzer fehlt ihm noch ein Passwort für den Zugriff auf die WebOberfläche Thruk. Dies kann durch den Befehl htpasswd /etc/thruk/htpasswd naemonadmin hinzugefügt werden.

Verwechseln Sie den (Naemon-)Benutzer naemonadmin nicht mit dem (Thruk-)Benutzer thrukadmin! Letzterer wird in der Objektkonfiguration nicht angelegt, er erhält seine Rechte in der Datei /etc/thruk/cgi.cfg. Hier wird er über einige authorized_for_*-Einträge zum Administrator mit allen Rechten.

In der Praxis bietet es sich an, Personen als Contact-Object zu hinterlegen und ihnen den Zugriff auf die Web-Oberfläche zu ermöglichen. Ob dann einer (oder mehrere) von diesen oder ein getrennter Administrator Vollzugriff auf der Web-Oberfläche, ist eine persönliche Entscheidung.

Listing 28.6 zeigt die Definition des naemonadmin-Benutzers:

define contact {
  contact_name                   naemonadmin
  alias                          Naemon Admin
  use                            generic-contact
  email                          your@mail.addr.ess
}

Listing 28.6    Definition des »naemonadmin«-Contacts

Die einzelnen Parameter haben dabei folgende Bedeutung:

[ ! ]  Mindestens »email« oder »pager«

Eines der beiden Attribute email oder pager muss bei einem Contact gesetzt sein, da es ansonsten zu einem Fehler kommt!

Wie Sie Listing 28.6 entnehmen können, erbt der naemonadmin die Definition von generic-contact aus dem template-Unterordner. Diese sehen wir uns nun genauer an:

define contact {
  name                           generic-contact
  host_notification_commands     notify-host-by-email
  host_notification_options      d,u,r,f,s
  host_notification_period       24x7
  register                       0
  service_notification_commands  notify-service-by-email
  service_notification_options   w,u,c,r,f,s
  service_notification_period    24x7
}

Listing 28.7    Definition des »generic-contact«

Die gesetzten Parameter haben die folgende Bedeutung (beachten Sie, dass wir die einzelnen Parameter zusammengefasst haben – symbolisiert durch ein Sternchen):

Abschließend sehen wir uns die Definition einer Kontaktgruppe genauer an. In Listing 28.8 sehen Sie die Definition der standardmäßig eingerichteten Kontaktgruppe admins.

define contactgroup {
  contactgroup_name              admins
  alias                          Naemon Administrators
  members                        naemonadmin
}

Listing 28.8    Definition der Kontaktgruppe »admins«

Die Parameter haben dabei folgende Bedeutung:

Command

Wenn Nagios eine externe Aktion (Überprüfung, Benachrichtigung etc.) auslösen muss, geschieht dies über die Command-Objekte, das heißt, jedes auszuführende Kommando muss als Command im Nagios definiert werden.

Die mit großem Abstand meisten Command-Objekte sind Checks, also Überprüfungen durch Aufruf eines Plugins. Allerdings benötigen die Plugins auf der Kommandozeile verschiedene Parameter, sodass keine festen Kommandozeilen vorgegeben werden, sondern diese mit sogenannten Macros definiert werden.

Diese Macros ersetzt Nagios dann unmittelbar vor der Ausführung durch entsprechende Werte betroffener Objekte (zum Beispiel Adresse des Hosts), durch Argumente bei der Servicedefinition (Argumente des check_command beim Service) oder statische Inhalte aus der Datei resource.cfg ($USERx$). Bei Benachrichtigungs-Commands finden sich allerdings deutlich mehr Macros, die in der Dokumentation ausführlich beschrieben sind.

Die wichtigsten Macros sind:

Listing 28.9 zeigt die Macros im Einsatz bei zwei Command-Definitionen:

define command {
  command_name  check_local_disk
  command_line  $USER1$/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$
}

define command{
  command_name  check_http
  command_line  $USER1$/check_http -I $HOSTADDRESS$ $ARG1$
}

Listing 28.9    Definition der Kommandos »check_local_disk« und »check_http«

Die dabei verwendeten Parameter haben folgende Bedeutung:

Werden die beiden Commands check_local_disk und check_http mit den Services Root Partition und HTTP aufgerufen, ergeben sich folgende Kommandozeilen, die schließlich von Nagios ausgeführt werden:

Da die Plugins ausführbare Programme bzw. Skripte sind, kann man diese Kommandozeilen auch manuell ausführen.

Insbesondere beim Einrichten neuer, unbekannter Plugins kann man so vor der Konfiguration seines Monitoring-Systems testen, ob das Plugin funktioniert, vernünftige Werte liefert und/oder mit der Hard- und Software sauber zusammenarbeitet.

Timeperiod

Der Host localhost verwendet zwei Timeperiod-Objekte: 24x7 (Überprüfung) und workhours (Benachrichtigung). Diese sind in der Datei timeperiods.cfg definiert.

Listing 28.10 zeigt die standardmäßige Konfiguration des Objekts workhours:

define timeperiod {
  timeperiod_name workhours
  alias           Normal Work Hours
  monday          09:00-17:00
  tuesday         09:00-17:00
  wednesday       09:00-17:00
  thursday        09:00-17:00
  friday          09:00-17:00
}

Listing 28.10    Timeperiod »workhours«, die die normalen Arbeitszeiten abbildet

Für jeden Wochentag können (auch mehrere, kommaseparierte) Zeitabschnitte definiert werden, wann diese Timeperiod zutreffen soll.

28.1.3    Eigene Hosts und Services konfigurieren

Um die Konfiguration zu erweitern, greift man einfach auf die schon vorhandenen Objekte zurück und legt eigene cfg-Dateien im Verzeichnis /etc/naemon/conf.d ab.

[»]  Als Beispiel dient ein Webserver mit der Adresse 192.168.1.80, auf dem sowohl eine HTTP- als auch eine HTTPS-Verbindung geprüft werden soll.

Es werden also ein Hostobjekt und zwei Serviceobjekte benötigt. Da für den HTTP-Test bereits sowohl ein Command als auch ein Service existiert, ist hier nur Copy&Paste mit kleinen Anpassungen notwendig.

Erstellen Sie dafür eine neue Datei im Verzeichnis conf.d und fügen Sie zur Definition des Host-Objekts den Inhalt aus Listing 28.11 hinzu.

define host {
  host_name  web-server
  alias      Der Web-Server
  address    192.168.1.80
  use        linux-server
}

Listing 28.11    Definition des Hosts »web-server«

Anschließend müssen Sie noch den HTTP-Test einrichten. Fügen Sie dafür den Inhalt aus Listing 28.12 an das Ende der neu erstellten Datei an:

define service {
  host_name              web-server
  service_description    HTTP
  check_command          check_http
  use                    local-service
}

Listing 28.12    Definition des Services »HTTP«

Für den HTTPS-Test existiert weder ein Service- noch ein eigenes Command-Objekt. Es stellt sich an sich die Frage, wie ein HTTPS-Server getestet werden kann.

Da HTTPS die verschlüsselte Variante von HTTP ist, ruft man das Plugin check_http zunächst mit dem Schalter --help auf, um zu prüfen, welche Parameter der Test verarbeiten kann:

ubuntu@ubuntu:~# /usr/lib/nagios/plugins/check_http --help
check_http v2.2 (monitoring-plugins 2.2)
…
 -S, --ssl=VERSION
    Connect via SSL. Port defaults to 443. VERSION is optional, and prevents
    auto-negotiation (1 = TLSv1, 2 = SSLv2, 3 = SSLv3).

 -C, --certificate=INTEGER[,INTEGER]
    Minimum number of days a certificate has to be valid. Port defaults to 443
    (when this option is used the URL is not checked.)
…

Listing 28.13    Hilfe-Ausgabe von »check_http«

Wie Sie Listing 28.13 entnehmen können, ist der HTTP-Test in der Lage, auch HTTPS-Anfragen zu generieren. Das Plugin muss dafür mit dem Schalter --ssl oder -S aufgerufen werden.

Da gleichzeitig noch die Möglichkeit besteht, die Laufzeit des SSL-Zertifikats zu testen, wird dies hier ebenfalls gemacht.

Es gibt nun zwei Möglichkeiten, dies in der Konfiguration zu hinterlegen:

  1. Definition eines neuen Commands check_https_cert mit angepasster Kommandozeile:

    define command {
      command_name  check_https_cert
      command_line  $USER1$/check_http -I $HOSTADDRESS$ --ssl -C $ARG1$
    }  
    define service {
      host_name              web-server
      service_description    HTTPS
      check_command          check_https_cert!14
      use                    local-service
    }

    Listing 28.14    Variante 1: eigenes Command

  2. Übergabe der Schalter --ssl -C 14 über $ARG1$ des bereits definierten Commands check_http:

    define service {
      host_name              web-server
      service_description    HTTPS
      check_command          check_http!--ssl -C 14
      use                    local-service
    }

    Listing 28.15    Variante 2: Übergabe bei Service

Erstere ist die aufwendigere Variante, insbesondere wenn man sich alle Möglichkeiten und Features der Plugins ansieht. Andererseits ist check_https_cert sprechender und gerade bei sehr komplexen Kombinationen von Plugin-Optionen einfacher zu verstehen.

In der mitgelieferten Datei commands.cfg befinden sich weitere Check-Commands, die sofort verwenden werden können. Unabhängig davon sollte man sich die Zeit nehmen, um die Monitoring-Plugins nacheinander mit dem Schalter --help aufzurufen und auszuprobieren.

Die Monitoring-Plugins bringen zwar einen guten Grundstock an Plugins mit, doch reichen diese in keinem Fall aus. Für viele Hard- und Software gibt es spezialisierte Plugins, die man auf den Webseiten

findet – aber auch eine Suche per Suchmaschine nach »Nagios Plugin« und dem gesuchten Produkt bringt häufig Erfolg.

28.1.4    Benachrichtigungen

Tritt ein Ereignis (unter anderem das Auftreten eines Fehlers oder Verschwinden desselben) ein, läuft die Benachrichtigungsmaschine des Cores los. Unter anderem wird dort ermittelt, welche Contacts denn mit dem entsprechenden Host oder Service verbunden sind. Bevor jedoch ein Notification-Command ausgeführt wird, testet der Core diverse Punkte:

Es existieren folgende Hostereignisse:

Ein Service kann folgende Ereignisse haben:

Daneben gibt es noch zwei Ereignisse, die sowohl Host als auch Service betreffen können:

Sind alle Filter erfolgreich passiert worden, führt der Core für jeden Contact das oder die jeweiligen host_notification_commands bzw. service_notification_commands aus. Für den schon definierten naemonadmin-Contact wären dies notify-host-by-email bzw. notifyservice-by-email, die beide in der Datei commands.cfg definiert sind (siehe Listing 28.16).

define command {
  command_name  notify-host-by-email
  command_line  /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: \
    $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: \
    $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" \
    | /bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" \
    $CONTACTEMAIL$
}

Listing 28.16    »notify-host-by-email« aus »commands.cfg«

Es wird mithilfe einer Reihe von Macros ein Text definiert, der dem Contact geschickt werden soll. In den mitgelieferten Commands wird mit dem Befehl printf und Steuerzeichen der Text für eine E-Mail aufbereitet.

Das Ergebnis wird dann per Pipe an mail weitergereicht, der für die Mail noch eine Betreffzeile (-s) und am Ende den Empfänger ($CONTACTEMAIL$) übergeben bekommt. Ist auf dem Monitoring-Server kein MTA installiert, können Sie zum Beispiel sendEmail verwenden, um die Mail per SMTP auf einen anderen Rechner abzuliefern.

Die Benachrichtigung per E-Mail ist die häufigste Variante. Allerdings kann man in den Notification-Commands alles einbauen, was in der Kommandozeile möglich ist. So sind neben SMS (mit den Projekten smsclient, smstools, Gammu) auch Benachrichtigungen per Jabber, IRC und vielen anderen Instant-Messenger-Systemen möglich.

Wer ungern liest und lieber zuhört, der kann sich die Meldungen auch vorlesen lassen. Der Fantasie sind hier fast keine Grenzen gesetzt.

28.1.5    NRPE – Partitionsfüllstand und andere lokale Werte remote überprüfen

Mit NRPE (Nagios Remote Plugin Executions) können Sie Plugins direkt auf den überwachten Rechnern ausführen und deren Ergebnis an den Monitoring-Server zurückliefern lassen kann.

Interessante NRPE-Plugins sind beispielsweise:

NRPE und Plugins installieren

Beachten Sie, dass sich dabei der Sprachgebrauch umdreht: Der oder die NRPE-Server (oder auch: NRPE-Dämon) ist der oder sind die überwachte Rechner, während hingegen der NRPEClient (oder NRPE-Plugin) nun der anfragende Naemon/Nagios-Server ist.

Auf dem zu überwachenden Rechner müssen darum Monitoring-Plugins und das des Paket nagios-nrpe-server (Debian) bzw. nrpe (CentOS) installiert werden. Der Monitoring-Server selbst benötigt diese NRPE-Server-Komponente eigentlich nicht, aber da Sie ihn vermutlich ebenfalls identisch mit überwachen wollen, ist er halt NRPE-Server und NRPE-Client zugleich.

Installieren Sie also auf jedem zu überwachenden System und dem Naemon-Server:

Achtung: Aufgrund des zu Anfang des Kapitels angesprochenen Durcheinander von Nagios-Derivaten und Plugin-Entwicklerteams lauten die nachfolgenden Konfigurationspfade des NRPE-Projekts wieder /etc/nagios auch wenn Sie NRPE hier unter Naemon einsetzen.

Darum: In der Konfigurationsdatei /etc/nagios/nrpe.cfg befinden sich einige Einstellungen für den NRPE-Server, von denen die wichtigsten hier aufgeführt sind:

server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=127.0.0.1

Listing 28.17    Die wichtigsten Einstellungen des NRPE-Daemons

Die wenigen notwendigen Einstellungen sind leicht verständlich:

Wenn der NRPE-Daemon gestartet ist, lässt sich durch einen lokalen Verbindungsaufbau testen, ob die Installation fehlerfrei verlief. Dazu ruft man das auf dem Monitoring-Server als Plugin installierte Tool check_nrpe nur mit der Angabe eines Hosts, hier localhost, auf. Gibt das Plugin NRPE plus die Versionsnummer des Daemons aus, steht einer weiteren Überwachung nichts mehr im Wege, so wie in Listing 28.18 dargestellt:

ubuntu@ubuntu:~# /usr/lib/nagios/plugins/check_nrpe -H localhost
NRPE v3.0.1

Listing 28.18    Erster lokaler Verbindungstest - erfolgreich

Typische Fehler, die an dieser Stelle passieren können, sind:

Funktioniert der Aufruf, kann man einen Blick auf die bereits definierten Commands in der nrpe.cfg werfen. Diese sind nichts anderes als Kommandozeilen, die Monitoring-Plugins mit entsprechenden Argumenten und Optionen aufrufen und dies unter einem Bezeichner im NRPE registrieren.

So prüft der Bezeichner check_user die Anzahl der eingeloggten User und check_sda1 mithilfe des Plugins check_disk den freien Speicher auf /dev/sda1 – dies ist für den alltäglichen Betrieb natürlich nicht hilfreich.

Es bietet sich hier an, einen Bezeichner check_disk_root zu definieren, der den freien Speicher auf der root-Partition testet (Angabe von / statt /dev/sda1) und gegebenenfalls weitere Command-Definitionen für weitere Partitionen bzw. Dateisysteme.

command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_sda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda1
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200

Listing 28.19    Vordefinierte Plugin-Aufrufe

In Listing 28.20 sehen Sie die Ausgabe des Aufrufs eines Plugins mit NRPE:

ubuntu@ubuntu:~# /usr/lib/nagios/plugins/check_nrpe -H localhost \
                 -c check_total_procs
PROCS OK: 139 processes | procs=139;150;200;0;

Listing 28.20    Ausführen eines Plugins via NRPE

Hat man im Laufe der Zeit eine Liste von Commands definiert, so kann man diese auch in eine oder mehrere Dateien auslagern und diese dann per include (einzelne Datei) oder include_dir (rekursiv alle Dateien mit der Endung .cfg) in der nrpe.cfg einlesen lassen.

Nun muss der NRPE-Daemon vom Monitoring-System aus kontaktiert werden. Dazu legt man ein neues Command-Objekt an, das check_nrpe aufruft und ihm den zu testenden Bezeichner übergibt. Dieses wird dann in einem Serviceobjekt verwendet:

define command {
  command_name  check_nrpe
  command_line  $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Listing 28.21    Definition des »check_nrpe«-Command-Objekts

Entsprechend kann das Command-Objekt in einem Service verwendet werden:

define service {
  host_name              linux-server
  service_description    Root-Partition
  check_command          check_nrpe!check_disk_root
  use                    local-service
}

Listing 28.22    Service auf dem entfernten Host