Open Source im professionellen Einsatz

Newsletter abonnieren
Seite durchsuchen

HEFTARCHIV | NEWS | E-BIBLIOTHEK | VIDEO | BLOGS | WHITEPAPER | EVENTS | ACADEMY | ABO | SHOP

user friendly

  Home  »  Heft & Abo  »  Heftarchiv  »  2004  »  01  »  Selbst ist der Admin  

RSS-Feed der aktuellen News von Linux-Magazin Online Folgen Sie Linux-Magazin Online auf Twitter
Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark

Monitoring: Server- und Netzüberlastungen mit Bordmitteln ermitteln

Selbst ist der Admin

von Charly Kühnast
Erschienen im Linux-Magazin 2004/01

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
Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark
Ähnliche Artikel
44 Servergebote Severdienste Apache, Postfix, Oracle/MySQL und Samba optimieren
Fit fürs elektronische Postamt LPIC-1-Vorbereitung - Teil 21: Mail Tranfer Agent
Agiler Urahn Konfigurationsverwaltung mit Cfengine2
Massenversand Workshop: Mailinglisten mit Mailman sicher betreiben
Holzauge, sei wachsam Nagios-Plugins im Eigenbau
Safer Mail QMail absichern
Whitepaper
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele

Über die letzten Jahre hinweg haben sich Open Source Lösungen als fester Bestandteil des gesamten Datenintegrationsmarktes etabliert. Viele Unternehmen haben bereits das Open Source Modell für Ihre Datenintegrationsprojekte aufgegriffen. Das vorliegende White Paper illustriert anhand ausgewählter Fallstudien und Anwendungsbeispiele die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.

Download PDF (Registrierung erforderlich)
The Role of Open Source in Data Integration

Obwohl in den letzten Jahren viele technische Fortschritte erzielt werden konnten, verfügen die meisten Datenintegrationsprozesse nach wie vor nur über eine sehr begrenzte Automatisierung. Das vorliegende White Paper von dem Industry Analyst Mark Madson wird zunächst ein grundlegendes Verständnis von Daten Integration vermitteln, die Vorzüge von Open Source Lösungen für Daten Integration erläutern und Ihnen professionelle Empfehlungen geben, damit Sie Ihre Integrationsjobs noch einfacher und produktiver gestalten können.

Download PDF (Registrierung erforderlich)
Kommentare (0)