Laut Wikipedia ist Monitoring eine Sonderform des Protokollierens mit dem Ziel des Eingreifens, wenn etwas nicht in Ordnung ist. Das kann schon eine simple Webcam zur Überwachung des Kaffeepegels einer Kaffeemaschine sein oder eine computergestützte Erfassung der Raumtemperatur in einem Rechenzentrum.

Ziele eines guten Monitorings sind kürzere Reaktionszeiten, Vermeidung von Downtimes, Vereinfachung von Arbeitsprozessen und eine bessere Ursachenermittlung bei komplexen Problemen. In einem Computernetzwerk mit einem zentralisierten Monitoring kann ein Monitoringserver leicht die von außen verfügbaren Dienste wie HTTP, FTP, SSH oder MySQL prüfen. Um aber beispielsweise die Prozessorauslastung zu messen, muss man diese intern auf dem zu prüfenden Client erfassen. Entsprechende Software für Remote-Monitoring ist in den meisten Softwarepaketen für IT-Monitoring enthalten. Weit verbreitet ist die Open-Source-Software Nagios [1], die auch professionell in sehr großen Netzwerken mit mehreren tausend Hosts eingesetzt wird.

Nagios im Kurzportrait

Quelltext frei viele Plugins und Addons verfügbar eigene Erweiterungen leicht möglich Active/Passive Monitoring Parents und Dependencies Event Handler Host-/Service-/Contactgroups redundantes und/oder verteiltes Monitoring möglich

Nagios besticht unter anderem dadurch, dass es sich leicht erweitern lässt. Die Website exchange.nagios.org [2] listet 301 Addons und 1.529 Plugins. Plugins sind kleine Programme oder Scripts, etwa zum Testen von HTTP oder der CPU-Temperatur, Addons erweitern Nagios um zusätzliche Funktionen. Ein beliebtes Addon ist PNP4Nagios [3], das die Messwerte von Nagios in einer Datenbank sammelt und daraus Grafiken erstellt. Ein guter Anlaufpunkt bei der Arbeit mit Nagios ist das deutschsprachige Nagios-Wiki [4], das auch eine Plugin-Übersicht enthält.

Abhängig von der Art des Clients, führt ein Nagios-Server beim Webhoster Mittwald CM Service, dem Arbeitgeber des Autors, bis zu 80 unterschiedliche Checks pro System durch. Diese lassen sich grob in die Bereiche Hardware, System und Ressourcen, Dienste, CMS sowie Security unterteilen. Diese Checks sind nicht nur für einen Webhoster hilfreich, sondern auch für Entwickler und Agenturen, die einen oder mehrere Webserver betreiben.

Zu den Hardware-Checks gehören die Kontrolle des RAID-Status, der SMART-Parameter der Festplatten, aller Sensoren (Temperatur etc.) und der Kernel-Meldungen (RAM-Fehler etc). An Systemressourcen werden unter anderem Plattenplatz, Anzahl der Prozesse, Systemzeit und Auslastung geprüft. Allein die Auslastung wird über zehn unterschiedliche Werte (Beispiele: Load, CPU, Swap) bestimmt und kann so Hinweise auf ganz spezielle Konfigurationsfehler in einem Content Management System wie TYPO3 liefern.

Weitere Basis-Checks sind Überprüfungen aller Standarddienste von HTTP und MySQL über FTP bis Mail und Backup. Sehr spezielle Checks betreffen Security und dynamisches Monitoring (automatisches Hinzufügen und Entfernen von Hosts).

Auch die Datenbanken sollten speziell überwacht werden. Neben den oben genannten Checks gehören dazu die Kontrolle der einzelnen MySQL-Threads (wie viele laufen, sind auffällige Queries dabei), regelmäßige Prüfungen aller Tabellen auf Fehler, die Auswertung des MySQL-Errorlogs und vieles mehr. InnoDB- und besonders Cache-Tabellen können aufgrund ihrer Größe oder eines besonders starken Wachstums Hinweise auf eventuelle Optimierungsmöglichkeiten einer Webpräsenz geben.

Ein Problem, das gelegentlich bei Verwendung der TYPO3-Extension „tt_news“ auftritt, fällt schon im DB-Monitoring auf, noch bevor das Monitoring des Webservers anschlägt. Die Extension ist dafür bekannt, viele JOINs in Verbindung mit der Sortierung durch „ORDER BY“ zu nutzen. Dafür müssen temporäre Tabellen angelegt werden, die bei entsprechender Größe die SQL-Abfrage stark verlangsamen können. Wenn dann noch die Index-Suche aktiviert ist und Google seinen Bot vorbeischickt, kann die Webpräsenz unbedienbar langsam werden, sodass nur ein sofortiger Eingriff hilft. In solchen Fällen zeigt sich bei einer näheren Untersuchung häufig, dass die „backPID“ aktiviert ist. Eine Deaktivierung kann zukünftig ein ähnliches Aufschaukeln verhindern. Und falls nachts mal der eine oder andere Bot zu Besuch war, sieht man das morgens auch an den gewachsenen Index- und Cache-Tabellen. Bots sind zwar wichtig für die Indizierung in Suchmaschinen, sie sind aber sehr schnell und können hohe Last erzeugen.

Sehr empfehlenswert ist auch die Überwachung des MySQL-Errorlogs. Wenn hier defekte Tabellen gemeldet werden, können diese umgehend repariert werden, um Performance und Sicherheit zu gewährleisten. Ein für Reparatur- und Recoveryzwecke benötigter SQL-Dump sollte nicht zu alt sein – auch das lässt sich mit Nagios sehr leicht überwachen.

Wesentlich vielfältiger als auf dem Datenbankserver sind die Monitoring-Möglichkeiten auf dem Webserver. Wichtig ist dabei zum Beispiel die Überprüfung der typo3temp-Verzeichnisse. Ein Hauptverursacher von voll gelaufenen typo3temp-Verzeichnissen ist GMENU_LAYERS, welches das Verzeichnis mit Javascript-Dateien vollschreibt. Wenn erstmal ein paar hunderttausend Dateien in dem Verzeichnis liegen, werden die Zugriffe auf die darin enthaltenen Dateien merklich langsamer. Ist GMENU_LAYERS der Verursacher, hilft als Workaround die Zuweisung einer „layer_menu_id“ oder alternativ ein Patch [5].

Es kann aber auch sein, dass typo3temp mit Tausenden von „EXTERNAL_URL“-Dateien gefüllt ist. Dies tritt auf, wenn bei Indexed Search die Indizierung externer Inhalte aktiviert ist. Hier gibt es keinen Workaround, sondern nur einen weiteren Patch [6]. Beide Patches sind im Zuge der Artikelrecherche entstanden und wurden bereits in den TYPO3-Bugtracker eingestellt.

Weitere Probleme können durch defekte Grafiken auftreten, bei denen während der Konvertierung durch ImageMagick oder GraphicsMagic Fehler aufgetreten sind, weil vielleicht schon die Quelldatei defekt ist. Dann gibt es auch mal GIF- oder JPEG-Dateien, die viele Megabyte groß sind und beim Versuch sie anzuzeigen einen Browserabsturz verursachen können. Solche Dateien können ebenso wie große JPEG-Bilder mit mehreren eingebetteten ICC-Profilen leicht vom Monitoring erfasst werden.

Sehr wichtige Checks sind auch verschiedene Überprüfungen des E-Mail-Versands aus einer Webpräsenz heraus. Dabei sollten E-Mails pro Tag und auch pro Stunde gezählt werden. Auf diese Weise entdeckt man Hacker, die etwa durch zu einfache Passwörter eingedrungen sind und Spam verschicken. Hacker, die Webpräsenzen beispielsweise zum Verteilen von raubkopierten Filmen nutzen, fallen im Monitoring durch ungewöhnlich große Dateien auf.

Empfehlenswerte CMS-Checks

alle Logs inkl. der vom CMS und seinen Erweiterungen Anzahl Zugriffe laut Accesslog Tabellenfehler und -größe Größe des Webverzeichnisses oder einzelner Unterverzeichnisse Anzahl der Dateien in temp- oder ähnlichen Verzeichnissen Liste der größten Dateien Verschachtelungstiefe des Webverzeichnisses Anzahl verschickter E-Mails absolut und pro Stunde defekte Bilddateien

Aufgrund der Komplexität von CMS-basierten Webpräsenzen benötigt man heute ein umfassendes und schnelles Monitoringsystem, das weit über einfaches Monitoring von HTTP und FTP hinausgeht und bis in Bereiche von Intrusion Detection hinein reicht oder sogar spezielle Konfigurationsprobleme erkennen lässt. Nagios eignet sich perfekt, um so ein Szenario aufzubauen. Vor der Komplexität des Systems sollte man dabei nicht zurückschrecken, denn ein einfaches Monitoring ist immer noch deutlich besser als gar kein Monitoring. Erweitern kann man es immer noch.