Log-Dateien überwachen

Das Installationspaket des Windows-Agenten aus Checkmk Raw enthält keine Python-Umgebung. Eine entsprechende Cabinet-Datei liegt allerdings bereits auf Ihrem Checkmk-Server bereit. Diese Datei namens python-3.cab finden Sie im Verzeichnis ~share/check_mk/agents/windows oder in Checkmk über Setup > Agents > Windows > Windows Agent. Kopieren Sie diese Datei auf Ihren Windows-Host in das Verzeichnis C:\Program Files (x86)\checkmk\service\install. Dort liegt bereits eine Datei mit diesem Namen und einer Dateigröße von 0 Byte. Diese Datei müssen Sie mit der Version vom Checkmk-Server überschreiben. Starten Sie anschließend den Service des Checkmk-Agenten neu. In der Windows PowerShell mit Administratorrechten, können Sie das mit dem folgenden Befehl erledigen:

Beim Neustart des Windows-Service wird die virtuelle Python-Umgebung automatisch installiert.

Alternativ können Sie auch ein aktuelles Python-Paket von python.org herunterladen und installieren. Achten Sie bei der Installation darauf, die folgenden Optionen zu aktivieren:

Falls sie nach der Installation von Python gleich drauflos testen wollen, ist auch unbedingt ein Neustart des CheckmkService entweder über den Windows Task Manager oder mit den oben angegebenen Befehlen notwendig. Sonst weiß der Service nämlich nichts von den neuen Umgebungsvariablen.

In den kommerziellen Editionen rufen Sie zunächst die Regel für das Agentenplugin Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Text logfiles (Linux, Solaris, Windows) auf. Die Voreinstellung Deploy the Logwatch plugin and its configuration sollte im Regelfall so belassen werden. Falls Sie die Konfigurationsdatei logwatch.cfg allerdings auf einem anderen Weg auf den Host übertragen wollen oder müssen, steht hier noch die Option Deploy the Logwatch plugin without configuration zur Verfügung.

Weiter geht es mit der Option Retention period. Die Voreinstellung beträgt hier eine Minute, was auch dem voreingestellten Check-Intervall in Checkmk entspricht. Der Wert sollte immer mindestens dem Check-Intervall entsprechen. Diese Option ist in erster Linie dafür zuständig, dass keine Log-Meldungen durch eine Service-Erkennung oder die manuelle Ausführung von cmk -d myhost verloren gehen. Weitere Details dazu finden Sie in der Inline-Hilfe der Option und im Werk #14451 mit dem diese Option eingeführt wurde.

Jetzt folgt die Sektion der Regel, wo es endlich richtig losgeht - Configure a logfile section. Und das beginnen wir direkt mit dem größten Stolperstein der vergangenen Jahre. In dem Feld Patterns for logfiles to monitor müssen Sie die Log-Dateien, die Sie überwachen wollen, benennen. Dies können Sie einzeln und explizit oder mit sogenannten Glob Patterns (kurz: Glob) erledigen. Wir verwenden an dieser Stelle das Python-Modul glob, zu dem es auf docs.python.org eine ausführliche Dokumentation gibt. Wir wollen Ihnen aber gleich hier ein paar hilfreiche Beispiele an die Hand geben.

Schreiben Sie hier beispielsweise /var/log/my.log hinein, wird Logwatch eben diese eine Log-Datei überwachen. Geben Sie hier stattdessen /var/log/*log ein, wird Logwatch alle Dateien, die auf die Zeichenfolge log enden und direkt im Verzeichnis /var/log liegen, überwachen. Wollen Sie Log-Dateien in allen direkten Unterverzeichnissen von /var/ überwachen, können Sie das beispielsweise mit dem folgenden Glob erledigen: /var/*/*log. Das Glob ** zum rekursiven Durchsuchen einer Verzeichnisstruktur bieten wir hier explizit nicht an, weil wir damit viel zu schnell bei viel zu großen Trefferlisten landen und den eigentlichen Einsatzzweck von Logwatch hinter uns lassen.

Die folgende Tabelle gibt Ihnen noch ein paar hilfreiche Beispiele, wie Sie Globs verwenden können, um auch wirklich zu die Dateien zu überwachen, die der Überwachung bedürfen, ohne alle einzeln angeben zu müssen:

Wenn es also darum geht, welche Dateien im ersten Schritt "gematcht" werden, verwenden wir keine regulären Ausdrücke und womöglich genügt Ihnen das schon, um alle gewünschten Dateien zu erreichen.

Wenn Sie jetzt allerdings weiter aussieben müssen, können Sie in einem zweiten Schritt mit der Option Regular expression for logfile filtering reguläre Ausdrücke auf die Treffer aus Schritt 1 anwenden.

Haben Sie also im ersten Schritt mit /var/log/* und /var/log/*/* allen Dateien /var/log/ und seinen direkten Unterverzeichnissen eingesammelt, könnte Sie mit dem regulären Ausdruck error.log$|err$ die Trefferliste auf alle Dateien reduzieren, die auf err.log oder err enden. Obacht: Der Punkt ist nun wieder ein beliebiges Zeichen. Somit könnten dann zum Beispiel die Dateien /var/log/apache2/error.log, /var/log/mail.err und /var/log/cups/error_log übrig bleiben.

Sie sehen also, dass wir Ihnen für Auswahl der überwachten Dateien bereits zwei gute und mächtige Werkzeuge an die Hand geben, damit Logwatch im nächsten Schritt sehr zügig durch eine überschaubare Dateiliste auch die weiteren Parameter bzw. Inhalte prüfen kann. Zu Letzterem können Sie Ihre Kenntnisse im Artikel reguläre Ausdrücke in Checkmk weiter vertiefen.

Mit der Option Restrict the length of the lines können Sie Logwatch anweisen, überlange Zeilen nach der vorgegebenen Anzahl an Zeichen abzuschneiden.

Die folgende Option Watch the total size of the log file bietet sich an, um eine defekte Log-Rotation zu erkennen. Wenn Sie hier 100 MiB einstellen, erhalten Sie jedes Mal eine Warnung, wenn eine bestimmte Log-Datei erneut um die eingestellte Größe gewachsen ist.

Die maximale Anzahl der Zeilen, die Logwatch pro Durchlauf und Datei prüft, lässt sich mit Restrict number of processed messages per cycle einschränken und mit Restrict runtime of logfile parsing können Sie dafür sorgen, dass Logwatch sich nicht zu lang an einer einzelnen Datei aufhält, die womöglich seit der letzten Prüfung mit abertausenden neuen Einträgen geflutet wurde.

Wenn Sie eine der beiden letzteren Optionen aktivieren, müssen Sie auch festlegen, was bei einer Überschreitung der angegebenen Grenzwert passieren soll. Mit unserer Voreinstellung wird der zugehörige Service kritisch und Sie erhalten die Mitteilung, dass Zeilen übersprungen wurden bzw. dass die maximale Laufzeit überschritten wurde.

Handling of context messages ist eine Option, mit der die Menge der übertragenen Daten sehr rasch sehr groß werden kann. Überlegen Sie also genau, ob Ihnen nur die Log-Meldung wichtig ist, die Ihrer Ansicht nach ein CRIT oder WARN erzeugen soll, oder ob alle Zeilen, die seit dem letzten Durchlauf von Logwatch hinzugekommen sind, an den Checkmk-Server übertragen werden sollen. Bei kleinen Log-Dateien, die minütlich nur um ein paar Zeilen anwachsen, ist die Einstellung Do transfer context sicherlich unproblematisch. Wenn aber auf einem Host aber 50 Log-Dateien überwacht werden, die plötzlich 100.000 neue Zeilen mit einer Länge von 500 Zeichen aufweisen, landen wir schon im Gigabyte-Bereich. Womöglich würde es bei einem solchen Ereignis eben genügen zu sehen, dass seit der letzten Prüfung sehr viele neue Meldungen dazu gekommen sind, um eine Prüfung direkt auf dem betroffenen Host zu veranlassen.

Sollten Sie den Kontext - also die Zeilen vor und nach einer für Sie wichtigen Log-Meldung - doch benötigen, so können Sie diesen mit der Optionen Limit the amount of context data sent to the monitoring server auf eine bestimmte Zahl an Zeilen vorher und nachher beschränken.

Mit Limit the amount of data sent to the monitoring server beschränken Sie die Größe der übertragenen Daten ganz allgemein.

Process new logfiles from the beginning ist standardmäßig abgeschaltet. Dies führt mitunter zu Verwunderung, weil Logwatch Probleme, die in Log-Dateien stehen, nicht "erkennt" und an den Checkmk-Server weiterreicht. Nach unserer Auffassung ist nichts älter als die Zeitung von gestern und so eben auch die Log-Meldungen, die vor dem ersten Durchlauf von Logwatch bereits in einer Log-Datei standen. Bei diesem allerersten Durchlauf tut Logwatch nämlich nicht mehr, als sich zu notieren, wie viele Zeilen bereits in dem jeweiligen Log enthalten sind. Erst beim zweiten Durchlauf werden die Dateien dann auf Ihren Inhalt - sprich die neu hinzugekommenen Zeilen - geprüft.

Logwatch ist bei seiner Arbeit darauf angewiesen, die Log-Dateien aus tatsächlich lesen zu können. Unter der Haube gibt sich Logwatch sehr viel Mühe, die Kodierung einer jeden Log-Datei zu erkennen. Allzu exotische Zeichenkodierungen können aber dazu führen, dass es hier zu Problemen kommt. Falls Sie die Zeichenkodierungen der überwachten Log-Dateien beeinflussen können, ist UTF-8 eine sehr gute Wahl. Geht das nicht und schafft Logwatch es nicht, die Kodierung herauszufinden, können Sie mit Codec that should be used to decode the matching files eine explizite Angabe machen.

Mit Duplicated messages management lässt sich wieder ein bisschen Bandbreite sparen und auch die spätere Ausgabe in Checkmk wird leserlicher, wenn Sie diese Option aktivieren. Wenn Sie Filter out consecutive duplicated messages in the agent output aktivieren, zählt Logwatch wie oft eine Zeile wiederholt wurde und schreibt dies entsprechend in den Output, statt die Zeilen zu wiederholen.

Zu guter Letzt werden jetzt, die für Sie interessanten Zeilen in den Log-Dateien per regulärem Ausdruck beschrieben und einem Status zugeordnet. Wenn Sie möchten, dass jede Zeile, die das Wort panic enthält zu einem CRIT in Checkmk führt, genügt es hier nach einem Klick auf Add message pattern unterhalb von Regular expressions for message classification panic in das Feld Pattern(Regex) einzutragen. Die Funktion der weiteren angebotenen Optionen sind bereits sehr detailliert ist der Inline-Hilfe an dieser Stelle beschrieben und werden hier nicht dupliziert.

Nur soviel: Der Status OK mag auf den ersten Blick verwirren. Er dient dazu, Zeilen aus einer Log-Datei erstmal an den Checkmk-Server zu übertragen, um dann dort erst die endgültige Klassifizierung vorzunehmen. Und damit kommen wir zu einem wichtigen Punkt, der zeigt, wie flexibel Logwatch - bei richtigem Einsatz - sein kann.

Alle Optionen, die in diesem Abschnitt erklärt wurden, werden zu Eintragungen in der bereits erwähnten Konfigurationsdatei, die auf dem jeweiligen Host abgelegt wird. Sollten Sie nun Änderungen an der Klassifizierung bestimmter Meldungen vornehmen wollen, kann es also sein, dass Sie zuerst die Regel editieren müssen, anschließend den Agenten backen und diesen installieren müssen.

Alternativ können Sie aber erstmal alle interessanten Meldungen an den Checkmk-Server übertragen (beispielsweise eben mit dem Status OK) und diese dann im Anschluss mit der Regel Logfile patterns auf dem Checkmk-Server (re-)klassifizieren. Auf diesem Wege können Sie sich das Backen und Ausrollen des neuen Agenten sparen und müssen nach einer entsprechenden Anpassung der oben genannten Regel nur einmal schnell die Änderungen aktivieren. Wie das genau geht, erfahren Sie weiter unten im Kapitel Reklassifizieren mit Logfile patterns.

In der Checkmk Raw Edition konfigurieren Sie das Agentenplugin wie üblich über eine Textdatei. Im Regelfall sucht Logwatch eine Datei namens logwatch.cfg in den Verzeichnissen /etc/check_mk (Linux) bzw. c:\ProgramData\checkmk\agent\config\ (Windows). Eine (fast) minimale Konfiguration könnte so aussehen:

Zuerst geben Sie hier also immer ein Glob Pattern an, gefolgt von allen anzuwendenden Optionen. Darauf folgt - mit einer Einrückung von einem Leerzeichen - zuerst ein Buchstabe, der den gewünschten Status bzw. die Funktion repräsentiert und schließend ein regulärer Ausdruck, der mit jeder Zeile der Log-Datei verglichen wird. Mit obiger Konfiguration würden alle neuen Zeilen, die seit dem letzten Durchlauf von Logwatch in die Datei /var/log/my.log hinzugefügt wurden, auf die beiden Pattern "eine kritische Meldung" und "etwas, dass nur eine Warnung auslösen soll" geprüft.

Eine sehr umfangreiche Beispielkonfiguration finden Sie als Instanzbenutzer in der Datei ~/share/check_mk/agents/cfg_examples/logwatch.cfg.

Da alle Optionen, die Sie in einer solchen Konfigurationsdatei angeben können, bereits im Abschnitt Konfiguration über Agentenbäckerei erklärt wurden, folgt hier nur eine Auflistung samt Verweis. Konsultieren Sie für die Erklärung bitte obigen Abschnitt.