Nagios Anleitung: Netzwerk-Überwachung von Windows- und Linux-Clients

Im ersten Teil Nagios Grundlagen HowTo für Anfänger wurde das Grundprinzip von Nagios erläutert, damit man ein wesentliches Verständnis darüber erhält. Trotzdem ist und bleibt Nagios ein komplexes Thema und es trifft sicherlich das Sprichwort "Man sieht vor lauter Bäumen den Wald nicht mehr". Diese Anleitung zeigt mithilfe von einigen Beispielen, wie man einzelne Clients (Windows- und Linux-Clients) im Netzwerk auf bestimmte Dienste überprüft und wie man die Clients strukturieren bzw. gruppieren kann.

Am besten lernt man, wenn man die Theorie in die Praxis umsetzt. Anfängern soll somit ein Einstieg in die Konfiguration von Nagios vermittelt werden.

Vorbereitung: Kontaktpersonen definieren

Bevor man damit beginnt, die einzelnen Hosts, Services oder Commands zu definieren, sollte man die Kontaktpersonen definieren, welche im Falle eines Ausfalls informiert werden. Bei Ausfall oder Fehlern bestimmter Dienste und Clients startet Nagios automatische Alarmierung, die individuell konfiguriert wird. Dazu öffnen wir die /etc/nagios/objects/contacts.cfg:

# 1. Kontaktperson
define contact{
        contact_name    meik
        use             generic-contact
        alias           Meik Schmidt
        email           mschmidt@pc-erfahrung.de
        }

# 2. Kontaktperson
define contact{
        contact_name    peter
        use             generic-contact
        alias           Peter Pan
        email           peter@pc-erfahrung.de
        }

# Definition Admin-Gruppe
# meik und peter sind Mitglieder dieser Gruppe
define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members meik,peter
}

In diesem Beispiel wurden zwei Kontaktpersonen (meik, peter) erstellt, welche Mitglieder einer gemeinsamen Gruppe (admins) sind. Die Zuweisung einer Gruppe ist nicht zwingend erforderlich, erleichtert aber später die Administration bei mehreren Kontakten, indem man anstelle der einzelnen Kontakten die Gruppe angibt.

Überwachung von Linux Webservern

Dazu legen wir im Verzeichnis /etc/nagios/objects/ eine neue Datei namens web.cfg an, welche unsere neuen Definitionen enthalten wird. Damit Nagios die neue Datei auch einliest, erweitern wir die /etc/nagios/nagios.cfg:

# You can specify individual object config files as shown below:
cfg_file=/etc/nagios/objects/contacts.cfg
cfg_file=/etc/nagios/objects/commands.cfg
cfg_file=/etc/nagios/objects/commands-nrpe.cfg
cfg_file=/etc/nagios/objects/timeperiods.cfg
cfg_file=/etc/nagios/objects/templates.cfg

# Definitions for monitoring the local (Linux) host
#cfg_file=/etc/nagios/objects/localhost.cfg
cfg_file=/etc/nagios/objects/web.cfg

Nach der Bekanntmachung in Nagios kann die Datei web.cfg nun dazu verwendet werden, um neue Definitionen anzulegen. Und damit beginnen wir nun, indem wir zwei neue Hosts anlegen, welche die physikalischen Rechner repräsentieren:

# Auszug web.cfg
define host{
use linux-server ; verwende Template
host_name server01 ; Name des Rechners
alias Webserver Nr. 1 ; Alias (erweiterter Namer)
address 212.68.X.X ; IP-Adresse
}

define host{
use linux-server
host_name server02
alias Webserver Nr. 2
address 212.68.X.X
}

Wie bereits in Kapitel 1 erklärt, erfüllen die Definitionen host_name, alias und address noch nicht die Mindestanforderungen eines Hosts. Dies wird durch die Einbindung des Templates linux-server erreicht, welcher zahlreiche Standard-Definitionen übergibt. Ein Blick in die templates.cfg macht die Standard-Definitionen sichtbar:

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

Kommen wir aber zurück zu unserer Ausgangsdatei web.cfg. Nachdem die beiden Hosts definiert wurden, ist es sinnvoll, diese zu einer Gruppe zusammenzuschließen. Gerade in großen Umgebungen sind Gruppen nützlich, da man spezielle Einstellungen für eine ganzen Gruppe und nicht mühsam Host für Host vornehmen kann. Beispiele für Gruppen wären "Windows-Server", "Linux-Webserver", "Windows-Arbeitsstationen" oder "Drucker-Einkauf".

Gruppen-Definitionen sind also nicht zwingend erforderlich, erleichtern aber die Administration und verbessern die Übersicht in der Nagios-Weboberfläche. Die Umsetzung ist relativ einfach, da zum einen die Gruppe erstellt und zum anderen die Hosts dieser Gruppe hinzugefügt werden:

# Auszug web.cfg

# HOSTS

define host{
use linux-server
host_name server01
alias Webserver Nr. 1
address 212.68.X.X
hostgroups http Server Gruppe ; Host zur Gruppe hinzufügen
}

define host{
use linux-server
host_name server02
alias Webserver Nr. 2
address 212.68.X.X
hostgroups http Server Gruppe
}

# HOSTGROUPS

define hostgroup{
hostgroup_name http Server Gruppe ; Name der hostgroup
alias Linux Webserver ; Erweiterter Name
}

Mit define hostgroup leiten wir die Hostgroup-Definition ein, welche mit zwei Zeilen (hostgroup_name und alias) bereits vollständig ist. In diesem Fall benötigen wir auch keine Einbindung eines Templates.

Was soll überwacht werden - Definition der Services

Im ersten Schritt haben wir festgelegt, wer geprüft werden soll (also die Hosts). Zur besseren Administration wurden die Hosts zu einer Gruppe zusammengeschlossen (Hostgroups). Im nächsten Schritt erstellen wir nun die Services, welche die zu prüfenden Dienste und Ressourcen festlegen. Beginnen wir mit einem einfach Beispiel dem PING, der die Erreichbarkeit eines Rechners überprüft

# Auszug web.cfg
# SERVICES

define service{
use local-service ; Verwende Template
hostgroup_name http Server Gruppe ; Wer wird geprüft --> Ganze Gruppe
service_description PING ; Name des Service
check_command check_ping!100.0,20%!500.0,60% ; Befehl
}

In diesem Beispiel verwenden wir wieder viele Standard-Einstellungen aus dem Template local-service. Letzteres legt u.a. die Informationen fest, in welchem Abständen geprüft, wer im Fehlerfall benachrichtigt oder welches Nachrichten-Medium verwendet wird. Für die vollständigen Informationen hilft ein Blick in die templates.cfg.

Der Eintrag hostgroup_name zeigt, dass dieser Service auf sämtliche Hosts der Gruppe "http Server Gruppe" angewendet wird. Alternativ zu hostgroup_name könnte man auch host_name einsetzen, um komma-separiert einzelne Hosts anzugeben. Auch eine Kombination beider ist möglich.

Was genau mit diesen Hosts geschehen soll, legt der Eintrag check_command fest. Und hier ist ein genauerer Blick notwendig: check_ping ist der eigentliche Befehl, der ausgeführt wird. Diesem Befehl werden Befehls-Argumente übermittelt, getrennt durch das Ausrufezeichen !.

Zerlegen wir den Befehl check_ping!100.0,20%!500.0,60% in die Einzelteile:

 

check_ping = Programm
100.0,20% = 1. Argument
500.0,60% = 2. Argument

Jetzt stellt sich die Frage, wo die Befehlsoptionen sind? Es muss also irgendwo hinterlegt sein, was der Befehl check_ping überhaupt macht? Lösung bringt ein Blick in die Datei commands.cfg, welche die Definition des Befehls enthält:

# Auszug commands.cfg

# 'check_ping' command definition
define command{
command_name check_ping
command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
}

Entscheidend ist an dieser Stelle der Eintrag command_line, welcher auf check_ping verweist (Command-Name und das ausführbare Programm sind identisch). Hierbei handelt es sich um ein ausführbares Programm, welches sich standardmäßig in /usr/lib/nagios/plugins/ wiederfindet und eigenständig lauffähig (und aufrufbar in der Shell) ist.

Der Zusammenhang zwischen Hosts, Services und Commands veranschaulicht folgende Grafik:

Nagios - Zusammenhang Host, Hostgroup und Command
Klicken zum Vergrößern

An dieser Stelle wird auch der check_command Aufruf in der Service-Definition nachvollziehbar. Man übergibt zwei Argumente, welche in der Command-Definition per $ARG1$ und $ARG2$ angesprochen werden. -w steht in diesem Beispiel für den Schwellwert Warnung, -c für kritisch.

Ein Aufruf des NAGIOS-Webfrontends zeigt folgendes Ergebnis:

Nagios - Status Linux Webserver (HTTP)

Weiteres Beispiel: HTTP-Dienst prüfen

Zum besseren Verständnis ein weiteres Beispiel. Nun soll überprüft werden, ob auf einem entfernten System der HTTP-Dienst erreichbar ist. Hierzu finden wir das Programm check_http im Verzeichnis /usr/lib/nagios/plugins/. Damit man versteht, wie das Programm funktioniert, führt man es auf der Shell aus:

# ./check_http
check_http: Could not parse arguments
Usage: check_http -H <vhost> | -I <IP-address> [-u <uri>] [-p <port>]
[-w <warn time>] [-c <critical time>] [-t <timeout>] [-L]
[-a auth] [-f <ok | warn | critcal | follow | sticky | stickyport>]
[-e <expect>] [-s string] [-l] [-r <regex> | -R <case-insensitive regex>]
[-P string] [-m <min_pg_size>:<max_pg_size>] [-4|-6] [-N] [-M <age>]
[-A string] [-k string] [-S] [-C <age>] [-T <content-type>] [-j method]

bck-gentoo-msi02 plugins # ./check_http -I 212.68.X.X
HTTP OK: HTTP/1.1 200 OK - 6699 bytes in 0.090 second response time |time=0.090162s;;;0.000000 size=6699B

check_http ist relativ einfach, da man keine umfangreichen Informationen angeben muss. Dieses Wissen setzen wir nun ein, um ein Command zu definieren:

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

Der command_name ist der eindeutige Name des Befehls/Command. Hierüber wird die Command-Definition angesprochen. command_line definiert nun die genaue Syntax:

$USER1$ = Variable für das Verzeichnis /usr/lib/nagios/plugins/
check_http = Programm in /usr/lib/nagios/plugins/
-I $HOSTADDRESS$ = Option, $HOSTADDRESS$ ist eine Nagios-Systemvariable für den Hostnamen des Aufrufers
$ARG1$ = 1. Argument

Nach Fertigstellung des Commands kann die Schnittstelle zwischen Host und Command erstellt werden, nämlich der Service. Dieses Mal verzichten wir auf das Template und definieren den Service komplett eigenständig:

define service {
service_description HTTP ; Name des Service
hostgroup_name http Server Gruppe ; Prüfe alle Clients dieser Hostgroup
check_command check_http ; Definition des Befehl ; Definition des Befehlss
normal_check_interval 5 ; Prüfintervall, Status OK (alle 5)
retry_check_interval 1 ; Prüfenintervall, Status Fehler (jede 1 Minute)
max_check_attempts 3 ; Setze Fehlerstatus nach 3 Versuchen
check_period 24x7 ; checke den ganzen Tag
notifications_enabled 1 ; aktive Service Benachrichtigungen
notification_interval 30 ; Alarmiere erneut nach 30 Minuten
notification_period 24x7 ; Alarmiere rund um die Uhr
notification_options w,u,c,r ; Alarmiere bei warning, unknown, critical, and recovery
contact_groups admins ; Alarmiere alle Mitglieder der Gruppe admins

active_checks_enabled 1 ; Aktive Checks sind enabled (1)
passive_checks_enabled 1 ; Passive Checks sind enabled (1)
}

Nach einem kurzen /etc/init.d/nagios reload werden nun die beiden Hosts darauf geprüft, ob der Webserver (HTTP) erreichbar ist.

Überwachung/Prüfung Linux Webserver

Weitere Artikel zu diesem Thema

Teil 1 - Nagios Grundlagen-Einführung für Anfänger und zentrale Konfiguration
Teil 2 - Nagios Anleitung: Netzwerk-Überwachung von Windows- und Linux-Clients
Teil 3 - Nagios Praxisbeispiele: Webserver (mysql, http, Systemauslaustung, Domains) überwachen
Teil 4 - Nagios Weboberfläche zur Statusüberprüfung und Anzeige des aktuellen Netzwerk-Zustands
Teil 5 -Nagios nützliche Links (Download, Community, Plugins, Anleitungen)