Nagios installieren und konfigurieren: Unterschied zwischen den Versionen
Admin (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Admin (Diskussion | Beiträge) |
||
| Zeile 486: | Zeile 486: | ||
<code><pre> | <code><pre> | ||
apt-get install sudo | apt-get install sudo</pre></code> | ||
Dort fügt nun eine Zeile ein: | Dort fügt nun eine Zeile ein: | ||
Version vom 28. Oktober 2012, 02:35 Uhr
Vorwort
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.
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 0Die 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 eigen 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
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
|
Bei Fragen zu den Anleitungen wendet Euch bitte an mein Forum unter http://www.gargi.org. Die Anmeldung und Nutzung des Forums ist kostenlos. |
<metakeywords>Nagios,Installieren,Konfigurieren,Linux,NSLU2,Monitoring</metakeywords>