[...]

ð

Darüber hinaus ist das manuelle Hinzufügen von durch MRTG zu überwachenden Geräten möglich. Das folgende Beispiel weist MRTG an, mittels SNMP die CPU-Last abzufragen:

341

5.1

5

Optimierung und Monitoring

LoadMIBs: /usr/share/snmp/mibs/UCD-SNMP-MIB.txt Target[localhost.cpu]:ssCpuRawUser.0&ssCpuRawUser.0:public@ð localhost+ ssCpuRawSystem.0&ssCpuRawSystem. 0:public@localhost+ ssCpuRawNice.0&ssCpuRawNice.0:public@ð localhost+ ssCpuRawNice.0&ssCpuRawNice.0:publ ic@localhost RouterUptime[localhost.cpu]: public@localhost MaxBytes[localhost.cpu]: 100 Title[localhost.cpu]: CPU Load PageTop[localhost.cpu]:

Active CPU Load localhost %

Unscaled[localhost.cpu]: ymwd ShortLegend[localhost.cpu]: % YLegend[localhost.cpu]: CPU Utilization Legend1[localhost.cpu]: Active CPU in % (Load) Legend2[localhost.cpu]: Legend3[localhost.cpu]: Legend4[localhost.cpu]: LegendI[localhost.cpu]: Active LegendO[localhost.cpu]: Options[localhost.cpu]: growright,nopercent

Mit diesem Wissen können Sie jeden Wert per SNMP abfragen. Wichtig ist die Angabe der MIB über LoadMIBs. Die MIB ist Bestandteil des SNMP-Paketes (libsnmp-base). Um die von MRTG erzeugten Daten ansehnlich darzustellen, bringt MRTG das Tool indexmaker mit, mit dessen Hilfe Sie aus den Daten der Konfigurationsdatei eine Indexdatei im HTML-Format erzeugen können: # indexmaker /etc/mrtg/mrtg.cfg > /var/www/mrtg/index.html

Im Verzeichnis /var/www befindet sich nach dem Durchlauf die Datei index.html, die die Tagesansicht der bei der Ausführung von indexmaker angegebenen Messpunkte in der Konfigurationsdatei anzeigt. Über einen Klick auf die Grafik kommen Sie zur Detailansicht der Datenquelle. Unter Gentoo installieren Sie für MRTG die folgenden Pakete: # sudo emerge net-analyzer/net-snmp media-libs/gd net-analyzer/mrtg

Anschließend erstellen Sie aus der Beispiel-Konfigurationsdatei des SNMP-Dienstes eine »richtige« Konfigurationsdatei: # sudo cp /etc/snmp/snmpd.conf.example /etc/snmp/snmpd.conf

342

Monitoring

Abbildung 5.3

Die Indexdatei von MRTG

Abbildung 5.4

Detailansicht der Netzwerkschnittstelle eth0

343

5.1

5

Optimierung und Monitoring

In dieser Datei ändern Sie die Zeilen mit dem Schlüsselwort com2sec: com2sec local localhost com2sec local 192.168.0.0/24

michnix michnix

Damit legen Sie fest, dass über das lokale Loopback-Interface und über das Netzwerk 192.168.0.0/24 auf den SNMP-Dienst zugegriffen werden kann. Damit der SNMP-Dienst diese Datei auch verwendet, müssen Sie noch in der Datei /etc/ conf.d/snmpd die Flags des Dienstes entsprechend setzen: SNMPD_FLAGS="-C -c /etc/snmp/snmpd.conf"

Danach können Sie den Dienst neu starten und so einrichten, dass er beim Systemstart automatisch geladen wird: # sudo /etc/init.d/snmpd restart # sudo rc-update -a snmpd default * snmpd added to runlevel default

Mit snmpget oder snmpwalk können Sie sich davon überzeugen, dass der SNMPDienst läuft und erreichbar ist: # snmpwalk -v1 -c michnix localhost|more SNMPv2-MIB::sysDescr.0 = STRING: Linux gentoo 2.6.19-gentoo-r5 #1 SMP Wed Apr 4 05:44:43 U ð TC 2007 i686 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 ð DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (51165) 0:08:31.65 SNMPv2-MIB::sysContact.0 = STRING: root SNMPv2-MIB::sysName.0 = STRING: gentoo SNMPv2-MIB::sysLocation.0 = STRING: Footown SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00 SNMPv2-MIB::sysORID.1 = OID: ð SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance SNMPv2-MIB::sysORID.2 = OID: SNMP-MPD-MIB::snmpMPDCompliance SNMPv2-MIB::sysORID.3 = OID: ð SNMP-USER-BASED-SM-MIB::usmMIBCompliance SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB SNMPv2-MIB::sysORID.6 = OID: IP-MIB::ip [...]

Um MRTG zu konfigurieren, erstellen Sie sowohl das Verzeichnis /etc/mrtg, in dem die Konfigurationsdateien von MRTG abgelegt werden, als auch das Verzeichnis /var/www/localhost/htdocs/mrtg, wo MRTG die HTML-Seiten samt den dazugehörenden Grafiken ablegt:

344

Monitoring

# sudo mkdir /etc/mrtg # sudo mkdir /var/www/localhost/htdocs/mrtg

Die Konfigurationsdateien werden unter Gentoo analog zu denen unter Ubuntu erstellt, Gleiches gilt für den Cron-Job. Mit dieser Konfiguration haben Sie eine Darstellung des Netzwerkverkehrs, der über die primäre Schnittstelle Ihres Systems läuft. MRTG stellt den Verkehr getrennt nach eingehendem und ausgehendem Verkehr dar und zeigt vier verschiedene Graphen: 왘

eine Tagesübersicht, basierend auf den Werten, die alle fünf Minuten aus dem Cron-Job ermittelt werden,

왘

eine Wochenübersicht, basierend auf dem 30-Minuten-Durchschnitt der Messdaten,

왘

eine Monatsübersicht, basierend auf dem Zwei-Stunden-Durchschnitt der Messdaten, und

왘

eine Jahresübersicht, basierend auf dem Tagesdurchschnitt der Messdaten.

Die Übersichten über diese vier Zeiträume geben dem Administrator eine sehr gute Informationsquelle zur Tendenzentwicklung. Kurzfristige Lastspitzen und Performanceengpässe lassen sich aus der Tages- und Wochenübersicht ermitteln, die langfristige Entwicklung ergibt sich aus der Monats- und Jahresübersicht. Wenn sich ein System kurzfristig an Leistungsgrenzen bewegt – abzulesen in der Tagesübersicht –, kann das auf einmalige Ereignisse wie z. B. Marketingaktionen oder Angriffe zurückzuführen sein und muss kein Grund sein, das System aufzurüsten. Zeigt sich anhand der langfristigen Daten allerdings, dass ein System ständig unter Dampf steht, ist eine Aufrüstung angeraten. Das Layout der Indexseite können Sie über entsprechende Parameter des Programms indexmaker verändern: # indexmaker Usage: indexmaker [options] mrtg.cfg [other.cfg ...] [...]

Die auf der Detailseite angezeigten Werte werden über die Konfigurationsdatei /etc/mrtg/mrtg.cfg gesteuert. Deren Inhalt wird – sofern bei der Installation nicht automatisch geschehen – mit dem Befehl cfgmaker erzeugt: # sudo cfgmaker michnix@localhost > /etc/mrtg/mrtg.cfg

Die mit diesem Befehl erzeugte Datei ist ein gutes Beispiel für die Gestaltungsmöglichkeiten von MRTG:

345

5.1

5

Optimierung und Monitoring

WorkDir: /var/www/mrtg EnableIPv6: no Target[hardy.eth0]: #eth0:michnix@localhost: SetEnv[hardy.eth0]: MRTG_INT_IP="192.168.0.20" MRTG_INT_DESCR="eth0" MaxBytes[hardy.eth0]: 1250000 Title[hardy.eth0]: eth0 PageTop[hardy.eth0]:

Traffic Analysis for eth0 -- hardy

System:	hardy
Maintainer:	Root [email protected]
Description:	eth0
ifName:	eth0
Max Speed:	1250.0 kBytes/s
IP:	192.168.0.20

[...]

Neben dem Überwachen des Netzwerkverkehrs sind bei einem Server noch weitere Betriebsparameter von großem Interesse, z. B. die CPU-Last und der Speicherverbrauch. Leider ist cfgmaker nicht so mächtig, diese Werte selbständig in eine Konfigurationsdatei schreiben zu können, weswegen Sie die gewünschten

347

5.1

5

Optimierung und Monitoring

Werte händisch in der MIB des Systems suchen und in eine Konfigurationsdatei verpacken müssen. Eine Konfigurationsdatei zur Überwachung der CPU, aufgeteilt in Benutzer- und Kernelzeiten, ist die folgende: WorkDir: /var/www/mrtg LoadMIBs: /usr/share/snmp/mibs/UCD-SNMP-MIB.txt Target[hardy.cpu]:ssCpuRawUser.0&ssCpuRawUser.0:[email protected]+ ssCpuRawSystem.0&ssCpuRawSystem.0:[email protected]+ ð ssCpuRawNice.0&ssCpuRawNice.0:[email protected] RouterUptime[hardy.cpu]: [email protected] MaxBytes[hardy.cpu]: 100 Title[hardy.cpu]: CPU Load on hardy PageTop[hardy.cpu]:

Active CPU Load %

Unscaled[hardy.cpu]: ymwd ShortLegend[hardy.cpu]: % YLegend[hardy.cpu]: CPU Utilization Legend1[hardy.cpu]: Active CPU in % (Load) Legend2[hardy.cpu]: Legend3[hardy.cpu]: Legend4[hardy.cpu]: LegendI[hardy.cpu]: Active LegendO[hardy.cpu]: Options[hardy.cpu]: growright,nopercent

ð

Denken Sie daran, den Community-String anzupassen, und speichern Sie die vorstehende Konfiguration in die Datei /etc/mrtg/cpu.cfg. In einer weiteren Konfigurationsdatei können Sie die Überwachung des Speicherverbrauchs festlegen: LoadMIBs: /usr/share/snmp/mibs/HOST-RESOURCES-MIB.txt Target[hardy.mem]: .1.3.6.1.4.1.2021.4.6.0&.1.3.6.1.4.1.2021.4.6.0: michnix@localhost PageTop[hardy.mem]:

Free Memory

WorkDir: /var/www/mrtg Options[hardy.mem]: nopercent,growright,gauge,noinfo Title[hardy.mem]: Free Memory on hardy MaxBytes[hardy.mem]: 1000000 kMG[hardy.mem]: k,M,G,T,P,X YLegend[hardy.mem]: bytes ShortLegend[hardy.mem]: bytes LegendI[hardy.mem]: Free Memory: LegendO[hardy.mem]: Legend1[hardy.mem]: Free memory, not including swap, in bytes

348

ð

Monitoring

Speichern Sie diese Datei als /etc/mrtg/mem.cfg. Damit MRTG diese Konfigurationsdateien verwendet, müssen Sie anschließend in der Datei /etc/cron.d/mrtg die entsprechenden Einträge anlegen: */5 * * * * /usr/bin/mrtg /usr/bin/mrtg fi else mkdir */5 * * * * /usr/bin/mrtg /usr/bin/mrtg fi else mkdir

root if [ -d /var/lock/mrtg ]; then if [ -x ð ] && [ -r /etc/mrtg/mem.cfg ]; then env LANG=C ð /etc/mrtg/mem.cfg >> /var/log/mrtg/mrtg.log 2>&1; ð /var/lock/mrtg; fi root if [ -d /var/lock/mrtg ]; then if [ -x ð ] && [ -r /etc/mrtg/cpu.cfg ]; then env LANG=C ð /etc/mrtg/cpu.cfg >> /var/log/mrtg/mrtg.log 2>&1; ð /var/lock/mrtg; fi

Zentrale oder dezentrale Konfiguration Bei MRTG ist eine Aufteilung der Konfiguration auf verschiedene Konfigurationsdateien – eine pro zu überwachendem Wert – durchaus sinnvoll. Ein Fehler in der Konfigurationsdatei kann dazu führen, dass MRTG stillschweigend keine Daten mehr aufzeichnet, was sich nachhaltig in der grafischen Darstellung niederschlägt: Bis der Fehler erkannt und behoben ist, fehlen schlichtweg die Daten in der Übersicht – und sie können auch nicht im Nachhinein wiederhergestellt werden. Daher sollten Sie als funktionierend bekannte Konfigurationen in eigene Dateien schreiben, so dass Änderungen an einzelnen Konfigurationen oder das Hinzufügen neuer Messwerte nicht zum Ausfall der gesamten Datenaufzeichnung von MRTG führen.

Nach dem Schreiben der MRTG- und Cron-Konfiguration wird sich das MRTGVerzeichnis im DocumentRoot mit Dateien füllen: # ls hardy.cpu-day.png hardy.cpu.html hardy.cpu.log hardy.cpu-month.png hardy.cpu.old hardy.cpu-week.png hardy.cpu-year.png hardy.mem-day.png hardy.mem.html

hardy.mem.log hardy.mem-month.png hardy.mem.old hardy.mem-week.png hardy.mem-year.png index.html localhost_eth0-day.png localhost_eth0.html localhost_eth0.log

localhost_eth0-month.png localhost_eth0.old localhost_eth0-week.png localhost_eth0-year.png mrtg-l.png mrtg-m.png mrtg-r.png oid-mib-cache.txt

Um eine übersichtliche Darstellung zu erhalten, können Sie mit dem Programm indexmaker eine neue Indexdatei erstellen. Übergeben Sie dazu als Parameter alle MRTG-Konfigurationsdateien: # indexmaker /etc/mrtg/mrtg.cfg /etc/mrtg/cpu.cfg /etc/mrtg/mem.cfg > /var/www/mrtg/index.html

ð

349

5.1

5

Optimierung und Monitoring

Die auf diese Weise erzeugte Indexdatei enthält alle Datenquellen, die in den als Parameter an indexmaker übergebenen Konfigurationsdateien definiert sind (Abbildung 5.6). Durch Klicken auf eine der Grafiken kommen Sie zur Detailansicht der gewählten Datenquelle.

Abbildung 5.6

5.1.3

Eine eigene MRTG-Indexdatei

Cacti

MRTG ist solides Handwerkzeug und kommt heute noch häufig in Rechenzentrumsumgebungen vor. Der Nachteil an MRTG ist die etwas altmodische Konfigurationsarbeit über die Kommandozeile. Wer nicht täglich mit dem Tool arbeitet und sich darüber hinaus gut mit SNMP auskennt, wird auf Dauer seine Schwierigkeiten mit MRTG haben, da er sich bei jeder Änderung neu in die Konfiguration einarbeiten muss. Mit Cacti steht ein ähnliches Tool wie MRTG zur Verfügung. Es greift zur Visualisierung der gesammelten Daten auf das RRDTool von Tobias Oetiker zurück, einem der Entwickler von MRTG. Cacti stellt die gesammelten Daten dar wie MRTG. Auf einer Übersichtsseite sieht der Benutzer Übersichtsgraphen aller Datenquellen, und per Klick auf einen Graphen gelangt er zur Detailansicht. Die Installation unter Ubuntu ist denkbar einfach: # sudo apt-get install cacti

350

Monitoring

Alle benötigten Pakete und Tools installiert apt automatisch mit. Im Anschluss an die Installation öffnet sich ein Dialog, der einige wichtige Installationsparameter abfragt. Von der Verwendung der Standardparameter sollten Sie nur dann abweichen, wenn Sie diese Abweichung gut begründen können. Im ersten Schritt erzeugt der Installer eine Datenbank auf dem lokalen MySQLServer, in der Cacti seine Daten ablegt.

Abbildung 5.7

Automatisches Anlegen der Datenbank für Cacti

Um die dafür benötigte Berechtigung zu erhalten, geben Sie im nächsten Schritt das Passwort des MySQL-Administrators ein.

Abbildung 5.8

Administrationsberechtigung für den Installer

351

5.1

5

Optimierung und Monitoring

Der Installer legt dann die Datenbank an und richtet einen MySQL-Benutzer für Cacti ein. Diesem weisen Sie im folgenden Schritt ein eigenes Passwort zu.

Abbildung 5.9

Das Passwort für den MySQL-Benutzer cacti

Cacti erzeugt mit PHP dynamische Webseiten. Dazu benötigt es einen Webserver. Der Ubuntu-Installer kann über apt installierte Webserver automatisch konfigurieren. In diesem Buch kommt durchgängig der Apache2 zum Einsatz, daher ist die Auswahl im Dialogfeld entsprechend.

Abbildung 5.10

Apache2 ist der Webserver für Cacti.

Nach dem vom Installer automatisch durchgeführten Neustart des Webservers ist unter der URL http:///cacti/ das Web-Interface von Cacti erreichbar. Das Verzeichnis ist nicht gegen unbefugte Zugriffe geschützt, daher empfiehlt

352

Monitoring

sich das umgehende Einrichten eines Zugriffsschutzes, z. B. via htaccess-Datei (siehe dazu Kapitel 4, »Serverdienste«). Beim ersten Aufruf des Web-Interfaces startet das Konfigurationsprogramm von Cacti.

Abbildung 5.11

Das Konfigurationsprogramm von Cacti

Die erste Frage ist die nach der Art der Installation. Bei einer neuen Installation ist die entsprechende Option zu wählen.

Abbildung 5.12

Art der Installation

Das Konfigurationsprogramm prüft im nächsten Schritt das Vorhandensein aller erforderlichen Komponenten. Bei einer Installation über den Ubuntu-Paketmanager sollte es an dieser Stelle keine Probleme geben, da der Paketmanager alle Abhängigkeiten automatisch auflöst.

353

5.1

5

Optimierung und Monitoring

Abbildung 5.13

Prüfen aller erforderlichen Komponenten

Nach Durchlaufen der Prüfung ist die Installation komplett, und der Login-Bildschirm von Cacti erscheint. Es kann passieren, dass während der Installation das Passwort für den Admin-Benutzer von Cacti nicht korrekt eingerichtet wird. In diesem Fall hilft nur Handarbeit. Cacti speichert seine Benutzerdaten in der MySQL-Datenbank Cacti und dort in der Tabelle user_auth. Öffnen Sie diese Tabelle in phpMyAdmin (siehe Kapitel 4, »Serverdienste«), und bearbeiten Sie den Benutzer Admin. Setzen Sie im Feld password das neue Passwort, wählen Sie aber vor dem Speichern für dieses Feld die Funktion MD5.

354

Monitoring

Abbildung 5.14

Setzen eines neuen Passwortes für den Admin-Benutzer

Nach dem Speichern können Sie sich mit dem Benutzernamen Admin und dem soeben gesetzten Passwort am Web-Interface von Cacti anmelden. Bei der erstmaligen Anmeldung erscheint die Aufforderung, das initiale Passwort zu ändern.

Abbildung 5.15

Passwortänderung bei der ersten Anmeldung

Nach der Änderung des Passwortes erscheint endlich das Web-Interface von Cacti. Über den Karteireiter graphs oben links gelangen Sie zur Übersicht der Graphen, die in Aussehen und Funktion der von MRTG entspricht.

355

5.1

5

Optimierung und Monitoring

Abbildung 5.16

Das Web-Interface von Cacti

Abbildung 5.17

Die grafische Darstellung von Cacti

Unter Ubuntu 10.4 sind automatisch die Graphen für den Speicherverbrauch, die Anzahl der eingeloggten Benutzer, den Load und die aktiven Prozesse eingerichtet. Das Hinzufügen eigener Messwerte und der dazugehörenden Graphen

356

Monitoring

geschieht komfortabel über das Web-Interface. Im Folgenden ist das Hinzufügen der Messwerte und Graphen für die Netzwerk-Interfaces beschrieben. Auf Grundlage dieser Beschreibung können Sie im Anschluss beliebige weitere Messwerte hinzufügen. Im Karteireiter console wählen Sie zunächst im Punkt Devices den Server aus, auf dem Sie die neuen Messwerte einrichten möchten. Bei lokaler Installation ist das der Server localhost.

Abbildung 5.18

Auswählen von localhost

In der Konfiguration des ausgewählten Servers (im Cacti-Jargon ein Device) fügen Sie im Feld SNMP Community den Read-String des SNMP-Dienstes ein, wählen als SNMP-Version die von Ihnen im SNMP-Dienst konfigurierte SNMPVersion aus und legen im Dropdown-Feld Host Template fest, dass das Device ein Generic SNMP-enabled Host ist. Cacti greift dann auf den lokalen SNMPDienst zu, um die gewünschten Werte auszulesen. Nach der Konfiguration der SNMP-Parameter fügen Sie im unteren Bereich der Device-Einstellungen im Abschnitt Associated Graph Template ein neues Template vom Typ SNMP – Generic OID Template hinzu. Im Anschluss an diesen Schritt erscheint am unteren Ende der Seite im Abschnitt Associated Data Queries automatisch ein Eintrag SNMP – Interface Statistics. Cacti hat automatisch die Überwachung der Netzwerk-Interfaces über SNMP angelegt.

357

5.1

5

Optimierung und Monitoring

Abbildung 5.19

SNMP-Konfiguration des Servers

Abbildung 5.20

Hinzufügen eines neuen, generischen SNMP-Templates

Abbildung 5.21

Das SNMP-Monitoring der Netzwerk-Interfaces ist aktiviert.

Damit die Daten der Interfaces grafisch dargestellt werden, müssen Sie im letzten Schritt die entsprechenden Graphen anlegen. Dies geschieht über den Navigationspunkt Create 폷 New Graphs links in der Navigationsspalte des Web-Interfaces.

358

Monitoring

Dort sind die möglichen Datenquellen bereits aufgeführt, und Sie müssen nur die Interfaces auswählen, für die Sie Graphen erzeugt haben möchten. Das lokale Loopback-Interface ist in der Regel nicht von Interesse. Aktivieren Sie die gewünschten Interfaces mit den Checkboxen am rechten Rand, und erstellen Sie die Graphen durch Bestätigen des Create-Buttons am unteren Seitenende.

Abbildung 5.22

Auswählen der zu erzeugenden Graphen

Das erfolgreiche Erzeugen der Graphen quittiert Cacti anschließend durch die Meldung ... + Created graph: Localhost – Traffic – eth0 + Created graph: Localhost – Traffic – eth1

... im Seitenkopf. In der Übersicht der Graphen finden Sie dann die beiden Netzwerk-Interfaces. Cacti unter Gentoo Zum Zeitpunkt der Manuskripterstellung gab es keinen funktionierenden Ebuild von Cacti für Gentoo. Da für Detektivspielen neben der normalen Administrationsarbeit wenig Zeit bleibt, hilft in diesem Fall nur das Warten auf einen funktionierenden Ebuild oder das manuelle Kompilieren von Cacti inklusive aller benötigten Tools. Von dieser Variante sollten Sie allerdings nur im größten Notfall Gebrauch machen.

359

5.1

5

Optimierung und Monitoring

Abbildung 5.23

5.1.4

Die Netzwerk-Interfaces sind da.

Nagios

Sowohl MRTG als auch Cacti sind gut dafür geeignet, Tendenzen festzustellen und darauf aufbauend Probleme wie Lastspitzen im Nachhinein erkennen und mittel- bis längerfristige Kapazitätsplanungen durchführen zu können. Wofür sich beide gar nicht eignen, ist die Echtzeitüberwachung von Systemen oder Infrastrukturen. Um Probleme möglichst zeitnah erkennen und entsprechend reagieren zu können, empfiehlt sich die Verwendung von Tools wie Nagios. Nagios ist ein Client/Server-basiertes Monitoring-Tool, das auf dem zentralen Überwachungsserver Daten von zu überwachenden Systemen sammelt, auswertet, darstellt und auch die Möglichkeit bietet, über Eskalationsketten beim Eintreten von Problemen Systemverantwortliche zu benachrichtigen. Nagios ist Open Source und steht unter der GPL. Daher kann es sehr leicht an eigene Bedürfnisse angepasst werden. Das Herzstück von Nagios ist der Nagios-Daemon selbst. Dieser leistet die gesamte Verwaltungsarbeit des Systems und verarbeitet alle Daten. Die Überwachung selbst wird über Plugins realisiert. Das können Programme oder Skripte sein, die der Nagios-Server aufruft und die über eine definierte Schnittstelle die Ergebnisse ihrer Überwachungstätigkeit an den Nagios-Server zurückmelden. Der Nagios-Server bereitet die Daten – genau wie MRTG – so auf, dass sie über einen (Apache-)Webserver veröffentlicht werden können. Die Weboberfläche

360

Monitoring

von Nagios bietet einem Administrator die Möglichkeit, Befehle an den NagiosServer abzusetzen, z. B. um einen Überprüfungsvorgang unmittelbar auszuführen oder um für einen Host oder einen Dienst eine geplante Downtime einzutragen. Nagios kennt zwei grundsätzliche Möglichkeiten, Überwachungsaktionen auszuführen: Abfragen über das Netzwerk, um die Erreichbarkeit und Güte von Netzwerkdiensten zu ermitteln, und Abfragen auf den zu überwachenden Systemen selbst. Die Prüfungen über das Netzwerk werden über Plugins realisiert, die sich auf dem Nagios-Server befinden und von diesem selbst aufgerufen werden. Mögliche Testfälle sind z. B. die Erreichbarkeit von Systemen per ICMP (»Ping«) oder das Prüfen, ob ein Webserver erreichbar ist. Da es sich bei den Plugins um Programme handelt, die bis auf den Rückgabewert beliebige Funktionen enthalten können, steht Ihrer Kreativität zur Überwachung Ihres Servers nichts im Weg. Administrator

Apache

CMD

NSCA NSCA Nagios NRPE

NRPE

CPU

WWW

Plugins ICMP

RAM

Nagios-Server Überwachtes System Abbildung 5.24

Übersicht über die Nagios-Komponenten

Um Ressourcen überwachen zu können, die über das Netzwerk nicht erreichbar sind, gibt es zwei verschiedene Agenten, die auf den zu überwachenden Systemen installiert sein müssen, mit denen der Nagios-Server über das Netzwerk kommunizieren und über die er die betreffenden Systeme überwachen kann. Dabei gibt es zwei verschiedene Arten der Überwachung. Das Nagios-Plugin NRPE, der Nagios Remote Plugin Executor, ist ein auf den zu überwachenden Systemen installierter Dienst, der über das Netzwerk Befehle vom Nagios-Server entgegennimmt, lokale Plugins ausführt und die Ergebnisse an den Nagios-Server zurückgibt. Der Verbindungsaufbau findet hierbei vom Nagios-Server in Richtung des zu überwachenden Systems statt, was aus Sicherheitsgründen die »rich-

361

5.1

5

Optimierung und Monitoring

tige« Richtung ist, denn wenn sich der Nagios-Server in einem internen Netzwerk befindet, ist es kaum wünschenswert, dass die zu überwachenden Systeme Verbindungen zu dem Nagios-Server aufbauen dürfen – vom Internet in ein internes Netz. Der Abschnitt »NRPE« (Seite 384) zeigt die Konfiguration und Verwendung von NRPE. Diese Kommunikationsrichtung stellt das zweite Überwachungs-Plugin für Nagios bereit, das NSCA (Nagios Service Check Acceptor). Dabei läuft ein NSCADienst auf dem zu überwachenden System und baut aktiv Verbindungen zum Nagios-Server auf. Details zur Verwendung von NSCA enthält der entsprechende Abschnitt auf Seite 390. Eine Übersicht über die Architektur von Nagios inklusive der Kommunikationsrichtungen zeigt Abbildung 5.24. Nagios kennt bei der Überwachung zwei unterschiedliche Dinge: Objekte und Services. Hosts sind die Bezeichnung für Systeme, Services stehen für Dienste, die von den Hosts angeboten werden. Ein Host kann verschiedene Services anbieten, z. B. Web, SSH, FTP oder Jabber. Umgekehrt kann ein Service aber auch von mehreren Hosts angeboten werden. Wenn Ihre Webseite aus Lastgründen auf verschiedene Server verteilt ist und über einen Loadbalancer angesprochen wird, stellt sie zwar einen einzelnen Dienst dar, dieser ist aber von mehreren Hosts abhängig. Hosts und Services können untereinander Abhängigkeiten bilden. Wenn Sie mit Nagios auf einem Host A den Service »Apache« überwachen, der wiederum den Service »Webseite« betreibt, führt ein Ausfall des Dienstes »Apache« dazu, dass auch der Dienst »Webseite« ausfällt. Umgekehrt bedeutet ein Ausfall des Dienstes »Webseite« nicht zwangsläufig, dass der Dienst »Apache« ausgefallen ist. Der Apache-Prozess kann durchaus noch vorhanden sein und von Nagios erkannt werden, trotzdem beantwortet er aber aufgrund eines internen Fehlers keine Anfragen von Clients mehr. Beide Dienste, »Apache« und »Webseite«, liegen auf einem Server, einem von Nagios ebenfalls überwachten Host. Fällt nun dieser Host aus, fallen ebenso beide Dienste aus. Der umgekehrte Fall, dass einer oder beide Dienste ausfallen, führt wiederum nicht dazu, dass der Host ausfällt (siehe Abbildung 5.25). Host

Webseite Nagios Apache

Abbildung 5.25

362

Abhängigkeiten in Nagios

Monitoring

Um solche Gegebenheiten zu modellieren, bietet Nagios die Möglichkeit, Abhängigkeiten von Hosts und Services zu definieren. Nagios selbst ist so schlau, beim Ausfall eines Services zu prüfen, ob der Host, auf dem der Service läuft, noch erreichbar ist. Ist dies nicht der Fall, werden alle dem Host zugeordneten Services als ausgefallen markiert. Die Überprüfung eines Hosts oder Dienstes kann einen von vier Status annehmen: OK, WARNING, CRITICAL, UNKNOWN. Dabei sind die Bedeutungen der einzelnen Status die folgenden: 왘

OK: Das Ergebnis der Überprüfung lag innerhalb der erlaubten Parameter.

왘

WARNING: Das Ergebnis der Überprüfung lag über dem für dieses Objekt konfigurierten Schwellwert für den Alarmzustand, aber unterhalb des Schwellwertes für den kritischen Zustand.

왘

CRITICAL: Das Ergebnis der Überprüfung lag über dem für dieses Objekt konfigurierten Schwellwert für den kritischen Zustand.

왘

UNKNOWN: Die Prüfung hat einen unbekannten Rückgabewert geliefert, was entweder an einem Fehler in der Ausführung, einem fehlerhaften Plugin oder anderen nicht näher definierten Ereignissen liegen kann. In diesem Fall ist ein Blick in die Logdatei von Nagios angezeigt.

In einer Infrastruktur hängen nicht nur Services von Hosts ab, sondern auch Hosts von anderen Hosts. Webserver können von Loadbalancern abgeschirmt werden, die gesamte Infrastruktur kann sich hinter Firewalls, Routern, Switches und anderen Netzwerkkomponenten verbergen etc. Vorausgesetzt, dass alle Komponenten einer Infrastruktur mit Nagios überwacht werden, können auch solche Abhängigkeiten modelliert werden. Fällt dann ein Host aus, der andere, von ihm abhängige Hosts abschirmt, markiert Nagios direkt alle diese Hosts als nicht erreichbar. Auf diese Weise lassen sich auch bei größeren Ausfällen die Ursachen ermitteln, und insbesondere bei stark vernetzten Diensten – wie z. B. auf verschiedene Systeme verteilte Web-, Datenbank- und Applikationsserver – ist diese Art der Intelligenz enorm hilfreich, um Probleme lokalisieren zu können. Abbildung 5.26 zeigt eine Kette von Abhängigkeiten. Der eigentliche zu überwachende Dienst ist die vom Webserver WWW ausgelieferte Webseite. Diese ist allerdings von einer Reihe anderer Services und Hosts abhängig. Damit dieser Dienst erreicht werden kann, müssen die Firewall, der Loadbalancer, die Web Application Firewall (WAF), der Switch und der Webserver im Status OK sein. Nur dann ist gewährleistet, dass die Webseite erreichbar ist. Erreichbarkeit ist nicht alles, eine Webseite soll auch Inhalte anbieten. In diesem Beispiel kommen die Inhalte dynamisch aus der auf dem Host DB liegenden Datenbank. Dort holt sie der Application Server APP und reicht die Ergebnisse an

363

5.1

5

Optimierung und Monitoring

den Webserver weiter. Das bedeutet, dass der Service »Webseite« inhaltlich nur dann OK ist, wenn sich die entsprechenden Services auf den Hosts DB und APP im Status OK befinden. Der Ausfall von einem der beiden Hosts, DB oder APP, führt zwar nicht dazu, dass der Dienst »Webseite« nicht mehr erreichbar ist, allerdings kann der Webserver keine sinnvollen Inhalte mehr darstellen.

Nagios

Firewall

Loadbalancer

WAF

Switch

DB

WWW

APP Abbildung 5.26

Komplexere Abhängigkeiten in Nagios

Bei der Überprüfung von Services nimmt Nagios in der Regel den Standpunkt eines Benutzers ein. Der Nagios-Server prüft per Netzwerk die Verfügbarkeit von Diensten. Das kann z. B. das Abrufen einer Webseite sein oder ein Verbindungsaufbau zu einem FTP-Server. Die Verfügbarkeit von Diensten ist in der Regel von großer Bedeutung. Neben den Diensten, die Nagios aus dem Blickwinkel des Benutzers prüft, werden auf den zu überwachenden Hosts lokale Plugins ausgeführt, die beliebige Parameter wie z. B. CPU-Last, Festplattenbelegung, Speicherverbrauch oder aktive Prozesse auslesen und an den Nagios-Server berichten.

364

Monitoring

Nagios und der eigene Server Wenn Sie nur einen einzelnen Server betreiben, stellt sich die Frage nach dem sinnvollsten Ort einer Nagios-Installation. Um die Verfügbarkeit des Servers zu überwachen, ist es wenig ratsam, Nagios auf dem zu überwachenden System zu installieren. Fällt das System aus, können Sie auch nicht mehr auf Nagios zugreifen, um nach den Ursachen des Ausfalls zu suchen. Überdies können Sie auf diese Weise auch keine temporären Probleme erkennen. Sie sollten Nagios – so wie jedes Überwachungstool – auf einem eigenen System, idealerweise außerhalb der Infrastruktur installieren, in der Sie den zu überwachenden Server betreiben. Bei der Überwachung einzelner Systeme ist Nagios recht anspruchslos, was seinen Ressourcenbedarf angeht, daher kann für diesen Zweck auch das Anmieten eines günstigen V-Servers bei einem anderen Provider ausreichend sein. Entsprechende Angebote sind schon für unter 10 Euro im Monat zu haben. Die in den folgenden Abschnitten gezeigten Beispiele setzen eine Installation von Nagios auf einem externen System voraus.

Installation unter Ubuntu Die Unterstützung von Nagios unter Ubuntu ist sehr umfangreich. Eine Suche nach Nagios-Paketen ergibt eine recht lange Liste: # apt-cache search nagios| awk ' { print $1}' munin nagios-images nagios-nrpe-server nagios-plugins nagios-plugins-basic nagios-plugins-standard nagios3 nagios3-cgi nagios3-common nagios3-core nagios3-dbg nagios3-doc arrayprobe gozerbot hobbit-plugins libnagios-object-perl libnagios-plugin-perl mailping nagcon nagios-nrpe-plugin nagios-plugins-extra nagios-snmp-plugins nagios-statd-client nagios-statd-server

365

5.1

5

Optimierung und Monitoring

nagiosgrapher nagvis ndoutils-common ndoutils-doc ndoutils-nagios3-mysql nsca python-pymssql collectd-utils

Für den Anfang reichen die folgenden Pakete: # sudo apt-get install nagios3 nagios-plugins-basic nagios-pluginsstandard nagios-images nagios-nrpe-plugin nagios-nrpe-server nagiosplugins nagios-plugins-extra nagiosgrapher

Während der Installation müssen Sie einige Fragen des Installers beantworten. Die erste bezieht sich auf die Art des E-Mail-Versands, über den Nagios Benachrichtigungen per E-Mail absetzen soll. Falls Sie unsicher sind, wählen Sie Nur lokal. E-Mails liegen dann ausschließlich lokal auf dem System. Ist die Zustellung über den Mailserver Ihres Providers gewünscht, wählen Sie entsprechend Internet-Site etc.

Abbildung 5.27

E-Mail-Einstellungen von Nagios

Die nächste Frage erfordert die Angabe des FQDN Ihres Servers, also des vollständigen DNS-Namens (Fully-Qualified Domain Name).

366

Monitoring

Abbildung 5.28

Der FQDN des Nagios-Servers

Im dritten und bereits letzten Schritt des Konfigurationsdialoges legen Sie das Passwort für den Benutzer nagiosadmin fest, über den Sie auf das Web-Interface von Nagios zugreifen können. Da die von Nagios überwachten Daten durchaus sensiblen Charakter haben, sollte das Passwort tunlichst weder nagiosadmin noch nagios sein. Oder allgemein ausgedrückt: Der Zugriff auf Monitoring-Daten durch einen Unbefugten stellt bereits eine Sicherheitslücke (Information Leakage) dar, weswegen Sie zur Absicherung von Nagios unbedingt ein hinreichend starkes Passwort verwenden sollten.

Abbildung 5.29

Das Passwort für den Zugriff auf das Web-Interface

367

5.1

5

Optimierung und Monitoring

Die Installationsroutine richtet anschließend eine Konfiguration für den ApacheServer ein und startet diesen neu, so dass Sie ohne Umwege auf die Nagios-Oberfläche zugreifen können. Die URL dazu ist http:///nagios3.

Abbildung 5.30

Das Web-Interface von Nagios

Freundlicherweise sind bereits einige Checks für den lokalen Server sowie das Netzwerk (Erreichbarkeit des Standard-Gateways) vorkonfiguriert – zu finden unter service detail.

Abbildung 5.31

Unter Ubuntu bereits vorkonfigurierte Checks

Installation unter Gentoo Auch unter Gentoo existiert ein Nagios-Paket. Gemeinsam mit diesem Paket werden auch die weiteren benötigten Pakete installiert. Damit Nagios überhaupt

368

Monitoring

installiert werden kann, müssen Sie in der Datei /etc/make.conf vorher die USEFlags jpeg und png hinzufügen. # sudo emerge nagios

Im Anschluss an die Installation richten Sie den Nagios-Dienst für den automatischen Start ein: # sudo rc-update add nagios default * nagios added to runlevel default

Damit der Apache automatisch für den Betrieb von Nagios konfiguriert wird, müssen Sie im nächsten Schritt in der Datei /etc/conf.d/apache2 die Variable APACHE_OPTS um den Parameter -D NAGIOS erweitern: APACHE2_OPTS="-D DEFAULT_VHOST -D INFO -D LANGUAGE -D SSL -D SSL_DEFAULT_VHOST -D PHP5 -D JK -D NAGIOS"

ð

Nach einem Neustart des Apache ... # sudo /etc/init.d/apache2 restart

... ist die Nagios-Oberfläche über den Webserver im Verzeichnis /nagios erreichbar – ohne Passwortschutz und ohne vorkonfigurierte Checks.

Abbildung 5.32

Nagios unter Gentoo

369

5.1

5

Optimierung und Monitoring

Konfiguration Die Installation stellt nur den geringsten Teil der Arbeit zur Einrichtung von Nagios dar. Der größte Teil besteht in der Konfiguration von Nagios. Diese ist unabhängig von der verwendeten Distribution, der einzige Unterschied zwischen Ubuntu und Gentoo besteht darin, dass sich unter Ubuntu die Konfigurationsdateien von Nagios im Verzeichnis /etc/nagios3 befinden, unter Gentoo im Verzeichnis /etc/nagios. Die folgenden Beispiele und Anweisungen verwenden die Pfadangaben von Ubuntu – für eine Adaption in Gentoo brauchen Sie einfach nur den Pfad /etc/nagios zu verwenden. Nagios ist so konfiguriert, dass es beim Start die Datei /etc/nagios3/nagios.cfg einliest. Die Datei ist von Hause aus vorbildlich dokumentiert und unter Ubuntu bereits so angepasst, dass kaum mehr Anpassungen notwendig sind. Wichtig sind die Direktiven, in denen die Verzeichnisse festgelegt sind, in denen Nagios nach weiteren Konfigurationsdateien sucht. Wie der Apache kann auch Nagios verschiedene Konfigurationsdateien verwenden, dies muss lediglich in der zentralen Konfigurationsdatei entsprechend konfiguriert sein. Insbesondere sind das die folgenden beiden Direktiven: cfg_dir=/etc/nagios3/conf.d cfg_dir=/etc/nagios-plugins/config

Die Direktiven nagios_user und nagios_group legen den Betriebssystembenutzer fest, in dessen Kontext der Nagios-Server läuft. Alle anderen Direktiven sind für den Anfang unwichtig. In der Hauptsache werden damit globale Vorgaben für das Verhalten von Nagios festgelegt, Logdateien definiert etc. Für die Überwachung eines oder einiger weniger Systeme gibt es in der Regel keinen Grund, an den Standardeinstellungen etwas zu ändern – es sei denn, Sie sind experimentierfreudig oder der Nagios-Server läuft auf einer Maschine mit begrenzten Ressourcen und erfordert Feintuning. Nach dem Start von Nagios können Sie zwar die Startseite aufrufen, das Abfragen von Informationen schlägt allerdings fehl (Abbildung 5.33). Der Grund liegt darin, dass ein nicht näher spezifizierter Benutzer in der Grundkonfiguration von Nagios zwar die Startseite aufrufen darf, aber auch nur diese und nicht mehr. Nagios verwendet zur Identifizierung eines Benutzers das Authentifizierungsverfahren des Apache, d. h. den Benutzer, der nach der Installation mit htpasswd angelegt worden ist und mit dem man sich beim Zugriff auf das Nagios-Verzeichnis am Apache anmelden muss. Damit dieser Benutzer Zugriffsrechte auf die eigentlichen Informationen von Nagios erhält, müssen in der Datei /etc/nagios3/ cgi.cfg die entsprechenden Direktiven angepasst werden. Standardmäßig heißt

370

Monitoring

der Benutzer unter Ubuntu nagiosadmin. Damit der nach der Installation angelegte Benutzer nagios zugreifen darf, müssen die folgenden Direktiven geändert werden: authorized_for_system_information=nagios authorized_for_configuration_information=nagios authorized_for_system_commands=nagios authorized_for_all_services=nagios authorized_for_all_hosts=nagios authorized_for_all_service_commands=nagios authorized_for_all_host_commands=nagios

Abbildung 5.33

Fehler beim Zugriff auf Informationen

Damit erhält der Benutzer nagios Zugriff auf alle Host- und Service-Informationen und darf zusätzlich über die Nagios-Oberfläche Befehle absetzen – was später noch näher erläutert wird. Nach dem Neustart des Nagios-Servers ... # sudo /etc/init.d/nagios3 restart

... ist ein Zugriff auf alle Informationen möglich (Abbildung 5.34). Freundlicherweise ist Nagios standardmäßig schon so konfiguriert, dass einige Checks auf dem lokalen Host, dem Nagios-Server, ausgeführt werden. Die Checks und ihre Ergebnisse sollten selbsterklärend sein. Darüber hinaus prüft Nagios die Erreich-

371

5.1

5

Optimierung und Monitoring

barkeit des Gateways mit ICMP-Paketen. Sofern das Gateway bei Ihnen erreichbar ist und keiner der überwachten Dienste auf dem Nagios-Server ein Problem hat, sollten alle Status ausschließlich grün sein.

Abbildung 5.34

Service-Details für den lokalen Host

Das Konfigurationsprinzip von Nagios erschließt sich aus der Analyse der vorhandenen Konfigurationsdateien im Verzeichnis /etc/nagios3/conf.d. Auch hier gilt, dass die Konfiguration auch in eine einzelne Datei zusammengefasst werden kann, aus Gründen der Übersichtlichkeit empfiehlt sich aber eine klare Trennung. Die Konfiguration von Nagios umfasst die Definition von Hosts, Services, Hostgruppen, Servicegruppen, Kontaktpersonen, Eskalationsketten und Betriebszeiten. Diese Themen sind in den folgenden Dateien konfiguriert: 왘

contacts_nagios3.cfg: Kontakte und Eskalationsketten

왘

host-gateway_nagios3.cfg: Das Gateway des lokalen Netzes

왘

services_nagios3.cfg: Definition von Services

왘

extinfo_nagios3.cfg: Erweiterte Informationen zu Hosts

왘

hostgroups_nagios3.cfg: Hostgruppen

왘

timeperiods_nagios3.cfg: Zeiträume für Überprüfungen

왘

generic-host_nagios3.cfg: Template eines generischen Hosts

372

Monitoring

왘

generic-service_nagios3.cfg: Template eines generischen Services

왘

localhost_nagios3.cfg: Konfiguration des lokalen Hosts

Templates In der vorstehenden Übersicht ist Ihnen der Begriff Template begegnet. Nagios verwendet zur Konfiguration Objekte, die Eigenschaften an andere Objekte vererben oder Eigenschaften von anderen Objekten erben können. Die Templates für den generischen Host und den generischen Service sind Beispiel-Templates, die als Vorlage für die Erstellung eigener Templates dienen können.

Einen guten Einstieg in das Verständnis der Nagios-Konfiguration bietet die automatisch angelegte Konfigurationsdatei für das Gateway des lokalen Netzes (/etc/ nagios3/conf.d/host-gateway_nagios3.cfg): define host { host_name alias address use }

gateway Default Gateway 192.168.0.1 generic-host

Objektdefinitionen in Nagios bestehen stets aus dem Schlüsselwort define, gefolgt vom Typ des Objektes und den Eigenschaften des Objektes, Letztere in geschweiften Klammern eingeschlossen. In diesem Fall ist das definierte Objekt ein Host. Dieser Host hat den Namen gateway, der alias dient der besseren Übersichtlichkeit in der Anzeige, die Eigenschaft address legt die IP-Adresse des Hosts fest und das Schlüsselwort use benennt ein Template, das für die Definition des Hosts verwendet wird, in diesem Fall das Template generic-host. Dieses Template ist in der Datei /etc/nagios3/conf.d/generic-host_nagios3.cfg definiert: define host{ name notifications_enabled event_handler_enabled flap_detection_enabled failure_prediction_enabled process_perf_data retain_status_information retain_nonstatus_information check_command max_check_attempts notification_interval

generic-host 1 1 1 1 1 1 1 check-host-alive 10 0

373

5.1

5

Optimierung und Monitoring

notification_period notification_options contact_groups register

24x7 d,u,r admins 0

}

Die in diesem Template festgelegten Eigenschaften werden von allen Hosts übernommen, die das Template über die use-Direktive verwenden. Änderungen am Template wirken sich unmittelbar auf alle Hosts aus, die dieses Template verwenden. Um das Senden von Benachrichtigungen bei einem Statuswechsel bei allen diesen Hosts zu unterbinden, setzen Sie im Template einfach die Direktive notifications_enabled auf »0«. Wichtig ist beim Anlegen von Templates, dass die Direktive register 0 gesetzt ist. Damit wird ein Template als ein solches gekennzeichnet und von Nagios nicht als echter Host betrachtet. Ohne diese Kennzeichnung würde Nagios dieses Template in die Überwachung einbeziehen, was aus verständlichen Gründen wenig sinnvoll ist. Betrachten Sie dieses Template als eine abstrakte Klasse, um in der Sprachweise der objektorientierten Programmierung zu bleiben. Sinn und Unsinn von Templates Bei der Überwachung einzelner Systeme erschließt sich die Mächtigkeit und der Vorteil von Templates bei der Nagios-Konfiguration häufig nicht, denn eine Konfiguration für ein oder zwei Systeme ist schnell auch ohne Templates erstellt. Bei der Verwaltung großer Infrastrukturen ist es allerdings ungeheuer hilfreich, gleiche Eigenschaften von Objekten zusammenfassen zu können. Globale Änderungen, die alle Hosts betreffen, müssen dann nur zentral am Template durchgeführt werden und nicht für jeden Host einzeln. Dasselbe gilt für Services und andere Objekte in Nagios: Für kleine Anwendungen sind Templates häufig überflüssig. Sobald Objekte in großer Zahl vorhanden sind und über ausreichend viele identische Eigenschaften verfügen, sind Templates eine große Hilfe.

Abbildung 5.35 zeigt das Template- und Vererbungsprinzip von Nagios. Das Template WWW legt globale Daten für einen bestimmten Servertyp fest, in diesem Beispiel für einen Webserver. Bei der Verwendung von Templates ist es sinnvoll, Systeme mit gleichen Eigenschaften zu gruppieren, also z. B. ein Template für Webserver, ein anderes für Datenbankserver und ein weiteres für Application Server. Das in Abbildung 5.35 gezeigte Template legt alle den zu überwachenden Webservern gemeinsamen Attribute fest, so dass die Webserver lediglich das zu verwendende Template und ihre individuellen Attribute besitzen.

374

Monitoring

WWW notification check_command max_check_attempts ... register 0

WWW 1

WWW 2

use www host_name hardy.rodewig.de alias hardy address 192.168.100.100

Abbildung 5.35

use www host_name hardy2.rodewig.de alias hardy2 address 192.168.100.101

Vererbung in Nagios

Neben der Möglichkeit der Vererbung bietet Nagios noch die Möglichkeit, Hosts zu Hostgroups und Services zu Servicegroups zusammenzufassen. Der Sinn dahinter liegt sowohl in der Vereinfachung der Konfiguration als auch darin, die Übersichtlichkeit der Überwachung zu erhöhen und zusammenhängende Dienste und Hosts in der Statusübersicht als solche kennzeichnen zu können. Dies ist insbesondere bei der Überwachung größerer Infrastrukturen von Bedeutung. Eine Hostgroup, bestehend aus den zwei Webservern hardy und hardy2, wird wie folgt definiert: define hostgroup { hostgroup_name alias members }

webserver Web-Server hardy, hardy2

Das Anlegen von Hosts in der Konfiguration von Nagios ist nur die halbe Miete. Damit Nagios Hosts überprüfen kann, müssen Services definiert und den zu überprüfenden Hosts zugewiesen werden. Die Verwendung von Templates ist dabei auch bei einer kleinen zu überwachenden Infrastruktur überaus sinnvoll. Nagios bringt ein Standard-Template für Services mit, den generic-service: define service{ name active_checks_enabled passive_checks_enabled parallelize_check obsess_over_service

generic-service 1 1 1 1

375

5.1

5

Optimierung und Monitoring

check_freshness notifications_enabled event_handler_enabled flap_detection_enabled failure_prediction_enabled process_perf_data retain_status_information retain_nonstatus_information notification_interval is_volatile check_period normal_check_interval retry_check_interval max_check_attempts notification_period notification_options contact_groups register

0 1 1 1 1 1 1 1 0 0 24x7 5 1 4 24x7 w,u,c,r admins 0

}

In der Regel, insbesondere bei der Überwachung eines einzelnen Servers, wird man für die verschiedenen Services dieselben Attribute verwenden. Je nachdem, wie unterschiedlich sich die zu überwachenden Dienste verhalten, können einzelne Attribute aus dem Template in die konkreten Service-Objekte verlagert werden. Direktiven zur Benachrichtigung beispielsweise sind bei einem nicht in einem Rechenzentrum stehenden und mit 7×24-Stunden-Support versorgten System eher von geringerer Bedeutung und werden in einem solchen Fall mit hoher Wahrscheinlichkeit für alle Services gleich sein können. Für die Definition von Eskalationsketten kennt Nagios zwei wichtige Objekte: Timeperiods und Contacts. Timeperiods sind Angaben über Zeiträume, innerhalb derer Nagios Benachrichtigungen rausschickt. Haben Sie einen 7×24 -Stunden-Support für Ihren Server, können Sie die Standard-Timeperiod verwenden. Wenn der Support ohnehin nur wochentags von 8 bis 16 Uhr erreichbar ist, sollten Sie die Timeperiod entsprechend anpassen, um zu verhindern, dass die Inbox des Supports (oder Ihre Inbox) in der Zeit zwischen 16 und 8 Uhr und am Wochenende von Nagios mit Mails zugepflastert wird. Eine entsprechende Definition dieser Timeperiod sieht wie folgt aus: define timeperiod{ timeperiod_name alias Monday Tuesday Wednesday

376

support_zeiten Arbeitszeit 0800-1600 0800-1600 0800-1600

Monitoring

Thursday Friday

0800-1600 0800-1600

}

Einen zu benachrichtigenden Kontakt können Sie über das Objekt contact erzeugen: define contact{ contact_name alias service_notification_period host_notification_period service_notification_options host_notification_options service_notification_commands host_notification_commands email }

support Server-Support support_zeiten support_zeiten w,u,c,r d,r notify-by-email host-notify-by-email [email protected]

In der Definition des Kontakts verwenden Sie die passende Timeperiod. Mit der Direktive service_notification_options können Sie festlegen, bei welchen Status eines Services dieser Kontakt benachrichtigt werden soll. Mögliche Werte sind die Kürzel der möglichen Status, wobei r für recovery steht, eine Benachrichtigung also dann erzeugt wird, wenn ein Host oder Service sich wieder erholt hat und in den Status OK zurückwechselt. Den Fall, dass ein Host ganz ausfällt, repräsentiert das Kürzel d (down). Für die Überwachung eines Services stehen verschiedene Direktiven zur Verfügung. Einige sind verpflichtend, andere optional. Die folgende Tabelle zeigt alle möglichen Direktiven. Optionale Direktiven sind dabei mit einem Stern gekennzeichnet. Direktive

Bedeutung

Name

Der Name eines Services, wenn dieser nur als Template vorhanden ist. Andere Services können diesen Service über diesen Namen einbinden und seine Attribute erben.

host_name

Name des oder der Hosts, auf dem oder denen dieser Service läuft.

hostgroup_name*

Zusätzlich oder alternativ zur vorstehenden Direktive host_ name kann mit dieser Direktive eine ganze Hostgruppe angegeben werden.

service_description

Eine Beschreibung des Dienstes. Die hier festgelegte Bezeichnung wird in der Nagios-Oberfläche angezeigt.

Tabelle 5.1

Direktiven zur Überwachung eines Services (*: optionale Direktiven)

377

5.1

5

Optimierung und Monitoring

Direktive

Bedeutung

display_name*

Falls Sie auf der Nagios-Oberfläche einen anderen Namen als die service_description angezeigt bekommen möchten, können Sie diese Direktive dazu verwenden.

servicegroups*

Gehört der Service zu einer Servicegroup, kann diese hiermit festgelegt werden.

is_volatile*

Kennzeichnet einen volatilen Service. Bei volatilen Services wird bei jeder Prüfung, die einen Hard State zurückgibt, eine Benachrichtigung erzeugt und der entsprechende Event Handler aufgerufen. Details dazu enthält der folgende Abschnitt.

check_command

Der Name des Befehls, der zur Überprüfung verwendet wird.

initial_state*

Ausgangsstatus des Services. Nicht jeder Service muss sich zu Beginn der Überprüfung durch Nagios im Status OK befinden. Mögliche Werte sind die Kürzel der vier Status O, W, C, U (OK, WARNING, CRITICAL, UNKNOWN).

max_check_attempts

Anzahl der Überprüfungen, die Nagios durchführt, bevor der Service als nicht OK festgelegt wird.

check_interval

Anzahl der Minuten zwischen zwei Überprüfungen, während der Service im Status OK ist. Über die Direktive interval_ length in der zentralen Nagios-Konfiguration kann die Einheit des Intervalls geändert werden. Der Standardwert ist 60 und steht für 60 Sekunden. Ein Wert von 1 bei check_ interval bedeutet also, dass zwischen zwei Überprüfungen 60 Sekunden liegen.

retry_interval

Nach dem Wechsel von OK in einen anderen Status gilt nicht mehr das check_interval, sondern das retry_interval. Die Bedeutung ist allerdings dieselbe und legt den Abstand zwischen zwei Überprüfungen des Services fest.

active_checks_ enabled*

Legt fest, ob aktive Checks für diesen Service erlaubt sind.

passive_checks_ enabled*

Legt fest, ob passive Checks für diesen Service erlaubt sind.

check_period

Diese Direktive legt den Namen der Timeperiod fest, innerhalb derer der Service geprüft wird. Näheres dazu beschreibt der folgende Abschnitt.

obsess_over_service*

Legt fest, ob der mit der Direktive ocsp_command in der zentralen Nagios-Konfiguration definierte Befehl nach jedem Check ausgeführt werden soll oder nicht. Zum Thema Automatismus lesen Sie bitte das nächste Hinweisfeld weiter unten.

Tabelle 5.1

378

Direktiven zur Überwachung eines Services (*: optionale Direktiven) (Forts.)

Monitoring

Direktive

Bedeutung

check_freshness*

Gibt an, ob Nagios so genannte Freshness-Prüfungen für diesen Service durchführen soll. Freshness-Prüfungen stellen sicher, dass Nagios eine Überprüfung regelmäßig durchführt und die Ergebnisse somit immer auf einem aktuellen Stand, also »frisch«, sind.

freshness_threshold*

Legt das Intervall für die Freshness-Prüfungen fest.

event_handler*

Befehl, der als Event Handler für diesen Dienst ausgeführt wird.

event_handler_ enabled*

Gibt an, ob der event_handler aufgerufen wird oder nicht.

flap_detection_ enabled*

Aktiviert oder deaktiviert die Flap-Erkennung für diesen Dienst. Aktivierte Flap-Erkennung ist sinnvoll bei Diensten, die ihren Status häufig ändern, und verhindert, dass jedes Mal Benachrichtigungen erzeugt und Event Handler aufgerufen werden.

low_flap_threshold*

Legt die untere Grenze für die Flap-Erkennung fest.

high_flap_threshold*

Legt die obere Grenze für die Flap-Erkennung fest.

process_perf_data*

Aktiviert die Aufzeichnung von Daten über die Ausführung von Checks und Plugins. Damit können Sie z. B. deren Ausführungszeit messen.

retain_status_ information*

Legt fest, ob Statusinformationen über einen Programmneustart von Nagios erhalten bleiben sollen. Dieses Attribut ist nur wirksam, wenn in der zentralen Konfigurationsdatei die Direktive retain_state_information=1 gesetzt ist.

retain_nonstatus_ information*

Analog zum vorstehenden Attribut legt dieses Attribut fest, ob nicht statusbezogene Informationen zum Service einen Neustart von Nagios überdauern sollen.

notification_ interval

Definiert das Intervall, in dem Benachrichtigungen erzeugt werden, solange sich der Dienst nicht im Status OK befindet.

notification_period

Legt die Timeperiod fest, innerhalb derer Benachrichtigungen gesendet werden.

notification_ options*

Mit dieser Direktive können Sie angeben, zu welchen Status Benachrichtigungen gesendet werden sollen.

notifications_ enabled*

Aktiviert oder deaktiviert das Senden von Benachrichtigungen.

contacts

Liste von Kontakten, die im Falle von Statuswechseln benachrichtigt werden.

Tabelle 5.1

Direktiven zur Überwachung eines Services (*: optionale Direktiven) (Forts.)

379

5.1

5

Optimierung und Monitoring

Direktive

Bedeutung

contact_groups

Analog zur vorstehenden Direktive; übernimmt als Argument eine oder mehrere Contactgroups.

stalking_options*

Erlaubt die Aktivierung erweiterter Loggings durch Nagios. Dieses Attribut ist nur dann sinnvoll, wenn Sie eine eingehende Logfile-Analyse betreiben möchten, und erzeugt wesentlich mehr Logdaten als im normalen Betriebsmodus.

use*

Bindet ein Template ein.

required*

Ist der Wert 0, stellt die Service-Definition lediglich ein Template dar und wird von Nagios nicht als eigenständiger Dienst erkannt. Andere Services können dieses Template über die use-Direktive einbinden.

Tabelle 5.1

Direktiven zur Überwachung eines Services (*: optionale Direktiven) (Forts.)

Bei der Konfiguration von Nagios werden Sie unweigerlich darauf stoßen, dass Nagios zwischen verschiedenen Status von Hosts und Services unterscheidet. Damit sind nicht die vier Zustände gemeint, die Nagios in der Weboberfläche ausgibt (OK, CRITICAL, WARNING und UNKNOWN), sondern eine interne Zuordnung von Zuständen aufgrund verschiedener ermittelter Ereignisse und in Abhängigkeit von vorherigen Status. Sobald ein Objekt (Host oder Service) den Status OK verlässt, befindet es sich im Soft State, allerdings nur so lange, wie Nagios diesen Zustand nicht erneut überprüft hat. Kann Nagios den von OK abweichenden Status durch eine erneute Überprüfung bestätigen, liegt ein Hard State vor. Wechselt das betreffende Objekt vor der erneuten Überprüfung aus dem Soft State zurück in den Status OK, ist dies für Nagios ein Soft Recovery. Analog dazu liegt ein Hard Recovery vor, wenn ein Objekt von einem Hard State zurück zu OK wechselt. Wechselt ein Objekt von einem Hard State in einen anderen, nennt sich der Zustand Hard State Change. In beiden Fällen, dem Eintreten eines Soft State oder eines Hard State, erzeugt Nagios ein Event (Soft State Event oder Hard State Event). Für jedes Event kann ein eigener Event Handler definiert werden. Das kann ein Programm sein, das beim Eintreten eines Events ausgeführt wird. Der Ausfall eines überwachten Prozesses kann z. B. einen Event Handler aufrufen, der den Prozess neu startet. So sind beliebige Reaktionen auf Events möglich. Neben Events erzeugt Nagios beim Wechsel von Status auch Benachrichtigungen, die – in Abhängigkeit von der Konfiguration – den oder die zuständigen Administratoren über verschiedene Wege darüber informieren können, dass ein Problem vorliegt. Wichtig für das Verständnis der Arbeitsweise von Nagios ist in diesem Zusammenhang, dass Nagios immer nur dann eine Benachrichtigung erzeugt und den

380

Monitoring

entsprechenden Event Handler aufruft, wenn sich ein Wechsel von einem Status in einen anderen Status ergeben hat. Beim Wechsel in einen Soft State loggt Nagios diesen Vorfall, erzeugt aber keine Benachrichtigung. Beim Wechsel in einen Hard State wird dies entsprechend auf der Nagios-Oberfläche angezeigt, der Event Handler aufgerufen und eine Benachrichtigung versendet (sofern konfiguriert). Dies geschieht aber nur einmal, nämlich nach dem Wechsel in den Hard State. Ergibt eine erneute Überprüfung, dass sich Host oder Service immer noch in diesem Hard State befinden, erfolgt keine weitere Reaktion, erst wenn sich der Hard State ändert. Bei volatilen Services erzeugt Nagios bei jeder Überprüfung, die einen Hard State ergibt, eine Benachrichtigung und ruft den Event Handler auf. Der Fluch des Automatismus Das Verwenden von Event Handlern erscheint auf den ersten Blick praktisch und ermöglicht theoretisch das sich selbst heilende System. In der Praxis sieht die Situation aber leider anders aus. Sicher kann ein Event Handler für den Zustand »Festplatte voll« darin bestehen, durch Löschen überflüssiger Dateien Platz auf der Platte zu schaffen. Aber wie soll ein dummes Programm erkennen können, welche Daten überflüssig sind, ob die Platte wirklich wegen zu vieler Daten voll ist oder ob nicht viel eher ein Hardwaredefekt vorliegt, der den freien Plattenplatz rapide schrumpfen lässt? Ein gut gemeinter, dafür aber schlecht umgesetzter Event Handler kann mehr Schaden erzeugen als das eigentliche Event. Seien Sie deshalb vorsichtig und umsichtig beim Einsatz von Event Handlern.

Netzwerkchecks Die Standardkonfiguration von Nagios bringt eine vorgefertigte Konfiguration für die Prüfung des lokalen Hosts, also des Nagios-Servers, mit. Das ist natürlich wenig nützlich für die Überprüfung eines Servers im Internet. Wie weiter oben beschrieben, ist es für die kontinuierliche Überwachung eines Servers sinnvoll, den Nagios-Server nicht auf demselben System zu betreiben. Fällt der Server komplett aus, kann auch Nagios nicht mehr arbeiten. Benachrichtigungen und Überwachung für die spätere Analyse des Ausfalls sind damit auch nicht mehr möglich. Daher sollten Sie Nagios stets auf einem anderen System installieren und dieses System im Idealfall so platzieren, dass es die Sicht eines Benutzers einnimmt, also auf demselben Weg auf den zu überwachenden Server zugreift wie Benutzer. Das kann ein Rechner bei Ihnen unter dem Schreibtisch sein, der über die DSL-Leitung auf den zu überwachenden Server zugreift, oder ein V-Server im Internet. Im letzteren Fall sollten Sie einen anderen Provider wählen als den, bei dem der zu überwachende Server gehostet ist. Damit umgehen Sie den Fall, dass Probleme beim Provider zum Ausfall Ihres Servers führen, Nagios dies aber nicht erkennt, weil der Zugriff auf den zu überwachenden Server über interne Verbin-

381

5.1

5

Optimierung und Monitoring

dungen beim Provider führt und keine Aussage über die Erreichbarkeit aus dem Internet möglich ist. Zur Überwachung eines entfernten Systems müssen Sie im ersten Schritt eine Hostdefinition erstellen. Darin legen Sie das zu verwendende Template, den Hostnamen, einen Alias und die IP-Adresse des zu überprüfenden Systems an: define host{ use host_name alias address }

generic-host hardy hardy 192.168.0.20

Im zweiten Schritt definieren Sie die Services, die Nagios von außen auf diesem System überwachen soll, also die über das Netzwerk erreichbaren Dienste. In diesem Beispiel sind das der FTP-Server, der Apache-Webserver und der OpenSSH-Server. Zusätzlich ist es hilfreich, die Erreichbarkeit per ICMP zu überwachen, um auch beim Ausfall aller Dienste feststellen zu können, ob der Host netzwerktechnisch noch erreichbar ist. Damit lässt sich bei einem Ausfall eher eingrenzen, ob ein Problem des Hosts oder der Internetanbindung besteht. Die Service-Definitionen dafür sehen wie folgt aus: define service{ # Apache-Webserver use host_name service_description check_command } define service { # OpenSSH-Server host_name service_description check_command use } define service { # FTP-Server host_name service_description check_command use } define service {

382

generic-service hardy HTTP check_http

hardy SSH check_ssh generic-service

hardy FTP check_ftp generic-service

Monitoring

# ICMP host_name service_description check_command check_ping!100.0,20 use }

hardy PING

ð %!500.0,60 % generic-service

Die Zahlenwerte hinter den Überwachungsbefehlen geben die Schwellwerte an, die Nagios für das Festlegen der Status verwendet. Der erste Wert legt die Eintrittsbedingung für den Status WARNING fest, der zweite die des Status CRITICAL. Auf Betriebssystemebene übergibt Nagios dem jeweiligen Plugin den ersten Wert mit dem Kommandozeilenparamenter -w, den zweiten mit dem Parameter -c. Dies ist wichtig für die Entwicklung eigener Plugins. Gruppierung von Objekten Bei der Konfiguration von Nagios gibt es verschiedene Arten, die Objekte zu gruppieren und auf verschiedene Konfigurationsdateien aufzuteilen. Für kleine Infrastrukturen ist es am übersichtlichsten, alle Objekte, die zu einem Host gehören, in eine einzige Konfigurationsdatei zu speichern. Wenn Sie nur eine überschaubare Anzahl von Systemen überwachen möchten, legen Sie für jedes System eine eigene Konfigurationsdatei an und legen alle systemspezifischen Objekte darin ab, also insbesondere die Host- und Service-Definitionen. Sobald die zu überwachende Infrastruktur größere Ausmaße annimmt und die Anzahl der zu überwachenden Systeme unüberschaubar wird, führt dieser Ansatz auch zu einer unüberschaubaren Anzahl von Konfigurationsdateien. Dann ist es ratsam, die Objekte nach ihrem Typ zu sortieren, so dass es für alle Hosts eine eigene Konfigurationsdatei gibt, für alle Services eine weitere eigene etc. Wo Sie die Grenze ziehen, ist Auslegungssache. Für den Anfang ist der erste Ansatz übersichtlicher und intuitiver.

Speichern Sie die Objektdefinitionen in einer neuen Konfigurationsdatei im Verzeichnis /etc/nagios3/conf.d (z. B. .cfg), und starten Sie Nagios anschließend neu. # sudo /etc/init.d/nagios3 restart

Nach dem Neustart kennt Nagios den neuen Host und wird die konfigurierten Services in die Überwachung mit einbeziehen. Über die Nagios-Oberfläche können Sie dann den Status des Hosts einsehen (Abbildung 5.36). Um festzustellen, ob Nagios auch wirklich den korrekten Systemzustand anzeigt, machen Sie die Probe aufs Exempel: Stoppen Sie den FTP-Server auf dem überwachten System: # sudo /etc/init.d/proftpd stop

383

5.1

5

Optimierung und Monitoring

Abbildung 5.36

Der neue Host in der Überwachung

Nach der nächsten zyklischen Überprüfung wird Nagios dies anzeigen und – sofern konfiguriert – eine Benachrichtigung verschicken.

Abbildung 5.37

Der FTP-Dienst im Zustand CRITICAL

Um die Erreichbarkeit der extern erreichbaren Dienste zu überwachen, ist diese Konfiguration bereits ausreichend. Allerdings erlaubt sie lediglich das Erkennen von Fehlern, wenn diese eintreten. Ein vorausschauendes Monitoring wichtiger Systemparameter wie Speicherverbrauch, CPU-Last und Festplattenbelegung ist damit allerdings noch nicht möglich. Gerade diese Parameter erlauben aber bei einer sorgfältig konfigurierten Überwachung ein rechtzeitiges Eingreifen, so dass sich Fehler gar nicht erst im Ausfall von Diensten oder des Systems manifestieren müssen. Damit diese Parameter überwacht werden können, muss auf dem zu überwachenden System NRPE oder NSCA installiert und konfiguriert sein, so dass Nagios Befehle direkt auf dem System abrufen kann. Alternativ können Sie MRTG im Parallelbetrieb verwenden und die Parameter per SNMP auslesen. Das parallele Pflegen zweier Überwachungssysteme ist allerdings unnötiger Aufwand, da Nagios alles mitbringt, was für das Abfragen lokaler Parameter notwendig ist. NRPE NRPE, der Nagios Remote Plugin Executor, erlaubt das Ausführen von NagiosPlugins auf entfernten Systemen. Dazu läuft auf diesen Systemen ein NRPEDienst, der Anfragen eines Nagios-Servers entgegennimmt, die entsprechenden Prüfungen ausführt und das Ergebnis an den Nagios-Server zurücksendet. Damit Sie NRPE verwenden können, müssen Sie auf dem zu überwachenden System die folgenden Pakete installieren:

384

Monitoring

# sudo apt-get install nagios-nrpe-server nagios-plugins nagios-plugins-basic nagios-nrpe-plugin

ð

bzw. # emerge nagios-nrpe

Der NRPE-Dienst wird über die Datei /etc/nagios/nrpe.cfg konfiguriert – sowohl bei Ubuntu als auch unter Gentoo. Die Standardkonfiguration startet den Dienst auf TCP-Port 5666 und legt als Benutzerumgebung für den NRPE-Dienst den Benutzer und die Gruppe nagios fest. Die folgenden Direktiven in der Konfigurationsdatei sollten Sie in jedem Fall beachten. allowed_hosts=192.168.0.22

Mit dieser Direktive legen Sie die IP-Adresse fest, von der aus auf den NRPEDienst zugegriffen werden darf. Dies ist zwar ein schwacher Schutz vor Angriffen, schränkt aber die Erreichbarkeit des Dienstes und damit die Möglichkeit für einen Angreifer, den Dienst aufzufinden, stark ein. An der Einstellung der folgenden Direktive sollten Sie niemals etwas ändern: dont_blame_nrpe=0

Wenn der Wert dieser Direktive 1 ist, nimmt der NRPE-Dienst beliebige Befehle über das Netzwerk entgegen und führt diese auf der lokalen Maschine aus. Eine bessere Angriffsmöglichkeit gibt es nicht. Zwar werden die Befehle mit den Rechten des Benutzers nagios ausgeführt, aber auch damit kann ein Angreifer schon erheblichen Schaden anrichten. Für die Einrichtung der Nagios-Überwachung ist ein erhöhter Loglevel hilfreich, weswegen Sie über die Direktive ... debug=1

... den NRPE-Dienst anweisen, seine Logdaten an den lokalen Syslog-Daemon zu senden. Die Befehle, die NRPE von Nagios entgegennimmt und ausführt, müssen – sofern die Direktive dont_blame_nrpe nicht gesetzt ist – in der Konfigurationsdatei definiert sein. NRPE bringt eine kleine Anzahl von Beispielen mit: 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

385

5.1

5

Optimierung und Monitoring

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

Bei diesen Beispielen sind die Schwellwerte fest in der Konfigurationsdatei von NRPE abgelegt, erkennbar an den Zahlenwerten bei den Befehlen. NRPE ist unter Ubuntu standardmäßig mit der Unterstützung variabler Argumente übersetzt, was das Senden individueller Befehle vom Nagios-Server voraussetzt. Da dafür dont_blame_nrpe aktiviert sein muss, ist von dieser Betriebsart dringend abzuraten. Sie können die Funktionstüchtigkeit von NRPE testen, indem Sie von dem Nagios-Server, der in der nrpe.cfg als autorisierter Host eingetragen ist, manuell Überprüfungen per NRPE anstoßen. Verwenden Sie dazu das Plugin check_nrpe mit einem auf dem zu überprüfenden Host in der NRPE-Konfiguration eingetragenen Befehl. Unter Ubuntu befinden sich die Nagios-Plugins wie das NRPEPlugin im Verzeichnis /usr/lib/nagios/plugins, unter Gentoo im Verzeichnis /usr/ nagios/libexec. Der Aufruf des Plugins mit dem Parameter -h gibt einen Hilfetext aus, der die korrekte Verwendung erklärt: # /usr/lib/nagios/plugins/check_nrpe -h NRPE Plugin for Nagios Copyright (c) 1999-2008 Ethan Galstad ([email protected]) Version: 2.12 Last Modified: 03-10-2008 License: GPL v2 with exemptions (-l for more info) SSL/TLS Available: Anonymous DH Mode, OpenSSL 0.9.6 or ð higher required Usage: check_nrpe -H [-n] [-u] [-p ] [-t ] ð [-c ] [-a ] Options: -n = Do no use SSL -u = Make socket timeouts return an UNKNOWN state ð instead of CRITICAL = The address of the host running the NRPE daemon [...] Note: This plugin requires that you have the NRPE daemon running on the remote host. You must also have configured the daemon to associate a specific plugin command with the [command] option you are specifying here. Upon receipt of the [command] argument, the NRPE daemon will run the appropriate plugin command and send the plugin

386

Monitoring

output and return code back to *this* plugin. This allows you to execute plugins on remote hosts and 'fake' the results to make Nagios think the plugin is being run locally.

Neben der Erläuterung der korrekten Syntax ist der letzte Absatz des Hilfetextes interessant, da dort die Funktionsweise des Plugins beschrieben ist. Hilfe zu den Nagios-Plugins Der Kommandozeilenparameter -h ruft bei allen Nagios-Plugins einen Hilfetext auf. Da alle Nagios-Plugins ausführbare Programme sind, können Sie auf der Kommandozeile alle Plugins ausführen, was bei der Implementierung neuer Überprüfungen oder der Entwicklung eigener Plugins enorm hilfreich ist, da Sie auf der Kommandozeile umgehend eine Rückmeldung erhalten. Insbesondere bei Plugins, die individuelle Schwellwerte als Parameter erwarten, ist die Hilfedatei eine gute Referenz.

Auf dem zu überwachenden System können Sie im Syslog die Logausgaben des NRPE-Servers kontrollieren: # sudo tail -f /var/log/syslog Sep 6 03:13:14 hardy nrpe[9560]: Starting up daemon Sep 6 03:13:14 hardy nrpe[9560]: Listening for connections on port 5666 Sep 6 03:13:14 hardy nrpe[9560]: Allowing connections from: ð 192.168.0.22

ð

Führen Sie auf dem Nagios-Server das Plugin nrpe_check aus, und übergeben Sie einen Befehl, der nicht in der nrpe.cfg auf dem Zielsystem konfiguriert ist: # /usr/lib/nagios/plugins/check_nrpe -H 192.168.0.20 -c foobar NRPE: Command 'foobar' not defined

Im Syslog des NRPE-Servers finden Sie die Angabe, dass der empfangene Befehl nicht bekannt ist und die Anfrage daher verworfen wurde: Sep 6 03:14:22 hardy nrpe[9568]: port 28349 Sep 6 03:14:22 hardy nrpe[9568]: Sep 6 03:14:22 hardy nrpe[9568]: Sep 6 03:14:22 hardy nrpe[9568]: 'foobar' to be run... Sep 6 03:14:22 hardy nrpe[9568]: Sep 6 03:14:22 hardy nrpe[9568]: Command 'foobar' not defined Sep 6 03:14:22 hardy nrpe[9568]: closed.

Connection from 192.168.0.22

ð

Host address is in allowed_hosts Handling the connection... Host is asking for command ð NRPE: Command 'foobar' not defined Return Code: 2, Output: NRPE: ð Connection from 192.168.0.22

ð

387

5.1

5

Optimierung und Monitoring

Anders sieht es aus, wenn Sie einen gültigen Befehl ausführen: # /usr/lib/nagios/plugins/check_nrpe -H 192.168.0.20 -c check_total_procs PROCS OK: 68 processes

ð

Das Plugin erhält vom NRPE-Server eine gültige und sinnvolle Antwort, und auf dem NRPE-Server gibt es einen entsprechenden Eintrag im Syslog: Sep 6 03:17:44 hardy nrpe[9649]: Connection from 192.168.0.22 ð port 34493 Sep 6 03:17:44 hardy nrpe[9649]: Host address is in allowed_hosts Sep 6 03:17:44 hardy nrpe[9649]: Handling the connection... Sep 6 03:17:44 hardy nrpe[9649]: Host is asking for command ð 'check_total_procs' to be run... Sep 6 03:17:44 hardy nrpe[9649]: Running command: ð /usr/lib/nagios/plugins/check_procs -w 150 -c 200 Sep 6 03:17:44 hardy nrpe[9649]: Command completed with return ð code 0 and output: PROCS OK: 68 processes Sep 6 03:17:44 hardy nrpe[9649]: Return Code: 0, Output: PROCS ð OK: 68 processes Sep 6 03:17:44 hardy nrpe[9649]: Connection from 192.168.0.22 ð closed.

NRPE funktioniert augenscheinlich und kann jetzt für die Überwachung durch Nagios verwendet werden. Unter Ubuntu sind zwei verschiedene Befehle für check_nrpe konfiguriert, einmal für den Aufruf mit einem Argument (check_ nrpe_1arg) und einmal für den Aufruf mit mehreren Argumenten (check_nrpe). Die erste Version ist für Befehle bestimmt, die außer dem Hostnamen keine weiteren Argumente benötigen und bei denen die Konfiguration der Schwellwerte in der NRPE-Konfiguration abgelegt ist. Die zweite Version benötigt den unsicheren dont_blame_nrpe-Modus und ist daher für den Betrieb nicht zu empfehlen. Verwenden Sie immer check_nrpe_1arg, und konfigurieren Sie die Überwachungsbefehle fest in der nrpe.cfg auf den zu überwachenden Systemen. Um die unter Ubuntu bereits vorkonfigurierten Überwachungsbefehle von NRPE in die Überwachung aufzunehmen, erweitern Sie die Konfigurationsdatei des zu überwachenden Systems um die folgenden Objekte: define service { # Anzahl der aktiven Prozesse host_name hardy service_description Prozesse check_command check_nrpe_1arg!check_total_procs use generic-service }

388

Monitoring

define service { # Load host_name service_description check_command use } define service { # eingeloggte Benutzer host_name service_description check_command use } define service { # Zombie-Prozesse host_name service_description check_command use } define service { # Root-Partition host_name service_description check_command use }

hardy Load check_nrpe_1arg!check_load generic-service

hardy Benutzer check_nrpe_1arg!check_users generic-service

hardy Zombies check_nrpe_1arg!check_zombie_procs generic-service

hardy

ð check_nrpe_1arg!check_sda2 generic-service

Das letzte Objekt müssen Sie an die in Ihrem System korrekte Root-Partition anpassen. Dazu reicht es allerdings nicht, den Aufruf auf dem Nagios-Server anzupassen – in der NRPE-Konfiguration auf dem Zielsystem muss die entsprechende Zeile ebenfalls angepasst werden: command[check_sda2]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/sda2

ð

Die Werte bedeuten, dass bei 20 % freiem Speicherplatz Nagios den Status WARNING für die Partition anzeigt, ab 10 % den Status CRITICAL. Nach der Änderung der Konfigurationsdateien müssen Sie den Nagios-Server und den NRPE-Server auf dem jeweiligen System neu starten: # sudo /etc/init.d/nagios3 restart # sudo /etc/init.d/nagios-nrpe-server restart

389

5.1

5

Optimierung und Monitoring

Nach dem Ausführen aller Kommandos zeigt Nagios alle gewünschten Informationen für den Host an.

Abbildung 5.38

Status-Abfragen per NRPE

Sichere Kommunikation NRPE ist unter Ubuntu und Gentoo bereits mit SSL-Unterstützung kompiliert (unter Gentoo allerdings nur dann, wenn das SSL-USE-Flag gesetzt ist). Damit findet die Kommunikation zwischen Nagios-Server und dem NRPE-Dienst verschlüsselt statt. Die SSL-Unterstützung geht allerdings nicht so weit, dass Nagios oder der NRPEDienst gegenseitig Zertifikate verwenden oder überprüfen. Damit ist eine Authentifizierung über SSL nicht möglich. Bedenken Sie diese Einschränkung bei der Einschätzung der Sicherheit.

NSCA Bei NRPE läuft die Kommunikation vom Nagios-Server zum überwachten Host. Diese Richtung ist ideal, wenn der Nagios-Server in einem internen Netzwerk steht und einen Server im Internet überwacht. Alle Zugriffe finden aus dem internen Netz ins Internet statt, so dass keine Löcher in die Firewall gebohrt werden müssen. Diese Kommunikationsrichtung ist aber nicht immer angebracht. In größeren Infrastrukturen kann es sein, dass sich der Nagios-Server in einem DMZ-Bereich befindet, neben den dort befindlichen Hosts aber auch Systeme im internen Netzwerk überwachen muss. In diesem Fall müsste ein Zugriff des Nagios-Servers durch die Firewall ins interne Netz geschaffen werden, was ein potentielles Sicherheitsrisiko darstellt. Aus diesem Grund ist in diesem Fall NRPE nicht das Mittel der Wahl, sondern NSCA, der Nagios Service Check Acceptor. NSCA geht den umgekehrten Weg und sendet Daten vom überwachten System zum NagiosServer. Dazu muss auf dem Nagios-Server die Unterstützung externer Befehle aktiviert sein. Diese Unterstützung erlaubt das Absetzen von Befehlen über die Nagios-Oberfläche, z. B. um eine Downtime zu planen oder um die Ausführung

390

Monitoring

eines Checks zu einem bestimmten Zeitpunkt zu veranlassen. Aus Sicherheitsgründen ist die Unterstützung externer Befehle unter Ubuntu deaktiviert. Um sie zu aktivieren, muss zunächst in der zentralen Konfigurationsdatei von Nagios die Direktive check_external_commands den Wert 1 zugewiesen bekommen. Damit wird Nagios angewiesen, in der Datei /var/lib/nagios3/rw/nagios.cmd nach Befehlen zu suchen. Diese Befehle können über die Weboberfläche in diese Datei eingetragen werden oder vom NSCA-Dienst, der auf dem Nagios-Server laufen muss, wenn NSCA zum Einsatz kommt. Aus unerklärlichen Gründen sind die Dateisystem-Berechtigungen auf die Datei nagios.cmd unter Ubuntu nach der Installation so gesetzt, dass das Aktivieren der externen Befehle in der Konfigurationsdatei allein nicht dazu führt, dass Nagios damit umgehen kann. Sie müssen darüber hinaus noch die Dateisystem-Berechtigungen der Datei korrigieren: # sudo /etc/init.d/nagios3 stop # sudo dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw # sudo dpkg-statoverride --update --add nagios nagios 751 ð /var/lib/nagios3 # sudo /etc/init.d/nagios3 start

ð

Unter Ubuntu installieren Sie NSCA über das gleichnamige Paket: # sudo apt-get install nsca

Das Paket enthält den NSCA-Server, der auf dem Nagios-Server laufen muss und die Verbindungen des NSCA-Clients auf dem zu überwachenden Server entgegennimmt. Auf beiden Systemen muss dieses Paket installiert werden, der Server muss allerdings nur auf dem Nagios-Server laufen. Daher sollten Sie auf dem zu überwachenden System nach der Installation den NSCA-Server wieder anhalten und die Init-Skripte für den automatischen Start entfernen: # sudo /etc/init.d/nsca stop # sudo update-rc.d -f nsca remove Removing any system startup links for /etc/init.d/nsca ... /etc/rc2.d/K16nsca /etc/rc3.d/K16nsca /etc/rc4.d/K16nsca /etc/rc5.d/K16nsca

Die Konfigurationsdatei von NSCA liegt nach der Installation direkt im etc-Verzeichnis (/etc/nsca.cfg). Das ist arg unglücklich, da die thematisch verwandten Konfigurationsdateien im Verzeichnis /etc/nagios liegen. Der Übersichtlichkeit halber sollten Sie daher die Datei in dieses Verzeichnis verschieben: # sudo mv /etc/nsca.cfg /etc/nagios/

391

5.1

5

Optimierung und Monitoring

Damit der NSCA-Dienst die Datei auch findet, müssen Sie anschließend das Startskript des Dienstes entsprechend anpassen. Ändern Sie dazu in der Datei /etc/init.d/nsca den Wert der Variablen CONF in den neuen Ort der Konfigurationsdatei: CONF=/etc/nagios/nsca.cfg

Anschließend starten Sie den Service neu ... # sudo /etc/init.d/nsca restart

... und prüfen das Ergebnis: # ps ax|grep nsca|grep -v grep 9191 ? Ss 0:00 /usr/sbin/nsca --daemon -c /etc/nagios/nsca.cfg

Voilà, der Dienst verwendet die verschobene Konfigurationsdatei. Bei Gentoo liegen die Konfigurationsdateien von NSCA bereits im »richtigen« Verzeichnis (/etc/nagios). Unter Gentoo installieren Sie NSCA über das Paket nagios-nsca: # sudo emerge nagios-nsca

In der Konfigurationsdatei müssen Sie unter Ubuntu den Pfad zu der Datei anpassen, die die externen Befehle enthält – standardmäßig ist dieser Pfad falsch: command_file=/var/lib/nagios3/rw/nagios.cmd

Sowohl unter Ubuntu als auch unter Gentoo sollten Sie bei der Verwendung von NSCA zwingend ein Passwort vergeben, mit dem der Client die an den Server geschickten Befehle verschlüsselt. Nur wenn Client und NSCA-Server dasselbe Passwort verwenden, erkennt der Server die Befehle als gültig an. Dies stellt ein zusätzliches Sicherheitsmerkmal dar und ist in jedem Fall eine gute Idee. Auf dem NSCA-Server – egal ob Gentoo oder Ubuntu – vergeben Sie daher in der Konfigurationsdatei des NSCA-Dienstes ein Passwort und wählen eine sichere Verschlüsselungsmethode aus. Der Standardwert (XOR) ist nicht sicher. In diesem Beispiel ist das Passwort foo (Achtung, auch nicht sicher!), und der verwendete Algorithmus ist AES256, ein als sicher geltender Industriestandard. password=foo decryption_method=16

Nach der Änderung muss der NSCA-Server neu gestartet werden. Auf dem NSCA-Client, also dem von Nagios zu überwachenden System, erstellen Sie eine

392

Monitoring

Datei /etc/nagios/send_nsca.cfg (unter Gentoo ist diese Datei bereits vorhanden) und schreiben die folgenden beiden Direktiven hinein: password=foo encryption_method=16

Damit haben Sie das Gegenstück zu den Einstellungen auf dem NSCA-Server erstellt. Sie können die Funktionalität von NSCA über die Kommandozeile testen: # echo "hardy#Prozesse#0#OK" | send_nsca -H 192.168.0.22 -d '#' -c send_nsca.cfg 1 data packet(s) sent to host successfully.

ð

Dieser manuelle Test zeigt auch das Format der NSCA-Meldungen: Hostname, Service, Returnwert und Status. Das Programm send_nsca sendet die Daten an den mit dem Parameter -H angegebenen Host, verwendet dabei das mit dem Parameter -d festgelegte Zeichen als Trennzeichen in dem Datensatz und übernimmt seine Einstellungen aus der mit dem Parameter -c spezifizierten Konfigurationsdatei. Auf dem Nagios- und NSCA-Server erscheint im Syslog eine entsprechende Meldung: Sep 7 18:20:11 hardy2 nsca[11239]: Connection from 192.168.0.20 ð port 11162 Sep 7 18:20:11 hardy2 nsca[11239]: Handling the connection... Sep 7 18:20:12 hardy2 nsca[11239]: SERVICE CHECK -> Host Name: ð 'hardy', Service Description: 'Prozesse', Return Code: '0', ð Output: 'OK' Sep 7 18:20:12 hardy2 nsca[11239]: End of connection... Sep 7 18:20:12 hardy2 nagios3: EXTERNAL COMMAND: ð PROCESS_SERVICE_CHECK_RESULT;hardy;Prozesse;0;OK

Um Services mit NSCA zu überwachen, müssen Sie diese auf dem Nagios-Server entsprechend konfigurieren und auf dem zu überwachenden System regelmäßig das Programm send_nsca ausführen, normalerweise per Cron-Job. Da das Verwenden externer Befehle in Nagios allerdings ein grundsätzliches Sicherheitsrisiko darstellt, sollte NSCA nur in begründeten Ausnahmefällen zum Einsatz kommen. Kennwörter, Dateien und die Sicherheit Die NSCA-Dateien, die das NSCA-Passwort enthalten, müssen gegen unbefugten Zugriff geschützt werden. Sie sollten daher unbedingt die Dateiberechtigungen der Dateien so restriktiv wie möglich festlegen.

393

5.1

5

Optimierung und Monitoring

Eigene Plugins Falls Ihnen die vorhandenen Plugins von Nagios nicht reichen, können Sie einfach eigene schreiben. Dabei gibt es nur einige wenige Rahmenbedingungen zu beachten: 왘

Das Plugin muss ein ausführbares Programm sein, wobei die verwendete Programmiersprache unerheblich ist. Vom Bash-Skript bis zum Java-Programm ist alles möglich, wenngleich nicht alles sinnvoll. Achten Sie darauf, dass das Plugin über korrekt gesetzte Dateirechte verfügt, so dass der Nagios- oder der NRPE-Daemon das Plugin ausführen können.

왘

Die Ausgabe des Programms darf nicht länger als 80 Zeichen sein, muss in einer Zeile ausgegeben werden und auf die Standardausgabe gehen (stdout).

왘

Das Plugin muss einen der vier möglichen Status zurückgeben: OK, WARNING, CRITICAL, UNKNOWN.

Neben diesen drei verpflichtenden Bedingungen sollte ein selbstgeschriebenes Plugin über verschiedene Verbosity-Level verfügen und bei Bedarf einen Hilfetext ausgeben, analog zu den Hilfetexten der Standard-Plugins. Die einfachste Form eines Plugins ist ein selbstgewählter Befehl, der über NRPE ausgeführt wird. Eine nützliche Information ist z. B. die Ausgabe von uname, da sich darüber der Systemname und die Versionsnummer sowie andere Informationen über den aktiven Kernel eines Systems auslesen lassen. Um diese Informationen per NRPE von einem entfernten System auszulesen, definieren Sie auf diesem System in der Datei /etc/nagios/nrpe.cfg einen neuen Befehl und starten den NRPE-Dienst anschließend neu: command[check_uname]=/bin/uname -a

Unter dem Namen check_uname kann der Nagios-Server diesen Befehl ausführen. Auf dem Nagios-Server fügen Sie einen neuen Service zur Konfiguration des Hosts hinzu (den Neustart des Nagios-Dienstes nicht vergessen): define service { host_name service_description check_command use }

hardy uname check_nrpe_1arg!check_uname generic-service

Das Ergebnis lässt sich nach der ersten Überprüfung dieses neuen Services durch Nagios auf der Nagios-Oberfläche betrachten (letzte Zeile in Abbildung 5.39). uname ist natürlich genau genommen kein standardkonformes Plugin, da es weder einen Status zurückliefert noch eine Aussage über die Qualität eines

394

Monitoring

Dienstes macht, es zeigt aber sehr schön, wie flexibel mit Nagios Informationen von einem System abgefragt werden können.

Abbildung 5.39

5.1.5

Die Ausgabe von »uname« von einem entfernten Rechner

Webserver-Statistiken

Neben der Überwachung betriebskritischer Parameter sind auf einem Webserver die Zugriffe auf die Website von besonderer Bedeutung, denn aus den Logdateien, die der Apache-Webserver über die Zugriffe der Benutzer anlegt, kann der Betreiber einer Website detaillierte Informationen über das Verhalten dieser Benutzer ermitteln. Die wichtigsten Basiskennzahlen im Online-Geschäft sind Page Impressions und Visits. Page Impressions geben die Anzahl der Seitenabrufe an, die Benutzer von einem Webserver angefordert haben. Eine Page Impression bezeichnet dabei den Abruf einer kompletten Webseite inklusive der darin enthaltenen Elemente. Darin unterscheidet sich die Kenngröße Page Impression von der reinen Abrufzahl, wie sie ein Webserver in der Logdatei vermerkt, denn der Webserver erzeugt pro abgerufenem Element einen Eintrag, so dass der Abruf einer Webseite, die verschiedene Grafiken und eingebundene weitere Webseiten enthält, zu entsprechend vielen Einträgen in der Logdatei des Servers führt. Der Begriff Page Impression wird insbesondere dann interessant, wenn Sie mit Ihrer Website durch Werbung Geld verdienen möchten und die Seitenzugriffe daher nach dem IVW-Verfahren3 ermitteln. In diesem Zusammenhang gibt es noch den Begriff Visit, der einen eindeutigen Besuch auf einer Website beschreibt. Über die Page Impressions und die Visits lassen sich Beliebtheit der Site, Beliebtheit von Unterseiten und das Besucherverhalten ermitteln. Das IVWVerfahren ist ein kostenpflichtiger Dienst, der über proprietäre Systeme der IVW bereitgestellt wird. Grundlage des Verfahrens ist ein so genanntes Zählpixel, das in jede zu überwachende Webseite eingebaut wird. Dahinter verbirgt sich eine 1 × 1 Pixel große transparente Grafikdatei, die auf einem Webserver der IVW liegt. Über entsprechende Aufrufparameter bei der Verlinkung können die Auf3 http://www.ivw.de/

395

5.1

5

Optimierung und Monitoring

rufe des Zählpixels jeder überwachten Website zugeordnet werden. In der Homepage des Nachrichtenmagazins SPIEGEL ist die Verlinkung des IVW-Pixels die folgende:

Bei der ARD sieht es ähnlich aus:

Der Aufruf einer Webseite, in der das Zählpixel verlinkt ist, führt somit also dazu, dass auf dem jeweiligen IVW-Host (*.ivwbox.de) das Pixel mit den übergebenen URL-Parametern abgerufen wird. Über IP-Adresse, Browserkennung und, je nach Konfiguration der Webseite, auch Cookies des Benutzers lassen sich mit diesen Daten Page Impressions und Visits ermitteln. Die Systeme, auf denen die Webserver mit den Zählpixeln laufen, sind so genannte IVW-Boxen, für IVW-Kunden abgeschlossene Systeme, die lediglich den Webdienst zur Verfügung stellen und über einen Socket den Logstrom des Webservers zur weiteren Auswertung an die IVW und den Betreiber der Website übermitteln. Die IVW ermittelt aus diesen Daten die auf der IVW-Website monatlich veröffentlichten Zugriffszahlen, der Systembetreiber kann mit den Daten eigene Auswertungen fahren. Das IVW-Verfahren lässt sich vom Benutzer leicht umgehen. Erweiterungen für gängige Browser, wie z. B. AdBlock Plus4 für Firefox, erlauben das Blockieren von Elementen, die der Browser dann gar nicht mehr abruft. Da die IVW-Auswertung allein durch die Implementierung der Überwachungsfunktion eine kostspielige Angelegenheit sein kann, lohnt sich das Verfahren in der Regel nur für große Anbieter. Eine Alternative dazu bietet der Google-Dienst Google Analytics. Dabei handelt es sich um einen kostenlosen Service, der über in Webseiten eingebetteten JavaScript-Code und den Gebrauch von Cookies sehr detaillierte Auswertungen über Zugriffe und das Benutzerverhalten auf einer Website darstellt. Die Besonderheit bei der Verwendung von Google Analytics ist, dass die erfassten Daten auf Servern von Google gesammelt und ausgewertet werden. Interessant sind in diesem Zusammenhang die Nutzungsbedingungen (Stand September 2008): »Die durch den Cookie erzeugten Informationen über Ihre Benutzung dieser Website (einschließlich Ihrer IP-Adresse) wird an einen Server von Google in 4 https://addons.mozilla.org/de/firefox/addon/1865

396

Monitoring

den USA übertragen und dort gespeichert. Google wird diese Informationen benutzen, um Ihre Nutzung der Website auszuwerten, um Reports über die Websiteaktivitäten für die Websitebetreiber zusammenzustellen und um weitere mit der Websitenutzung und der Internetnutzung verbundene Dienstleistungen zu erbringen. Auch wird Google diese Informationen gegebenenfalls an Dritte übertragen, sofern dies gesetzlich vorgeschrieben ist oder soweit Dritte diese Daten im Auftrag von Google verarbeiten.« Ob und inwieweit dies für einen Website-Betreiber relevant ist, muss jeder selbst entscheiden. Eine Alternative bieten Auswertungsprogramme, die die Logfiles des ApacheWebservers auswerten. Ein bekannter Vertreter dieser Art ist der Webalizer.5 Das Problem hierbei liegt – wie oben beschrieben – darin, dass weder Apache noch Webalizer Zugriffe einzelnen Webseiten zuordnen können und so keine belastbare Aussage über die tatsächliche Zahl von Zugriffen möglich ist. Ob ein Abruf direkt im Sinne einer Page Impression oder nur indirekt durch automatisches Nachladen eines Skriptes erfolgt ist, kann durch Logfile-Analyse nicht ermittelt werden. Ebenso kann eine kontinuierliche Trendmessung durch eine Änderung an der Struktur der Webseiten leicht ad absurdum geführt werden. Führt ein Relaunch eines Webauftritts dazu, dass jede Seite wesentlich mehr Elemente vom Server benötigt, erhöht sich die Zahl der Zugriffe auf den Server allein durch die Umstellung der Website und nicht dadurch, dass mehr Benutzer auf die Seite zugreifen. Nichtsdestotrotz ist ein Tool wie Webalizer eine einfache Möglichkeit, rudimentäre Auswertungen über die Nutzung einer Website zu erstellen, und wenn Sie die Einschränkungen dieser Methode kennen und sich darüber im Klaren sind, spricht nichts dagegen, Logfiles mit dem Webalizer auszuwerten. Für den Hausgebrauch reicht das allemal. Webalizer ist als Paket für Ubuntu und Gentoo verfügbar: # sudo apt-get install webalizer # sudo emerge webalizer

Die Konfigurationsdatei liegt unter Ubuntu im Verzeichnis /etc/webalizer (webalizer.conf), unter Gentoo muss sie händisch erstellt werden. Eine Beispieldatei findet sich allerdings unter /usr/portage/distfiles/webalizer.conf.gz. Erstellen Sie unter Gentoo das Verzeichnis /etc/webalizer, und entpacken Sie die Datei in dieses Verzeichnis.

5 http://www.webalizer.com/

397

5.1

5

Optimierung und Monitoring

# sudo mkdir /etc/webalizer # sudo zcat /usr/portage/distfiles/webalizer.conf.gz > /etc/webalizer/webalizer.conf

ð

Webalizer sollte regelmäßig über die archivierten Logdateien des Apache laufen. Wenn Sie die Logdateien jede Nacht rotieren, sollten Sie auch jede Nacht den Webalizer laufen lassen. Das Programm ist so intelligent, zusammenhängende Logdateien erkennen zu können und daraus eine kontinuierliche Historie zu erstellen. Die Grundkonfiguration beschränkt sich auf wenige Handgriffe und ist bei beiden Distributionen gleich. Die erste wichtige Direktive legt die Logdatei fest, die Webalizer zur Auswertung verwendet. LogFile /var/log/apache2/access.log.1

Geben Sie dort den Namen der Logdatei als Parameter an. Wenn Sie über Ihren Rotatelog-Mechanismus eine andere als die standardmäßig eingetragene Logdatei erzeugen, müssen Sie den Wert entsprechend anpassen. Praktisch ist, dass Webalizer auch eine gepackte Logdatei als Parameter akzeptiert. Das erspart das händische oder skriptgesteuerte Entpacken von rotierten Dateien. Webalizer entpackt die Datei selbständig für die Auswertung und packt diese nach der Arbeit wieder zusammen. Die folgende Direktive legt das Verzeichnis fest, in dem Webalizer die Ausgaben abspeichert. Da die Ausgaben im HTML-Format erzeugt werden, sollte sich das Verzeichnis im DocumentRoot Ihres Webservers befinden: OutputDir /var/www/webalizer

Für das Auge ist die Angabe ReportTitle Usage statistics for wichtig, denn damit können Sie die Überschrift der Statistik anpassen. An diesen Text wird der Wert der Direktive HostName angehängt. Das Problem, dass jede geladene Grafik einen Abruf erzeugt, lässt sich zumindest teilweise über die Direktive PageType abfangen. Mit dieser Direktive teilen Sie Webalizer mit, welcher Dateityp als Seitenabruf gewertet werden soll. Dabei sind auch Wildcards möglich. Allerdings lässt sich damit das Problem automatisch geladener Seiten nicht umgehen. PageType PageType PageType PageType PageType PageType PageType

398

htm* cgi phtml jsp php3 pl php

Monitoring

Die weiteren Einstellungen geben Ihnen die Möglichkeit, die Ausgabe des Webalizer individuell anzupassen. Verwenden Sie die installierte Konfigurationsdatei als Ausgangspunkt, darin ist jede Direktive ausführlich erläutert. Nach Fertigstellen der Konfiguration starten Sie den Webalizer. Je nach Größe der Logdateien kann ein Durchlauf recht lange dauern. Als Beispiel: Auf einem Intel Core 2 Duo mit 2,16 GHz dauert das Auswerten einer 7 Gigabyte großen Datei mit ca. 30.000.000 Logeinträgen knapp acht Stunden – wobei eine solche Logdatei zugegebenermaßen nicht repräsentativ ist und von einem Hochlastwebserver stammt, der im Monat Abrufe in dreistelliger Millionenhöhe beantwortet. Nach Abschluss der Auswertung befinden sich im als Ausgabeverzeichnis konfigurierten Verzeichnis HTML- und PNG-Dateien, die über einen Webbrowser abgerufen werden können. Die Startseite zeigt die monatliche Übersicht (Abbildung 5.40).

Abbildung 5.40

Die Monatsübersicht des Webalizer

Nach Auswählen eines Monats führt Webalizer zur Detailansicht des Monats mit vielen Einzelansichten. In der Standardkonfiguration sind dies eine Übersicht über die Abrufe pro Tag (Abbildung 5.41) und pro Stunde (Abbildung 5.42) sowie verschiedene tabellarische Auswertungen der Zugriffe im betreffenden Monat. Insbesondere die Stundenübersicht ist für den Systembetreiber interessant, denn daraus lässt sich sehr genau ablesen, wann die Zeit des geringsten Zugriffs auf die Website ist. In dieser Zeit sollten notwendige Wartungsarbeiten stattfinden, die den Service unterbrechen oder das System belasten könnten.

399

5.1

5

Optimierung und Monitoring

Typische Arbeiten sind das Rotieren von Logdateien, das – je nach Serverdienst – zu einem kurzen Ausfall des Dienstes führen kann. Ressourcenintensive Arbeiten wie ein Backup können dazu führen, dass die Antwortzeit des Webservers oder anderer wichtiger Dienste leiden.

Abbildung 5.41

Die Tagesübersicht über die Zugriffe

Abbildung 5.42

Die Stundenübersicht des Webalizer

Neben den Statistiken über Abrufe generiert der Webalizer in der Standardkonfiguration auch noch eine Übersicht über die Länder, aus denen die Zugriffe stattgefunden haben (Abbildung 5.43). Das kann aus Marketinggründen interessant sein, etwa um den Erfolg der Internationalisierung der Website zu überprüfen.

400

Optimierung

Abbildung 5.43

5.2

Übersicht über die zugreifenden Länder

Optimierung

Trotz einer Überwachung mit Tools wie MRTG und Nagios kommt es beim Betrieb eines Servers immer wieder zu unerwarteten Problemen. Hardware kann plötzlich ausfallen, ein Angriff kann so viele Systemressourcen verbrauchen, dass die Antwortzeiten des Servers einbrechen, eine fehlerhaft programmierte Anwendung oder Webapplikation kann zu einem Speicherloch werden, ein unbedarfter Benutzer führt einen Befehl mit weitreichenden Folgen aus etc. Die Möglichkeiten sind vielfältig, und in solchen Fällen hilft nur eine schnelle Diagnose und Reaktion. MRTG ist für so einen Fall gänzlich ungeeignet, und Nagios hilft auch nur bedingt, denn es zeigt lediglich die Parameter an, für die es konfiguriert ist. Eine manuelle und flexible Diagnose ist damit nicht möglich. Es gibt eine Reihe von kleinen Programmen, die zumindest eine erste Diagnose in Fehlerfällen ermöglichen. Zunächst sind das die praktischen Helferlein, die jeder Linux-Distribution beiliegen, wie top, df, netstat etc., mit denen sich die wichtigsten Parameter des Betriebssystems in Echtzeit auslesen lassen. Mit top beispielsweise kann man im Handumdrehen wildgewordene Prozesse identifizieren, die zu viel CPU-Zeit oder Speicher verbrauchen. Sind die betreffenden Prozesse identifiziert, kann es sinnvoll sein, dem Problem näher auf den Grund zu gehen. Bei einem Webserver unter Volllast ist dabei insbesondere und häufig der Apache von Interesse, bei einem LAMP-System darüber hinaus noch die MySQLDatenbank. Für beide Server existieren verschiedene Tools zur Echtzeitanalyse. top bietet zwar einen guten Überblick über die allgemeine Lage des Systems, stößt aber beispielsweise bei der Aussage über I/O-Aktivitäten an seine Grenzen. Die Kopfzeilen von top geben zwar an, wie die momentane Speicherlast und

401

5.2

Index A

B

a2enmod 179 Abhängigkeiten 363 Absicherung 291 ACCEPT 117 AccessFileName 160 ACK 116 AdBlock Plus 396 Adium 300 AIX 14 alias 91 Allow 162 AllowOverride 163, 173, 225 AMD IOMMU 418 AMD64 59 Änderungsverwaltung 142 Angriff 15 Apache 146, 148, 281 APACHE_OPTS 369 apachetop 402 APT 70, 474 apt-get 73, 75, 474 autoclean 75 autoremove 75 check 75 clean 75 dist-upgrade 75 install 75 purge 75 remove 75 source 75 update 75 upgrade 75 ARP-Cache 432 AT&T-Unix 96 atime 41 Atomicity 261 Ausfall 15 Ausfallzeit 416 Auswahl 29 auth 439 auto_failback 444 Autojoin 432

backports 71 Backup 254 badblocks 49 Bash 88 Basic Regular Expression 179 bcast 436 Benutzer 87 Benutzerdaten 34 Berechtigungen 111 Betriebssystem 217 blkid 50 Blockdevice 446 Blockgröße 37 Bochs 417 BSD 14 BSI 479

C CA 64, 189 CAcert 309 Cache 224 Cacti 350 Catalina 286 CERT 486 cfg_dir 370 cfgmaker 347 CFLAGS 67, 80 CGI 175 Chain 117 ChallengeResponseAuthentication 84 Chat 292 chmod 93 chown 113 chroot 329 Citrix 417 Cluster 430 Cluster-IP 432 com2sec 336 commercial 72 common 449 Common Name 190 Community-String 348

491

Index

comp.os.minix 20 compression 438 compression_threshold 438 Consistency 261 console 426 Contacts 376 CRITICAL 363 ctime 41

D Dateigröße 41 Dateisystem 35, 37, 38, 50 Datenbanksicherheit 245 Datenblock 44 Datensicherheit 458 Datenübertragungsvolumen 15 Datenvolumen 15 deadtime 438 Debian 18, 19, 24, 32 debootstrap 423 debugfs 49 DefaultType 162 Defekt 15 degr-wfc-timeout 452 Deny 162 Denyhosts 138 depend 102 destination port 118 DFN 64 Dimensionierung 19 Distribution 23 Distrowatch 23 DNS 225 DNS-Zugriff 225 DocumentRoot 38, 172 Dokumentation 141 Dom0 420 Domain0 420 DomainU 420 Domäne 420 DomU 420, 427 dpkg 76, 480 DRBD 446 drbdadmn 454 drbddisk 457 DROP 117 dumpe2fs 45, 49 Durability 262

492

E e2fsck 45, 49 e2fsprogs 49 e2fsprogs 49 e2image 50 e2label 50 ebuilds 78 EDITOR 91 Ejabberd 295, 299, 306, 312, 316 ELF 30 EMC 417 emerge 481 equery 482 Erreichbarkeit 361 ErrorLog 164 Exabyte 51 export 91 ext2 39 ext3 39 ext4 39, 50 Extend 51

F Fail2ban 135 Failback 444 Fedora 24 Fehler 15 Feintuning 69 Festplatten 19, 49 Festplatten-I/O 223 FHS 33 filefrag 50 Fileserver 44, 95 Filesystem Hierarchy Standard 33 FILTER 117 find 112 findfs 50 Firefox 396 Firewall Builder 121 Forking 149, 150 FORWARD 117 FQDN 190 Fragmentierung 48 FreeBSD 13 fsck.ext2 49 e2fsprogs 49 fsck.ext3 49

Index

FTP 362 FTPS 315 Full Mode 48 fwbuilder 121

G Gast 418 genkernel 447 Gentoo 24, 27, 31, 60, 80 gentoolkit 482 GET 334 GETBULK 334 GETNEXT 334 GID 41 global 449 GNU Privacy Guard 61 GNU/Linux 14 GNU-Tools 14 Google Analytics 396 GPG 61 Gratuitous ARP 432 groupadd 88 Guest 418 Güte 361 Gutsy 71

H Hard State Change 380 Hardlinks 41, 42 Hardware 18, 217 Hardware-RAID 54 Hardy 71, 422 Härtung 228 Härtungsmaßnahmen 143 Hash 61 Heap 30 Heartbeat 430 Heartbeat2 434 HISTSIZE 91 Hochverfügbarkeit 415 Host 362, 418 virtueller 170 HostbasedAuthentication 84 Host-Firewall 115 Hostgroup 375 HostnameLookups 163 HP-UX 14

HTTP 119, 229 HTTP_PROXY 91 HTTPS 119

I IA64 59 id 88 IDS-System 132, 143 IgnoreRhosts 84 Image-Datei 62 Indexes 173 Indexmaker 342 Informationssicherheit 16 Init 96 initdead 438 Inode 41 INPUT 117 Installation 33, 60 Intel VT 418 Intrusion-Detection 132 Inventur 96 iostat 405, 406 iptables 116, 117 IRIX 40 ISMS 16 ISO 17799 141 ISO 18028 143 ISO 27001 140, 488 ISO 27002 141 Isolation 262 IVW 395

J Jabber 292, 362 Java 282 JFS 40 Journal 38, 47 Journaling 38

K Kapazität 57 KDE 27 KeepAlive 156, 437 KeepAliveTimeout 156 Kernel 22 Kernel-Update 416, 428

493

Index

Keyserver 64 Knoppix 24 Konfiguration 33 Kryptographie 196 Kubuntu 27

L LAMP 145 Landscape 460 Lebenszyklus 37 libc 30 Linus 19 Linux 21 Linux Standard Base 30 Linux-HA 430 Linux-Kernel 40 Listen 169, 171 LockFile 155 Logdatei 34 logfacility 436 LogFormat 164 Logging 180 Logical Volume Managers 36 Logstrom 396 LSB 30 LTS 25 LVM 36, 37, 447 lwp-request 181

M Mac OS X 14 Mailversand 312 Main 72 Maintainer 62 Mandriva 24 MANGLE 117 Manpage 38 MaxKeepAliveRequests 156 MaxRequestsPerChild 158 MaxSpareServers 157 MaxSpareThreads 159 md5 439 Metadaten 42 Meta-Distribution 27 Metapakete 76 Metasploit 478 Metazeichen 184

494

mfks.ext3 45 MIB 334 MIB Browser 336 Microsoft 417 Minix 20, 39 MinSpareServers 157 MinSpareThreads 159 mirror 424 Mirroring 56 mke2fs 49 mkfs.ext2 50 mkfs.ext3 50 mklost+found 50 mod_jk 284 mod_rewrite 178 mod_ssl 187 Module 178 Monitoring 36, 142, 333 moo 70 Moore, H. D. 478 MRTG 333, 340 mtime 41 Multics 20 Multithreading 149, 150 Multiverse 72 MySQL 201, 231 mytop 404

N Nagios 333, 360 nagios_group 370 nagios_user 370 NameVirtualHost 171 NAS 446 NAT 117 NCSA 147 Netcraft 147 netstat 111 Netzwerkdienste 110 Netzwerkproblem 422 Neustart 416 nmap 116 Node 431 node 436 Novell 18 Novell SUSE 24 NRPE 361, 384

Index

Objekt 362 OK 363 OpenBSD 13 OpenPGP 61 OpenSSH 81 OpenSSL 478 openSUSE 18, 19, 24, 31 Optimierung 333, 401 Ordered Mode 47 OTR 306 OUTPUT 117

PREROUTING 117 Pretty Good Privacy 61 Primary 453 Priorität 106 ProFTPD 315, 435 Programmierung 216 proposed 72 protocol 451 Protokollierung 142 Provider 14 Prozess 227 Prozess-ID 96 Prüfsumme 62 PSI 299 PubkeyAuthentication 84 PUT 229

P

Q

Page Impression 395 Paketmanagement 69 Paketmanager 24, 29, 435 Partitionierung 33 Partner 72 Passphrase 191 PasswordAuthentication 84 Patch-Management 473 PATH 91 Pattern 117 PCI DSS 487 PCLinuxOS 24 PermitEmptyPasswords 84 PermitRootLogin 84 PGP 61 PHP 148, 198, 442 PHP3 200 phpinfo 201 phpMyAdmin 235, 238 phpPgAdmin 264, 266 PidFile 155 Pidgin 299 pidstat 405, 407 Ping 437, 443 Ping of Death 115 Port 83 Portage 24, 28, 78 POSIX 14 PostgreSQL 248, 261 POSTROUTING 117

QEMU 417

NSCA 362, 390 Nutzungsstatistik 449

O

R RAID 17, 39, 53 RAID 0 55 RAID 1 56 RAID 10 57 RAID 5 57 RAID-Controller 19 RAID-System 17 RAM 19 rc-config 107 rc-status 107 rc-update 107, 439 Red Hat 24 Redundanz 15, 16 Reiser4 40 ReiserFS 39 resize 50 RESPONSE 334 ressource 449 Restricted 72 RewriteEngine 180 RewriteRule 181 RhostsRSAAuthentication 84 Risiko-Management 15 RLimit 228 RPM 24

495

Index

rsync 105, 445 Runlevel 96, 99

S S/MIME 309 SAN 446 sar 405, 409 Schutzbedarf 15 SCP 83, 325, 326 SCPONLY 328 Secondary 455 Sendfile 225 ServerAdmin 172 Serverdienste 145 ServerLimit 159 ServerRoot 155 ServerSignature 168 Serverwartung 459 Service 362 SET 334 setguid 113 setuid 113 SFTP 325, 326 shell_exec 442 Sicherheit 429 Slackware 24, 32 SLES 32 SMART 410 smartctl 411 smartmontools 411 SNMP 333, 334 snmpget 338 snmpset 339 snmptable 339 snmpwalk 338 Soft Recovery 380 Soft State 380 Soft State Event 380 Software-RAID 54 Solaris 14 Spam-Relay 95 Speicherverbrauch 218 SQL 240 SSH 81, 362 ssh-keygen 82 SSL 185, 309 Stack 30 Stallmann 21

496

Startpartition 35 StartServers 157 stat 41 state 118 Stateful Inspection 118 STONITH 435 strace 89 StrictModes 84 Striping 55 Stromausfall 16 sudo 87 SUDO_PROMPT 91 Suhosin 209 Superblock 41, 45 Support 31 Swap 37 Switch 432 Symlink 42 SymLinksIfOwnerMatch 176 SYN 116 sysstat 402, 405 System V 96 Systemhärtung 95 Systemstart 96, 99, 103, 105, 120 System-V 30, 96 Sys-V 96 sysv-rc-conf 104 sysv-rc-config 104

T Table 117 Tanenbaum 20 Target 117 tcpdump 441 TCP-Stack 115 Template 373 Terabyte 51 Thread 149 ThreadsPerChild 159 Timeout 155 Timeperiods 376 TLS 185 Tomcat 281 Torvalds 19 tune2fs 49 Tuning 156, 216

Index

U

W

Ubuntu 18, 24, 25, 31, 68, 474, 484 UDP 119 UID 41 Umask 92 Unics 20 Universe 72 Unix 14, 20 UNKNOWN 363 unlink 42 update-rc.d 104, 439 updates 72 upgrade 475 Upstart 98 Urlaub 485 usage-count 449 USE-Flag 68 Usenet 20 UsePrivilegeSeparation 84 usermod 88

WAF 363 Wahrscheinlichkeit 17 Warez 95 WARNING 363 warntime 437 Wartung 459 Wartungsvertrag 19 Web 362 Webalizer 397 WebDAV 229 wfc-timeout 452 WinSCP 327 Wireshark 441 Worker 288 Writeback Mode 47 WWW 146

V Vaterprozess 157 Vererbung 375 Verfügbarkeit 15, 444 Verzeichnisebene 34 Virenschutz 114, 133 VirtualHost 171, 172 Virtualisierung 416, 429 Virtuelle Hosts 170 Visit 395 VMware 416, 417

X X.509 189, 309 X11Forwarding 84 Xen 417, 418, 420 xen-create-image 424 Xfce 27 XFS 40 xm 426 XML 431 XST 229 Xubuntu 27

Z Zählpixel 395 Zertifizierung 141 Zugriffsrechte 41 Zugriffsschutz 161

497

System:	hardy (jabber.rodewig.de)
Maintainer:	Root
Description:	Internet