CMS-Eigenheiten in Datenbanken

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.

CMS-Monitoring auf dem Webserver

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.

Fazit

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.