Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03176.jsonl.gz/2208

Wer zur Überwachung seiner Server nicht rund um die Uhr vor der Shell sitzen und Logs sowie die von procfs bereitgestellten Informationen auswerten will, braucht Überwachungswerkzeuge, die die Arbeit für ihn erledigen. Vor allem für kleine Umgebungen eignen sich die beiden Werkzeuge Monit und Munin, die einen sogar benachrichtigen, wenn sie selber nicht mehr weiterwissen.
Erbsen zählen
Rrdtool ist das wohl beste Werkzeug, um Systemeigenschaften von der CPU-Auslastung über den Netzwerkverkehr bis hin zur Festplattentemperatur festzuhalten und grafisch auszuwerten. Allerdings ist es durch sein kompliziertes Interface nicht ganz einfach zu benutzen, und die Erstellung eines zentralen Überwachungs-Dashboard erfordert einiges an Zeit. Deshalb existiert eine Reihe von Front-ends zu rrdtool, die nicht nur die Zusammenstellung eines Dashboard vereinfachen, sondern auch beim Erstellen der Datenbanken sowie der Sammlung der Daten behilflich sind.
Eines dieser Werkzeuge ist das in Perl geschriebene Munin (munin.projects.linpro.no, GPLv2), das sich entweder einfach von Hand installieren lässt und mittlerweile auch Teil der meisten Paketsammlungen ist. Der wichtigste Unterschied zu anderen Lösungen wie dem recht populären Cacti besteht darin, dass Munin einen Client-Server-Betrieb unterstützt. Dies ermöglicht es, auf einem oder mehreren Servern die zu erfassenden Daten zu erheben und sie dann auf einem oder mehreren zentralen Servern zu konsolidieren.
Zu diesem Zweck besteht Munin aus zwei Programmteilen, die Munin Master und Munin Node genannt werden. Munin Node kommt dabei auf den verschiedenen Clients zum Einsatz, während Munin Master auf dem zentralen Server sitzt. Einmal konfiguriert, wird Munin Master regelmässig (beispielsweise über einen Eintrag in der crontab) aufgerufen, worauf es dann alle in der zentralen Konfigurationsdatei registrierten Munin Nodes abklappert, die auf den Clients als Daemon laufen, und sie nach den von ihnen erhobenen Daten fragt.
Diese werden dann auf dem Munin Master in die verschiedenen Round Robin Databases eingefügt. Daraus erzeugt Munin Master dann mit Hilfe von rrdgraph die verschiedenen Graphen und speichert sie zusammen mit ein paar HTML-Dateien in einem beliebigen Verzeichnis ab. Dieses kann dann mit einem Webbrowser über einen separat zu installierenden Webserver wie Apache angesurft werden, worauf man ein übersichtliches Dashboard zu Gesicht bekommt, über das man sortiert nach Node auf die bekannten rrdtool-Graphen zugreifen kann, die die erfassten Daten nach Stunden, Tagen, Monaten und Jahren darstellen.
Viele Plug-ins
Die Daten, die Munin Node an den Zentralserver rapportiert, stammen nicht von Munin Node selber, sondern von einem oder mehreren Plug-ins. Diese sind alleine für die Erstellung der Round-Robin-Datenbanken sowie die Erhebung der Daten zuständig und können pro Maschine aktiviert respektive deaktiviert werden. So können Statistiken des Mail Transfer Agent nur auf dem Mailserver erhoben werden, während Apache-Prozesse beispielsweise nur auf dem Webserver gezählt werden.
Standardmässig bringt Munin eine Reihe von Plug-ins mit, die je nach unixoidem Betriebssystem mehr oder weniger Systembereiche und Applikationen abdecken. Während für AIX neun Plug-ins bereitstehen, die unter anderem CPU-Auslastung und Arbeitsspeicherverbrauch behandeln, existieren für Linux 39 Plug-ins, die sich unter anderem auch um den NFS-Server und eine Vielzahl von Informationen aus procfs kümmern. Weitere Plug-ins stehen beim Munin Exchange zur Verfügung, die unter anderem auch den Status von APC-USVs und den verschiedensten Daemons abfragen. So kommt man mit rrdtool so gut wie gar nicht in Berührung. Wer unter den Plug-ins kein passendes für seine Bedürfnisse findet, kann mit einer beliebigen Scriptsprache selber eines schreiben – man muss sich dann aber auch wieder mit rrdtool beschäftigen. Immerhin übernimmt Munin die zentrale Sammlung und Darstellung der Daten.
Warnungen an Nagios
Wie bereits erwähnt, werden sowohl Munin Master als auch Munin Node je über eine zentrale Konfigurationsdatei gesteuert. Bei Munin Master dient sie vor allem der Definition der verschiedenen Nodes. Zudem können Benachrichtigungen per E-Mail oder für Nagios konfiguriert werden, wobei die Stärke von Munin vor allem darin liegen dürfte, Nagios hinsichtlich grafischer Auswertung von (Leistungs-)Daten zu ergänzen.
Bei den Nodes erfolgt in der Konfigurationsdatei vor allem die Definition der IP-basierten Zugangskontrolle. Plug-ins können aktiviert respektive deaktiviert werden, indem einfach ein Symlink zum jeweiligen Programm im Plug-in-Verzeichnis erstellt respektive entfernt wird.
Monitoring-Regeln
Daemons am Leben halten
Hat man die bisherigen Leistungsdaten der Server im Blick, ist schon viel erreicht. Allerdings sind die Graphen und Munin wenig geeignet, um plötzlich auftretende Probleme zu erkennen oder um mit der Nichtverfügbarkeit einzelner Services umzugehen. Dazu eignen sich spezialisierte Monitoring-Programme wie Monit (www.tildeslash.com/monit, GPLv3) viel besser.
Monit ist ein C geschriebener Monitoring-Daemon, der sich hauptsächlich auf die Überwachung von lokalen Prozessen, Dateien, Verzeichnissen sowie Devices versteht. Es lassen sich auch entfernte Services testen, wobei dann aber nur eingeschränkte Funktionalität zur Verfügung steht.
Objekte, die mit Monit überwacht werden, lassen sich auf eine Vielzahl von Eigenschaften überprüfen. Rund um diese Eigenschaften können Bedingungen definiert werden, bei deren Eintreten Monit eine Aktion ausführt. Prozesse können beispielsweise darauf getestet werden, ob sie laufen und wie viele Ressourcen sie belegen. Laufen sie nicht oder haben sich in einen Zombie verwandelt, kann Monit angewiesen werden, sie automatisch neu zu starten. Oder einen Alarm zu versenden, beispielsweise per
E-Mail. Ähnliches ist möglich, wenn sie zu viele Ressourcen belegen. Zudem ist es im Falle von Netzwerkprozessen wie einem HTTP- oder MySQL-Server möglich, zu testen, ob sie Verbindungen annehmen, ob die richtigen Antworten geliefert werden oder ob beispielsweise eine heruntergeladene Datei die richtige Checksumme aufweist, womit sich allfällige Manipulationen entdecken liessen.
Die Überwachung von Dateien, Verzeichnissen und Devices erstreckt sich unter anderem auf ihre Existenz, ihre zugeordneten Rechte, die von ihnen belegte Speicherkapazität oder ihre Checksumme. So kann beispielsweise ein Administrator benachrichtigt werden, bevor eine Partition volläuft, sich die Checksumme einer Datei ändert (weil sie vielleicht von einem Angreifer manipuliert wurde) oder es kann eine Log-Datei rotiert werden, wenn sie zu gross wird.
Unter Kontrolle
Die Definition der zu überwachenden Objekte erfolgt in der zentralen Konfigurationsdatei namens monitrc. Sie kann mit einer beliebigen Anzahl von Objekten bestückt werden, wobei die auf die Objekte anzuwendenden Regeln in einer auf Token basierenden Sprache definiert werden, die fast beliebig verknüpfbare Bedingungen beherrscht. Zusätzlich ist es möglich, Abhängigkeiten zu definieren. Mit diesen können Aktionen kaskadiert werden. Sollte ein Test fehlschlagen, wird die von ihm ausgeführte Aktion an alle angehängten Tests weitergegeben. Wird vom ersten Test beispielsweise das Monitoring deaktiviert, stellen alle angehängten Tests ebenfalls ihre Monitoring-Aktivität ein. Beispiele für ein paar einfache Tests, bei denen Apache auf Funktionsfähigkeit, das Root-Filesystem auf Überlauf und www.infoweek.ch auf Verfügbarkeit geprüft werden, zeigt der Kasten «Monitoring-Regeln».
Die Überwachung der Services erfolgt über ein Webinterface, das von einem in Monit eingebetteten Webserver bereitgestellt wird. Es bietet einen Überblick über die überwachten Objekte sowie ihren aktuellen Status. Zusätzlich ist für jedes Objekt eine Detailansicht verfügbar, die sich aus weiteren Informationen zum Objekt (Leistungsdaten, Uptime usw.) sowie den Regeln zusammensetzt, die zur Überwachung des Objekts appliziert werden. Gleichzeitig lässt sich das Monitoring für einzelne Objekte aktivieren respektive reaktivieren sowie Prozesse stoppen oder starten.
Alarme werden standardmässig per E-Mail versendet. Zusätzlich lassen sich Events per Syslog loggen und an weitere Server verteilen. Ausserdem können beliebige Programme ausgeführt werden. So können Alarme beispielsweise über ein Script an einen Jabber-Server weitergeleitet werden, um den oder die Administratoren direkt per Instant Message zu benachrichtigen.