Nagios installieren und konfigurieren

Vorwort

Alles im Griff

Vertrauen ist gut, Kontrolle ist besser ... ein Spruch, der sich gerade was Server betrifft sich immer wieder bewahrheitet. Deswegen ist ein ordentliches Servermonitoring das A und O wenn es darum geht, die darauf laufenden Dienste auch immer im Auge zu behalten und schnell einzuschreiten, wenn es einmal wo kracht. Oder noch besser: Wenn es sogar automatisch wieder ans Laufen gebracht wird und unser Eingreifen nur noch dann gefordert ist, wenn es nicht mehr anders geht.

Um Server zu Überwachen gibt es sicherlich teure Lösungen. Aber wir wollen uns einmal daran halten, was uns die Opensource Welt an Softwaregeschenken macht. Das führt mich zu Nagios Core 3, eine freie Servermonitoring Software, die weit verbreitet ist und zu der es eine Vielzahl an Erweiterungen mittlerweile gibt, die einem das Leben noch leichter machen.

Mich hat es zudem interessiert, ob wir auf unserer NSLU2 auch die Chance haben, derartige Software zum Laufen zu bringen.

Nagios auf der NSLU2 in Äktsch'n:

Dazu habe ich erstmal ein aktuelles Debian (Debian 6 Squeeze) für die ARML Plattform installiert (eine Anleitung dazu findet Ihr hier, doch macht hier nur die Basisinstallation und keine weiteren Dienste! http://myslug.de/index.php?title=Debian_6_auf_der_NSLU2

Wenn Ihr ein Basissystem installiert habt, kann es schonmal los gehen. Wir installieren zuerst ein Standard Nagios über den apt:

Nagios installieren

Um das System auf einem Debian Lenny zu installieren kann der Apt Paketmanager relativ einfach verwendet werden. Auf einem einfachen Basissystem setzt hierzu ein

apt-get install nagios3 nagios-plugins

ab. Die folgenden beiden Abfragen beantwortet einfach mit den jeweiligen Standardvorgaben:





Ansonsten dürfte das Standardsystem damit installiert sein. Der vorgegebene User innerhalb der Standardkonfiguration lautet nagiosadmin.

Ihr werdet dann noch nach einem Admin Passwort gefragt, das via htaccess den Zugriff steuert.

Ihr könnt nun Nagios mit einem Browser unter

http://IP_ODER_DEINE_DOMAINE/nagios3

aufrufen.

Solltet Ihr irgendwelche Konfigurationsdateien von Nagios ändern, dann vergesst nicht, nagios mittels

/etc/init.d/nagios3 reload

neu zu starten.

Erste Änderung nach der Installation von Nagios

Ändern des Homeverzeichnis in der /etc/passwd:

nano /etc/passwd

Suchen nach folgender Zeile:

nagios:x:104:106::/var/run/nagios3:/bin/false

Danach diese in

nagios:x:104:106::/home/nagios:/bin/bash

ändern, bzw. besser alte Zeile auskommentieren und diese neu anlegen. Dadurch wird auch für das Erste ein su auf den User nagios ermöglicht, was wir später für die Erzeugung eines privaten und öffentlichen Schlüssels benötigen.

Nun legen wir das neue Homeverzeichnis an:

mkdir /home/nagios

Die korrekten Nutzerrechte:

chown -R nagios:nagios /home/nagios

Erstes Monitoring

Im Netzwerk befindet sich der Server 192.168.0.2 der Server1 heißen soll. Diesen müssen wir erstmal Nagios bekannt machen. Dazu legen wir im /etc/nagios3/conf.d/ eine neue Konfiguration fest:

touch /etc/nagios3/conf.d/server1_nagios2.cfg

Diese editieren wir und füllen die Datei wie folgt:

define host{
        use                     generic-host
        host_name           Server1
        alias                    Server1
        address                 192.168.0.2
        }

Diese Datei wird Dreh- und Angelpunkt für unser Monitoring werden. Aber wir bekommen so erstmal noch nichts zu sehen. Also machen wir einfach mal die Datei /etc/nagios3/conf.d/hostgroups_nagios2.cfg auf. Dort schauen wir uns einmal den folgenden Abschnitt an:

# A list of your web servers
define hostgroup {
        hostgroup_name  http-servers
                alias           HTTP servers
                members         localhost
        }

Hier ist bereits schon der Monitoringdienst für Webserver vordefiniert. Wenn wir immer wieder die gleichen Dienste für verschiedene Server haben, können wir diese Dienst als eine Gruppe auch hier hinterlegen. Das macht Sinn, wenn es besonders viele Server sind. In unserem Fall wollen wir, dass unser Server auch ein Mitglied der http-server wird und damit ein Monitoring auf den http gemacht wird. Ändert dafür den Abschnitt wie folgt ab:

# A list of your web servers
define hostgroup {
        hostgroup_name  http-servers
                alias           HTTP servers
                members         localhost,Server1
        }

Gleiches kann dann auch für die ssh Gruppe usw. gemacht werden. Hierzu müsst Ihr Euch einfach zunächst die fordefinierten Gruppen in dieser Konfigurationsdatei ansehen. Wenn Ihr Eure Änderungen vorgenommen und alles gespeichert habt, müsst Ihr den Nagios wieder neu starten:

/etc/init.d/nagios3 reload

Jetzt sollte Euer Server mit den ersten Diensten im Monitoring sein.

Weitere Dienste einrichten

Im Folgenden werden wir ein paar weitere Dienste einrichten. Diese Dienste werden erstmal recht einfach sein, da sie nicht lokal auf dem Zielrechner ausgeführt werden müssen. Hier bietet sich erstmal der FTP Dienst an.

Jetzt möchten wir erstmal wissen, wie dieser Check genau aussieht und ob dieser bereits definiert ist. Hierzu spitzen wir einfach einmal in das /etc/nagios-plugins/config Verzeichnis. Dort finden wir eine ftp.cfg Datei, die wir zunächst uns einmal näher ansehen:

# 'check_ftp' command definition
define command{
        command_name    check_ftp
        command_line    /usr/lib/nagios/plugins/check_ftp -H '$HOSTADDRESS$'
        }

####
# use these checks, if you want to test IPv4 connectivity on IPv6 enabled syste$
####

# 'check_ftp_4' command definition
define command{
        command_name    check_ftp_4
        command_line    /usr/lib/nagios/plugins/check_ftp -H '$HOSTADDRESS$' -4
        }

Der erstere Aufruf ist für uns interessant. Hier sehen wir, dass das Check Kommando check_ftp heißt.

Jetzt rufen wir wieder unsere /etc/nagios3/conf.d/server1_nagios2.cfg auf. Dort bauen wir folgenden Abschnitt unter unserer Hostdefinition ein:

define service {
        host_name                       Server1
        service_description             FTP
        check_command                   check_ftp
        use                             generic-service
        notification_interval           0 
}

Speichert die Änderung und startet den Nagios neu:

/etc/init.d/nagios3 restart

Schaut Euch im Plugins Verzeichnis ein wenig um, dort findet Ihr sicherlich schnell in den Konfigurationsdateien einen Hinweis darauf, welchen Dienst Ihr bereits einfach einbauen könnt.

Allerdings geht nicht jedes Plugin direkt vom Nagios Server aus, sondern muss auf dem Zielserver teilweise remote ausgeführt werden. Das ist ein wenig tricky, aber das schauen wir uns dennoch gleich einmal an.

Externe Kommandos aktivieren

Um später externe Kommandos abzusetzen muss noch etwas gedreht werden.

Zuerst mittels einem Editor die Zeile check_external_commands=1 in der /etc/nagios3/nagios.cfg setzen.

Folgende Befehle dann an der Konsole absetzen:

/etc/init.d/nagios3 stop
dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 start

Plugin Remote ausführen

Jetzt wird es deutlich kniffeliger, da wir nun einen Check auf den Zielrechner direkt durchführen wollen. Einige Plugins müssen auch entsprechend auf dem Zielrechner gestartet werden, da wir eine Information über den Festplattenstatus, den Serverload etc. nur vom jeweilgen Server direkt geliefert bekommen können.

Dafür müssen wir unseren Zielrechner erstmal einwenig vorbereiten. Die folgenden Schritte werden somit alle erstmal auf dem Zielserver durchgeführt:

a) Nutzer und Gruppe Nagios erzeugen:

groupadd -g 9001 nagios
useradd -u 9001 -g nagios -d /home/nagios -m -c "Nagios Monitoring" nagios

b) Nutzerverzeichnisrechte anpassen:

chown -R nagios:nagios /home/nagios

c) Neues Verzeichnis anlegen:

su nagios
mkdir /home/nagios/.ssh
exit

d) Plugins installieren:

apt-get install nagios-plugins

Das wars dann soweit auf dem Zielrechner. Den Rest machen wir wieder vom Nagios Rechner aus:

Schlüssel erzeugen:

su nagios
cd /home/nagios/.ssh
ssh-keygen -b 1024 -f id_dsa -t dsa -N ''

Das hat zum einen den Schlüssel erzeugt. Damit Nagios auch den Zielrechner als "known-hosts" einträgt, loggt Euch einfach kurz in den Zielrechner ein:

ssh 192.168.0.2

Ihr werdet aufgefordert, den Fingerprint des Zielrechner zu speichern.

Jetzt verlasst wieder den Zielrechner:

exit

Danach den Nutzer nagios:

exit

Wir schieben nun unseren Schlüssel auf den Zielrechner:

scp /home/nagios/.ssh/id_dsa.pub 192.168.0.2:/home/nagios/.ssh/authorized_keys

Jetzt nochmal kurz auf unserem Zielrechner die Rechte angepasst:

chown -R nagios:nagios /home/nagios/.ssh
chmod 700 /home/nagios/.ssh

Das waren soweit erstmal die Vorbereitungen. Wir testen gleich einmal, ob alles klappt. Gebt hierzu auf dem Nagiosrechner folgendes ein:

su nagios
/usr/lib/nagios/plugins/check_by_ssh -H 192.168.0.2 -i /home/nagios/.ssh/id_dsa -C "/usr/lib/nagios/plugins/check_users -w 10 -c 20"

Das sollte Euch nun anzeigen, wieviele User auf dem Zielrechner eingeloggt sind. Ihr dürft an der Stelle nicht mehr nach irgendeinem Passwort gefragt werden. Sollte das dennoch der Fall sein, dann überprüft bitte Eure Installation.

Ihr habt gesehen, dass wir auf dem Nagios Server einen check_by_ssh ausführen und auf dem Zielrechner das entsprechende tatsächliche Plugin. So gestalten wir auch in Zukunft den Aufbau von einem Remote Check. Dies muss aber bevor wir den als normalen Dienst integrieren entsprechend definiert werden. Wir schauen uns dazu wieder das Verzeichnis /etc/nagios-plugins/config an. Dort sehen wir eine load.cfg. Diese Datei öffnen wir einfach mal und sehen uns an, was bereits dort definiert ist:

# 'check_load' command definition
define command{
        command_name    check_load
        command_line    /usr/lib/nagios/plugins/check_load --warning='$ARG1$,$ARG2$,$ARG3$' --critical='$ARG4$,$ARG5$,$ARG6$'
        }

Diese definition ist für einen lokalen Check ausgelegt. Wir fügen nun folgende Zeilen darunter ein:

# 'ssh_check_load' command definition
define command{
        command_name    ssh_check_load
        command_line    /usr/lib/nagios/plugins/check_by_ssh -H '$HOSTADDRESS$' -i /home/nagios/.ssh/id_dsa  //
                             -C "/usr/lib/nagios/plugins/check_load --warning=$ARG1$,$ARG2$,$ARG3$ --critical=$ARG4$,$ARG5$,$ARG6$"
        }

Bitte achtet im Script auf den Hinweis //Zeilenumbruch. Diesen bitte entfernen und die darunterliegende Zeile mit der oberen wieder zusammenfügen, sonst produziert das Skript Fehler!

Ihr seht, dass wir ein neues Kommando gebaut haben, das auf den Aufruf ssh_check_load hört. Wir übernemen im Grunde die alte Kommandozeile und erweitern die um den check_by_ssh Aufruf. Diese Erweiterung ist dann auch für alle anderen Plugins gleich. Die alte Zeile wird dann in Hochkommas " " gefasst und bei den Argumenten $ARGS$ die einfachen Hochkommas ' ' weggelassen. Das ist wichtig, da sonst der Auffruf nicht funktioniert! Auch wenn später innerhalb des Remotebefehls das $HOSTADDRESS$ rein muss, müssen wir die einfachen Hochkommas weglassen!

Wir speichern die Änderung und bauen nun den Check in unsere /etc/nagios3/conf.d/server1_nagios2.cfg ein:

define service{
        use                             generic-service 
        host_name                       Server1
        service_description             Current Load
        check_command                   ssh_check_load!5.0!4.0!3.0!10.0!6.0!4.0
}

Hinter unserem ssh_check_load Kommando werden dann die entsprechenden Argumente gesetzt ( $ARGS1$ ... ) und mit Ausrufezeichen getrennt.

Das war's dann auch schon. Startet Nagios neu:

/etc/init.d/nagios3 reload

Templates ändern

Sämtliche Überwachungsoptionen (Checkintervall, wer soll verständigt werden etc.) können natürlich innerhalb der Service eingegeben werden. Das macht allerdings die Konfigurationsdateien auf Dauer ziemlich unübersichtlich. Von daher können auch Templates definiert werden, die dann über das use Kommando eingebunden werden. Hier einmal das Standard Template aus der /etc/nagios3/conf.d/generic-service_nagios2.cfg :

define service{
        name                            generic-service ; The 'name' of this service template
        active_checks_enabled           1       ; Active service checks are enabled
        passive_checks_enabled          1       ; Passive service checks are enabled/accepted
        parallelize_check               1       ; Active service checks should be parallelized (disabling this can lead to major performance problems)
        obsess_over_service             1       ; We should obsess over this service (if necessary)
        check_freshness                 0       ; Default is to NOT check service 'freshness'
        notifications_enabled           1       ; Service notifications are enabled
        event_handler_enabled           1       ; Service event handler is enabled
        flap_detection_enabled          1       ; Flap detection is enabled
        failure_prediction_enabled      1       ; Failure prediction is enabled
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
                notification_interval           0               ; Only send notifications on status change by default.
                is_volatile                     0
                check_period                    24x7 ;täglich rund um die Uhr wird geprüft
                normal_check_interval           5 ; alle 5 Minuten wird geprüft
                retry_check_interval            1 ; Bei Fehler wird in einer Minute nochmals geprüft
                max_check_attempts              4 ; 4 Fehlschläge bis Statusmeldung
                notification_period             24x7 ; täglich rund um die Uhr wird gemeldet
                notification_options            w,u,c,r ; Status Warning, Undefiniert, Critical, Recovered wird gemeldet
                contact_groups                  admins
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
        }

Ich habe mal fehlende Erklärungen ergänzt. Wenn Ihr ein neues Template anlegen wollt, dann kopiert diesen Abschnitt und ändert den Templatenamen. Dann könnt Ihr entsprechend weitere Änderungen vornehmen:

define service{
        name                            mein-service ; The 'name' of this service template
        active_checks_enabled           1       ; Active service checks are enabled
        passive_checks_enabled          1       ; Passive service checks are enabled/accepted
        parallelize_check               1       ; Active service checks should be parallelized (disabling this can lead to major performance problems)
        obsess_over_service             1       ; We should obsess over this service (if necessary)
        check_freshness                 0       ; Default is to NOT check service 'freshness'
        notifications_enabled           1       ; Service notifications are enabled
        event_handler_enabled           1       ; Service event handler is enabled
        flap_detection_enabled          1       ; Flap detection is enabled
        failure_prediction_enabled      1       ; Failure prediction is enabled
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
                notification_interval           0               ; Only send notifications on status change by default.
                is_volatile                     0
                check_period                    24x7
                normal_check_interval           5
                retry_check_interval            1
                max_check_attempts              3
                notification_period             24x7
                notification_options            w,u,c,r
                contact_groups                  admins,techniker
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
        }

Jetzt könnt Ihr bei den Services entsprechend die Änderungen dort vornehmen, wo es auch geändert werden soll:

define service {
        host_name                       Server1
        service_description             SSH
        check_command                   check_ssh
        use                             mein-service
}

Nach Änderung müsst Ihr Nagios neu laden:

/etc/init.d/nagios3 reload

Diese Templateänderung gilt nur für die Services! Wenn Ihr das Template (generic-host) innerhalb Eurer host - Definition ändern wollt, dann geht analog in der Datei /etc/nagios3/conf.d/generic-host_nagios2.cfg . Kommt nur nicht auf die Idee, ein Service Template innerhalb des host-Abschnitts zu verwenden! Da sollen sich schon Leute fummelig nach den Fehlern gesucht haben

Benachrichtigungen versenden

Das beste Monitoring nützt natürlich nichts, wenn wir nicht über einen Ausfall verständigt werden. Nagios kann das sowohl per Mail als auch per SMS. Der SMS Weg setzt natürlich noch zusätzliche Hardware (ISDN etc.) voraus, weshalb wir uns in unserem Tutorial nur auf die klassische E-Mail beschränken.

Damit aber überhaupt eine Mail von unserer Slug versendet werden kann müssen wir ersteinmal einen Mail Transporter definieren. Aufmerksame Leser meiner Seite kennen eventuell die Vorgehensweise, aber ich liste die notwendigen Schritte dazu gerne nochmal auf.

Die heutigen Debianserver haben als Standard MTA den exim4 hinterlegt. Solltet Ihr eigentlich keinen Mailserver aktiviert haben, könnt Ihr aber dennoch den exim4 dazu verwenden, via eines sogenannten Smarthosts (= externer Mailserver) Eure Nagios Mails verschicken zu lassen.

Um einen Smarthost einzurichten startet die Konfiguration mit einem

dpkg-reconfigure exim4-config

Folgende Konfigurationsschritte:

1.) Versand über Sendezentrale (Smarthost); Empfang mit SMTP oder Fetchmail

2.) Email Name des Systems: Lasst einfach den voreingestellten Domänen Name stehen

3.) IP-Adressen, auf denen eingehende SMTP-Verbindungen erwartet werden: 127.0.0.1

4.) Weitere Ziele, für die die E-Mails angenommen werden sollen: Auch hier den default Domän Namen stehen lassen

5.) Rechner für die die E-Mails weitergeleitet werden sollen (Relay): Leer lassen, wenn nicht ein weiterer Rechner DIESEN Rechner als Smarthost verwendet. Also normal leer lassen.

6.) IP Adresse oder Rechnername der Sendezentrale für ausgehende E-Mails: Hier und genau hier kommt die IP Adresse oder der Rechnername (mail/smtp.xyz) Eures ISP rein!

7.) Lokalen E-Mail Namen in ausgehende Mails verbergen: Ja

8.) Sichtbarer Domänennamen für lokalen Benutzer: Hier gebt eine Adresse ein, die Ihr besitzt (in der Form meinepage.de)

9.) DNS Anfrage minimieren: Ja

10.) Versandart bei lokaler Mailzustellung: Mbox Format in /var/mail/

11.) Einstellungen auf kleine Dateien aufteilen: Nein

Danach startet der MTA neu. Jetzt kann es auch sein, dass Euer Smarthost eine Authentifizierung abverlangt. Diese hinterlegt in der folgenden Datei: /etc/exim4/passwd.client

Hier das Passwort wie folgt hinterlegen:

IP_des_Mailserver_oder_Name:LOGIN:PASSWORT

Die Datei sollte nur lesbar für root sein.

Startet danach den MTA neu:

/etc/init.d/exim4 restart

Soweit so gut. Legt nun einen neuen Kontakt in der Datei /etc/nagios3/conf.d/contacts_nagios2.cfg an. Kopiert einfach dazu den root User Abschnitt und ändert diesen entsprechend Eurer Daten ab:

define contact{
        contact_name                    mein_name
        alias                           Mein_name
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-service-by-email
        host_notification_commands      notify-host-by-email
        email                           meine@adresse.mail
        }

Wenn der neue Kontakt definiert ist, fügt diesen dann in den Abschnitt Contact Groups der gleichen Datei mit ein:

define contactgroup{
        contactgroup_name       admins
        alias                   Nagios Administrators
        members                 root,mein_name        
        }

Da der Kontakt root ein "Dummy" ist, könnt Ihr den auch gleich aus der Zeile members löschen.

Wie immer dann den Nagios neu laden:

/etc/init.d/nagios3 reload

Um jetzt zu testen, dass alles klappt, schießt einfach einen Dienst auf Euren Zielserver ab und wartet, bis Ihr eine Mail bekommt. Das dürfte nicht lange dauern

Toter Mysql:

***** Nagios *****

Notification Type: PROBLEM

Service: MYSQL
Host: Server1
Address: 192.168.0.2
State: CRITICAL

Date/Time: Fri Aug 28 20:09:54 CEST 2009

Additional Info:

Cant connect to local MySQL server through socket /var/run/mysqld/mysqld.sock (2)

MYSQL testen

Eine Spezialität ist das Checken des MYSQL Servers. Das wollen wir auch über einen Remote Zugriff erledigen. Dazu müssen wir aber auf dem Zielrechner eine Datenbank für Nagios und den User Nagios anlegen, der aber nur lesend auf seine Datenbank zugreifen kann. Uns genügt es zu wissen, ob die DB läuft. Also meldet Euch bitte auf Eurem Zielrechner an der mysql Datenbank an:

mysql -u root -p

Nun erzeugen wir eine Datenbank und einen Nutzer

CREATE DATABASE nagiosdb;
GRANT select ON nagiosdb.* TO nagios@localhost;
exit

Nun wenden wir uns dem Nagios Server zu. Dort öffnet die Datei /etc/nagios-plugins/config/mysql.cfg und fügt folgende Zeilen ein:

# 'ssh_check_mysql' command definition
define command{
        command_name    ssh_check_mysql
        command_line      /usr/lib/nagios/plugins/check_by_ssh -H '$HOSTADDRESS$' -i /home/nagios/.ssh/id_dsa // 
           -C "/usr/lib/nagios/plugins/check_mysql -H localhost -u nagios"
}

Bitte achtet im Script auf den Hinweis //Zeilenumbruch. Diesen bitte entfernen und die darunterliegende Zeile mit der oberen wieder zusammenfügen, sonst produziert das Skript Fehler!

Die /etc/nagios3/conf.d/server1_nagios2.cfg wird wie folgt ergänzt:

define service {
        host_name                       Server1
        service_description             MYSQL
        check_command                   ssh_check_mysql
        use                             generic-service
}

Danach nagios neu laden:

/etc/init.d/nagios3 reload

Spezialfall Mail Queues

Um die Mailqueues zu prüfen benötigt man normalerweise Rootrechte. Wie wir wissen werden aber alle Checks nur als User nagios durchgeführt. Um nun remote einen Test durchzuführen, der beispielsweise den Mail Queues eines Exim4 prüft, müssen wir einen neuen Dienst definieren, der folgendes Kommando absetzt:

/usr/lib/nagios/plugins/check_by_ssh -H 192.168.0.2 -i /home/nagios/.ssh/id_dsa -C "/usr/lib/nagios/plugins/check_mailq -w 40 -c 70 -M exim"

Rootrechte hätte man, wenn der Befehl wie folgt aussieht:

/usr/lib/nagios/plugins/check_by_ssh -H 192.168.0.2 -i /home/nagios/.ssh/id_dsa -C "sudo /usr/lib/nagios/plugins/check_mailq -w 40 -c 70 -M exim"

Nur nützt uns das wiederum nichts, weil wir hier ein Passwort für Root eingeben müssten.

Um das zu umgehen legen wir auf dem Zielrechner nun fest, dass genau dieser Befehl /usr/lib/nagios/plugins/check_mailq vom User nagios mit Rootrechte ausgeführt werden darf. Das setzt auf dem Zielrechner als root folgenden Befehl ab:

visudo

Sollte dieser nicht funktionieren muss noch sudo installiert werden:

apt-get install sudo

Dort fügt nun eine Zeile ein:

nagios ALL=(root) NOPASSWD: /usr/lib/nagios/plugins/check_mailq

Speichert die Änderung. Jetzt definiert unter /etc/nagios-plugins/config/mail.cfg ein neues Kommando:

# 'ssh_check-mailq' for exim
define command {
        command_name    ssh_check_mailq_exim
        command_line    /usr/lib/nagios/plugins/check_by_ssh -H '$HOSTADDRESS$' -i /home/nagios/.ssh/id_dsa // 
                -C "sudo /usr/lib/nagios/plugins/check_mailq -w $ARG1$ -c $ARG2$ -M exim"
}

Bitte achtet im Script auf den Hinweis //Zeilenumbruch. Diesen bitte entfernen und die darunterliegende Zeile mit der oberen wieder zusammenfügen, sonst produziert das Skript Fehler!

Danach wie gehabt den Service für Euren Host anlegen:

define service {
        host_name                       Server1
        service_description             Mail-Queues
        check_command                   ssh_check_mailq_exim!25!50
        use                             generic-service
}

Die Argumente ( 25 = Warning , 50 = Critical ) können natürlich entsprechend angepasst werden.

Und nun wie gewohnt:

/etc/init.d/nagios3 reload

Der Event Handler

Nun wollen wir alles einwenig automatisieren. Also wenn ein Dienst ausfällt soll uns Nagios versuchen, diesen wieder auszuführen und ans Laufen zu bringen. Hierzu fügen wir als erstes eine neue Zeile in die Datei /etc/nagios3/resource.cfg ein:

$USER2$=/usr/share/nagios3/plugins/eventhandlers

In diesem Verzeichnis liegen dann alle unsere Startscripte.

Nun müssen wir uns ein Startscript für den Neustart eines Apache Webservers z.B. anlegen.

nano /usr/share/nagios3/plugins/eventhandlers/restart_apache

Füllt die Datei wie folgt:

#!/bin/bash
# $1 = Status $2 = Zustandstyp  $3 = Versuch $4 = Host

case $1 in
   OK)
      ;;
   WARNING)
      ;;
   CRITICAL)
      if [ $2 == "HARD" ] || [[ $2 == "SOFT" && $3 -eq 3 ]]; then
      ssh $4 -i /home/nagios/.ssh/id_dsa "sudo /etc/init.d/apache2 restart"
      fi
      ;;
   UNKNWON)
      ;;
esac
exit 0

Die Datei muss dann ausführbar gemacht werden:

chmod +x /usr/share/nagios3/plugins/eventhandlers/restart_apache

Nun legen wir uns eine neue Konfigurationsdatei für unsere Handler Kommandos an:

nano /etc/nagios3/conf.d/my-handlers_nagios2.cfg

Dort definieren wir nun unser neues Event:

define command{
     command_name    restart_apache
     command_line    $USER2$/restart_apache $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$ $HOSTADDRESS$
}

Die Änderung wird gespeichert und wir fügen in unserem Apache / http Dienst noch folgende Zeile mit ein:

define service {
        host_name                       Server1
        service_description             HTTP
        check_command                   check_http
        use                             generic-service
        event_handler               restart_apache
}

Natürlich haben wir hier wieder das Problem, dass auf dem Zielrechner dieser Prozess normal nicht von nagios ausgeführt werden kann. Deswegen müssen wir wieder in der /etc/sudoers eine Zeile einfügen. Diese Datei bitte nur über

visudo

auf dem Zielrechner editieren!

Fügt dann folgende Zeile ein:

nagios ALL=(root) NOPASSWD: /etc/init.d/apache2

Speichert die Änderung ab. Jetzt wieder auf dem Nagios Server ein

/etc/init.d/nagios3 reload

Killt jetzt zum Test auf Eurem Zielrechner den Apache mit

/etc/init.d/apache2 stop

Wartet ein wenig ab. Wenn alles richtig konfiguriert ist sollte in wenigen Minuten wieder der Apache laufen.

Externes Plugin integrieren oder selbst schreiben

Wer ein zusätzliches Plugin benötigt, der kann sich einmal auf http://exchange.nagios.org umsehen, ob es da nicht schon was passendes gibt. Ich habe das einmal für den Dienst Fail2Ban ausprobiert. Ein Plugin (ist in dem Fall ein Shell Script) findet Ihr beispielsweise hier: http://exchange.nagios.org/directory/Plugins/Security/Firewall-Software/Check-Fail2Ban-Service/details

Ladet nun die Datei check_fail2ban.sh herunter. Das Plugin muss auf dem Zielrechner ausgeführt werden. Also legt auf dem Zielrechner für eigene Plugins ein Verzeichnis /usr/local/share/nagios3/plugins an und kopiert das Script dort hin. Dann macht es noch ausführbar:

chmod +x /usr/local/share/nagios3/plugins/check_fail2ban.sh

Wer einmal eigene Plugins auf Scriptbasis schreiben möchte, kann sich dieses Script als Lernbeispiel ranziehen, dort sieht man recht schön, wie das in der Art funktioniert.

Da der im Script beinhaltete Befehl fail2ban-client ping nur als root ausgeführt werden kann, muss das noch in der /etc/sudoers festgelegt werden:

visudo

Folgende Zeile einbauen:

nagios ALL=(root) NOPASSWD: /usr/local/share/nagios3/plugins/check_fail2ban.sh

Jetzt können wir unser Check Kommando (remote) auf dem Nagiosserver definieren:

# 'ssh_check_fail2ban' command definition
define command{
        command_name    ssh_check_fail2ban
        command_line    /usr/lib/nagios/plugins/check_by_ssh -H '$HOSTADDRESS$' -i /home/nagios/.ssh/id_dsa // 
                 -C "sudo /usr/local/share/nagios3/plugins/check_fail2ban.sh"
        }

Bitte achtet im Script auf den Hinweis //Zeilenumbruch. Diesen bitte entfernen und die darunterliegende Zeile mit der oberen wieder zusammenfügen, sonst produziert das Skript Fehler!

Dann natürlich dieses als Dienst integrieren:

define service {
        host_name                       Server1
        service_description             Fail2ban
        check_command                   ssh_check_fail2ban
        use                             generic-service
}

Und was dann? Richtig! Nagios neu laden:

/etc/init.d/nagios3 reload

User Variable setzen

Natürlich könnt Ihr auch in der /etc/nagios3/ressource.cfg neue Variablen bauen. Um ein wenig Ordnung in die Konfiguration zu bringen solltet Ihr beispielsweise alle eigenen Scripte unter /usr/local anlegen. Dazu erstmal einen neuen Pfad:

mkdir /usr/local/share/nagios3
mkdir /usr/local/share/nagios3/eventhandlers

Dort kopiert nun Eure Eventhandler Scripte hin. Editiert die ressource.cfg und fügt eine neue Zeile ein:

$USER5$=/usr/local/share/nagios3/eventhandlers
Passt nun Euere Kommandozeilen entsprechend auf die neue Variable an (z.B.) :

<code><pre>
define command{
     command_name    restart_proftpd
     command_line    $USER5$/restart_proftpd $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$ $HOSTADDRESS$
}

Danach wieder nagios neu laden:

/etc/init.d/nagios3 reload

Remote Plugin Executor (NRPE)

Um auf einem Zielrechner diverse Dienste über Nagios zu beobachten kann man natürlich eine ssh Verbindung aufbauen und ein Plugin remote ausführen. Wesentlich eleganter geht das über den NRPE Dienst des Nagios. Dazu wird auf dem Zielrechner ein kleiner Dienst installiert, der auf einen bestimmten TCP Port horcht. Wenn dann unser Nagios Server einen Request auf einen externen Dienst absetzt tut er dies über den bestimmten Port (TCP 5666 per default). Dann führt NRPE das Plugin auf dem Zielrechner aus und liefert den Wert wieder an den Nagios Server zurück.

Wir erklären das anhand einer Debianinstallation. Das Prinzip bleibt zwar zumeist bei jeder Distribution gleich, kann aber in der Konfiguration voneinander abweichen.

Dazu muss natürlich ein Nagios Server im Netz vorhanden sein. Dieser findet sich beispielsweise auf 192.168.0.2

Jetzt installieren wir auf dem Nagios Server zunächst das NRPE Plugin, das später ausgeführt werden muss:

apt-get install nagios-nrpe-plugin

Nun schreiten wir auf unserem Zielrechner zu Tat und installieren folgende beiden Pakete:

apt-get install nagios-plugins nagios-nrpe-server

Auch das geht fluchs von der Hand.

Jetzt ändern wir noch eine kleine Sache an der /etc/nagios/nrpe.cfg

Dort sucht die Zeile

allowed_hosts=127.0.0.1

und ändert diesen durch die IP Eures Nagios Servers ab:

allowed_hosts=192.168.0.2

Das stellt sicher, dass dann unser Nagios Server sich an den Zielrechner andocken darf. Sollte dies vergessen werden gibt es eine Meldung später im Nagios, dass der SSH Handshake nicht funktioniert.

Ihr findet bereits ein paar fertig definierte Dienste. Diese könnt Ihr dann als Beispiel für weiter eigene definierte Dienste verwenden:

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_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1
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

Eine Festplatte könnt Ihr beispielsweise mittels deren UUID wie folgt prüfen:

command[check_home]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -x /dev/disk/by-uuid/12345-1234... -p /home

Der Parameter -x steht für das Device, das -p für den Mountpunkt.

Speichert nun die Änderung und vergesst nicht, den NRPE neu zu starten:

/etc/init.d/nagios-nrpe-server restart

Auf dem Nagios Server können dann die Dienste konfiguriert werden. Bei den Diensten können normalerweise Parameter übergeben werden. Beispielsweise wenn Ihr eine IP oder einen Wert an das Plugin übermitteln wollt, wird das ja bei der Dienstdefinition durch ein ! gelöst. Ihr müsst Hier bei dem NRPE Plugin allerdings eine Kleinigkeit beachten. Es wird zwischen zwei Pluginvarianten unterschieden: NRPE mit und ohne Parameter / Argument. Wenn Ihr also einen Check ohne Argument (beispielsweise bei den check_users) verwenden wollt, dann definiert den Dienst wie folgt:

define service{
        host_name                       MyServer
        service_description             Current Users
        check_command                   check_nrpe_1arg!check_users
        use                                generic-service
}

Der Aufruf also OHNE zusätzliche Parameter/Argumente werden somit mit dem Befehl check_nrpe_1arg gelöst. Das auszuführende Plugin wird dann mittels ! angehängt.

Sollte ein oder mehrere Parameter verwendet werden müssen, dann baut den Service wie folgt auf:

define service{
        host_name                       MyServer
        service_description             Current Users
        check_command                   check_nrpe!check_irgendwas!10 13 15
        use                                generic-service
}

Also hier der check_nrpe , das Plugin mit ! abgetrennt, die Parameter auch mit einem ! und weitere mit einem Leerzeichen abgetrennt. Das nrpe Plugin muss somit nicht extra konfiguriert werden, sondern das erledigt bereits der apt-get.

Wenn Ihr nun den Dienst fertig konfiguriert habt startet den Nagios Server neu:

/etc/init.d/nagios3 reload

Viel Spaß!

Euer
Pierre "Gargi" Kretschmer

Nagios: http://www.nagios.org
Debian: http://www.debian.org

Empfehlenswerte Literatur: Nagios: System- und Netzwerk-Monitoring http://www.amazon.de/Nagios-System-Netzwerk-Monitoring-Wolfgang-Barth/dp/3937514465