Open Source im professionellen Einsatz

Monitoring: Server- und Netzüberlastungen mit Bordmitteln ermitteln

Selbst ist der Admin

Charly Kühnast

Fällt ein Server aus, sollten nicht die User, sondern Tools dem Admin das mitteilen. Besser wäre, wenn er schon die Frühformen abnormen Serververhaltens erkennt. Das vorgestellte Toolset überwacht Server und Dienste und fertigt Lastanalysen an. Anders als fertige Lösungen sind die gezeigten Skripte sehr flexibel.

Wer Daten über den Zustand seines Netzes und der Server sammelt und übersichtlich darstellt wird Engpässe und Überlastungen schnell und ohne manuelles Durchforsten von Logfiles diagnostizieren können. Für dieses Monitoring gibt es eine ganze Reihe guter und nützlicher Werkzeuge. Erst kürzlich hat das Linux-Magazin Nagios und Big Sister vorgestellt[1],[2].

Dieser Beitrag handelt aber davon, wie man diese Werkzeuge nicht benutzt, sondern stattdessen Bordmittel, die zu einem guten Teil jede Linux-Distribution mitbringt. Dazu kommen ein paar einfache, aber trickreiche Bash-Skripte. Das gewährleistet, dass jeder Admin das Vorgehen gut nachvollziehen kann. Somit - und hier liegt der Vorteil gegenüber den großen Netzmanagement-Tools - kann jeder den hier vorgestellten Werkzeugkasten an seine IT-Landschaft und deren Applikationen individuell anpassen. Weitere Vorteile:

Auch exotische Auswertungen sind möglich.
Es entstehen nicht nur die Ergebnisse, sondern auch die
Rohdaten, die man verschiedenen auswerten kann.

n Hoher Lerneffekt für den Admin.

Skripte haben für Linux/Unix-Enthusiasten ungleich mehr
Charme als fertige Binaries.

Die Nachteile sollen aber auch nicht verschwiegen werden:

Bis zur Einsatzreife vergeht mehr Zeit als bei einer fertigen
Lösung.
Weniger Features.
Wenn sich die Toolsammlung bewährt, hat deren
Programmierer für den Rest seines Daseins die Programmpflege
am Bein.

Livecheck: Antworten die Server und ihre Dienste?

Das Wichtigste zuerst: Der Admin muss schauen, ob alle Server laufen und die Dienste, die auf ihnen laufen sollen, auch verfügbar sind. Dabei wird ihm das kleine Bash-Skript »simple_livecheck.sh« helfen - aber zuvor muss er noch einige Verzeichnisse und Dateien anlegen: Das Arbeitsverzeichnis ist »/usr/local/shellscripts/livecheck«. Darunter gibt es das Unterverzeichnis »etc«, in dem er mit dem Editor seiner Wahl für jeden Server eine Datei anlegt.

Ihr Name folgt zwingend dem Muster » IP-Adresse_Name.SLD.TLD«, im Falle des hier vorgestellten Beispiels lautet er »10.0.0.2_funghi.gondor.de«. In die Datei schreibt der Admin untereinander jene Ports, die im normalem Betriebszuständen aktiv sein sollen:

25
80
110

Für die anderen zu überwachenden Server legt man analog weitere Dateien an, im Beispiel »10.0.0.12_inn.gondor.de«, deren Inhalt nur aus der Portnummer 119 besteht.

Nmap leistet gute Dienste

Im Skript läuft eine Schleife über die Dateien, die per Ping checkt, ob die Server überhaupt antworten. Ist das der Fall - was jeder Admin schwer hofft -, überprüft das Skript die einzelnen Ports per Nmap[3], hier in der Version 3.00. Achtung, Suse Linux 9.0 hat einen nervigen Bug: Nmap funktioniert aus bislang ungeklärter Ursache nicht mit Root-Rechten. Listing 1 zeigt das Bash-Skript. (In Perl wären einige Details eleganter zu lösen - Snapshot-Autor Michael Schilli wird den Kopf oder gar den Autor dieses Beitrags schütteln.) Der Beispielserver fördert folgende Meldung zu Tage:

Server 10.0.0.2 (funghi.gondor.de): ping OK
10.0.0.2: Port 25 is up
10.0.0.2: Port 80 is up
10.0.0.2: Port 110 is up

Die Gegenprobe nach manuellem Stoppen des Apache befriedigt:

Server 10.0.0.2 (funghi.gondor.de): ping OK
10.0.0.2: Port 25 is up
10.0.0.2: Port 80 is down
10.0.0.2: Port 110 is up

So soll es sein! Aber selbst dem letzten Frischlings-Admin ist klar, dass ein Konsolen-Echo eine suboptimale Form der Alarmierung ist. Besser wäre es, erstens auf die Echos zu verzichten und stattdessen einen Eintrag ins Syslog zu schreiben, denn das Skript wird im wahren Leben nicht von Hand, sondern als Cronjob ausgeführt. Zweitens wäre eine Benachrichtigung per Mail, SMS oder Cityruf praktisch[4].

Listing 1: »simple_livecheck.sh«
01 #! /bin/bash 02 03 # Das Skript prüft, ob Server lebt und 04 # seine Dienste verfügbar sind 05 06 WDIR=/usr/local/shellscripts/lm-livecheck 07 08 for i in `ls $WDIR/etc/`; do 09 10 ## extract IP and fqdn from file name 11 IP=`echo $i\|cut -f1 -d"_"`; 12 NAME=`echo $i\|cut -f2 -d"_"`; 13 14 ## ping host to see if it's up 15 PING=$(/bin/ping -c2 -q -w2 $IP\|grep transmitted\|cut -f3 -d","\|cut -f1 -d","\|cut -f 1 -d"%") 16 if [ $PING -eq " 0" ]; then 17 ## Host is up 18 echo "Server $IP ($NAME): ping OK"; 19 20 ## now checking the ports 21 for j in `cat $WDIR/etc/$i`; do 22 23 RET=`/usr/bin/nmap -r --host_timeout 2500 --initial_rtt_timeout 2000 -p $j $IP\|grep $j/tcp\|cut -f1 -d"/"`; 24 25 if [ -z $RET ]; then 26 echo "$IP: Port $j is down"; 27 ## Alarm: Port down ## 28 else 29 echo "$IP: Port $j is up"; 30 fi 31 done 32 33 else 34 echo "Server $IP ($NAME): no response"; 35 fi 36 done

Listing 1:
»simple_livecheck.sh«

01 #! /bin/bash
02 
03 # Das Skript prüft, ob Server lebt und
04 # seine Dienste verfügbar sind
05 
06 WDIR=/usr/local/shellscripts/lm-livecheck
07 
08 for i in `ls $WDIR/etc/`; do
09 
10   ## extract IP and fqdn from file name
11   IP=`echo $i|cut -f1 -d"_"`;
12   NAME=`echo $i|cut -f2 -d"_"`;
13 
14   ## ping host to see if it's up
15   PING=$(/bin/ping -c2 -q -w2 $IP|grep transmitted|cut -f3 -d","|cut -f1 -d","|cut -f 1 -d"%")
16   if [ $PING -eq " 0" ]; then
17     ## Host is up
18     echo "Server $IP ($NAME): ping OK";
19 
20     ## now checking the ports
21     for j in `cat $WDIR/etc/$i`; do
22 
23       RET=`/usr/bin/nmap -r --host_timeout 2500 --initial_rtt_timeout 2000 -p $j $IP|grep $j/tcp|cut -f1 -d"/"`;
24 
25       if [ -z $RET ]; then
26         echo "$IP: Port $j is down";
27         ## Alarm: Port down ##
28       else
29         echo "$IP: Port $j is up";
30       fi
31     done
32 
33   else
34     echo "Server $IP ($NAME): no response";
35   fi
36 done