Checkmk macht bei der Logfile-Überwachung (Checkmk-Logwatch) genau das, was man im Alltag braucht: Es merkt sich, welche Logzeilen bereits verarbeitet wurden, und bewertet neue Einträge anhand Ihrer Regeln. In der Praxis stolpert man dabei früher oder später über Dateien unterhalb von .../var/check_mk/logwatch/… – oft mit Namen wie Application oder Security. Dann kommt die typische Frage aus dem Betrieb: „Kann ich die wegwerfen, um Platz zu schaffen oder Fehler zu beheben?“

Dieser Beitrag erklärt kurz, wofür diese Dateien da sind, wann Löschen sinnvoll sein kann und wie Sie die Dateien so „löschen“, dass Sie sich nicht selbst Log-Hinweise abschneiden.

Was sind die Checkmk-Logwatch-Dateien überhaupt?

In Checkmk arbeitet Logwatch im Kern in zwei Stufen:

1. Auf dem überwachten Host sammelt das Agentenplugin (mk_logwatch.py) neue Logzeilen und erzeugt daraus eine Ausgabe für den Checkmk-Agenten. Damit nicht bei jedem Check die kompletten Logs erneut gelesen werden, nutzt Logwatch State-Informationen (z. B. Dateioffset, „bis hierhin habe ich gelesen“) sowie Batch-Dateien für die transportierten Logzeilen.
2. Auf dem Checkmk-Server (OMD-Site) werden die vom Agenten gelieferten Logzeilen als Servicezustand dargestellt (OK/WARN/CRIT). Je nach Check/Setup kann Checkmk Logzeilen auch an die Event Console weiterleiten.

Checkmk dokumentiert die typischen Ablagen für State- und Batch-Dateien primär auf der Host-Seite (Linux/Windows), inklusive logwatch.state.* und logwatch-batches/*. Diese Dateien sind ein wesentlicher Teil der „nur neue Zeilen“-Logik. (Die offizielle Doku nennt u. a. logwatch.state.* und logwatch-batches/* als Speicherorte.)

Warum heißen Dateien manchmal „Application“ und „Security“?

Wenn Sie Windows-Eventlogs überwachen, begegnen Ihnen diese Begriffe praktisch immer:

• Application: Anwendungsereignisse (Abstürze, Fehler, Start/Stop, „Application Error“ etc.)
• Security: Audit- und Sicherheitsereignisse (Logins, fehlgeschlagene Anmeldungen, Zugriffe, Policy-Änderungen)

Je nach Setup landen Auszüge bzw. der aktuell relevante „Arbeitsstand“ dieser Logquellen als Dateien im Logwatch-Kontext Ihrer Checkmk-Instanz.

Wozu sind diese Dateien gut (simpel erklärt)?

Logwatch ist kein SIEM. Es ist „Monitoring“ im klassischen Sinn: Sie definieren, welche Muster kritisch oder warnend sind, und Checkmk setzt den Servicezustand entsprechend.

Damit das zuverlässig funktioniert, braucht Logwatch intern eine Art Gedächtnis:

• Welche Logzeilen wurden schon verarbeitet?
• Welche Meldungen sind neu und unbestätigt?
• Wie vermeide ich, dass ich bei jeder Abfrage erneut Gigabytes scanne?

Genau hier helfen die State-/Batch-Mechanismen. Checkmk selbst schreibt dazu, dass Logwatch im Regelfall „neu, unbestätigt und kritisch“ als Kriterium nutzt, um aus ereignisbasierten Logzeilen einen zustandsbasierten Service zu machen. (docs.checkmk.com)

In welchen Fällen sollte (oder kann) man diese Dateien löschen?

Vorab: In vielen Umgebungen bringt „Platz schaffen“ hier wenig. Die Dateien sind häufig nicht riesig, und blindes Löschen ist eher eine Fehlerquelle als ein Gewinn.

Sinnvolle Gründe gibt es trotzdem – typischerweise diese:

Wenn Logwatch „überläuft“ oder blockiert

Checkmk aktuallisiert die Informationen in diesen Verzeichnissen normalerweise selber, manchmal kann es aber passieren, dass diese Dateien „blockieren“ und Checkmk sie nicht aktuallisieren kann. In so einem Fall ist es schlau, sie manuell zu löschen.

Wenn Sie bewusst einen Neustart der Auswertung wollen

Beispiel: Sie haben Logfile-Regeln stark geändert (Patterns, Klassifizierungen) und möchten den Zustand „aufräumen“, ohne dass alte, bereits gesehene Meldungen im Status herumspuken.

Wenn Sie die Meldungen in den Logfiles löschen, wird Checkmk sie beim nächsten Durchlauf mit aktuellen Informationen befüllen.

Wichtig: Sie könnten diese Dateien für Troubleshooting brauchen

Löschen Sie die Informationen in diesen Dateien nicht einfach so. Wenn Sie eine Störung analysieren wollen, fehlen Ihnen sonst die Informationen.

Solange die Dateien keine Probleme verursachen lassen Sie sie einfach da. Sie werden bei jedem Durchlauf des Agenten sowieso wieder befüllt (es bringt also nichts sie zu löschen) und sie verbrauchen kaum Speicher (1 – 10 MB)

Vor dem Löschen: erst lesen, dann entscheiden

In der In diesen Dateien stehen relevante Informationen: Hinweise auf Fehlkonfigurationen, Login-Probleme, Dienst-Abstürze, Policy-Änderungen usw. Deshalb:

• Dateien ansehen (z. B. mit less) oder
• auf Ihren Admin-PC kopieren (z. B. via scp) und archivieren

Wenn Sie bei Shell-Tools unsicher sind: Ein kurzer Abstecher zu Texteditoren hilft – je nachdem, ob Sie eher nano oder vim nutzen. (Wir haben dazu eine gute Einordnung in nano vs vim – welcher Unix-Texteditor ist besser?.)

So löschen (bzw. leeren) Sie die Checkmk-Logwatch-Dateien auf der OMD-Site

Ausgangslage aus der Praxis: Sie finden auf dem Checkmk-Server in Ihrer Site unterhalb von var/check_mk/logwatch/ hostbezogene Dateien.

1) In das richtige Verzeichnis wechseln

Typischer Pfad (bitte Site-Namen und Host-FQDN anpassen):

cd /omd/sites/<sitename>/var/check_mk/logwatch/<FQDN>
ls -lah

Dort sehen Sie dann z. B. Application und Security.

2) Inhalt leeren statt „hart löschen“

In vielen Fällen ist Truncaten (Datei auf 0 Byte setzen) die sauberere Variante, weil Rechte/Owner/Datei-Existenz erhalten bleiben.

echo > Application
echo > Security

Alternative, etwas „klassischer“:

: > Application
: > Security

Beide Varianten setzen die Datei auf Größe 0 – Sprich, die Datei wird ausgelehrt.

3) Optional: Ownership und Rechte prüfen

Wenn Sie als Instanzbenutzer arbeiten (z. B. OMD[sitename]:~$), passt das meist. Falls nicht:

ls -l

Bei auffälligen Berechtigungen sollten Sie erst klären, warum das so ist, bevor Sie weiter herumprobieren.

Was passiert danach im Monitoring?

Nach dem Leeren passiert typischerweise Folgendes:

• Der Logwatch-Service liefert wieder einen „frischen“ Zustand, weil Checkmk keine alten Meldungen aus genau dieser Datei mehr sieht.
• Neue Logereignisse laufen ab dann wieder normal ein und werden gemäß Ihrer Regeln bewertet.
• Wenn die Datei ein Arbeitsstand/„Batch“ für bereits erkannte Meldungen war, kann es sein, dass Meldungen kurzfristig nicht mehr als „unbestätigt“ erscheinen, weil Sie den lokalen Kontext weggenommen haben.

Wichtig: Logwatch basiert darauf, nur neue Zeilen seit dem letzten Durchlauf zu verarbeiten. In der Checkmk-Doku wird dieses Prinzip explizit beschrieben („alle neuen Zeilen seit dem letzten Durchlauf“). Wenn Sie State-/Arbeitsstände zurücksetzen, beeinflussen Sie genau diese „seit dem letzten Mal“-Logik. (docs.checkmk.com)

Zusammenfassung

Wir haben also gelernt:

• Checkmk nutzt die Logwatch-Logdateien um ein performanteres – und effizienteres Monitoring zu ermöglichen.
• Es macht Sinn, die Logwatch-Logdateien zu löschen, wenn Sie sich aufgehängt haben oder überlaufen.
• Es macht Sinn, die Logwatch-Logdateien zu löschen, wenn Sie große Änderungen an dem Host System vorgenommen haben und die Checkmk Informationen „auffrischen“ wollen.
• Es macht keinen Sinn, die Logwatch-Logdateien zu löschen, um Platz zu schaffen, da diese beim nächsten Check-Durchlauf sowieso wieder befüllt werden und ohnehin nicht viel Speicher verbrauchen.
• Wenn Sie die Dateien löschen, machen Sie nichts kaputt, jedoch wäre es schlau diese vorher durchzulesen oder zu archivieren, falls Sie diese mal zur Fehlersuche benötigen.

Zusätzliche Beiträge und Informationen

Wenn Sie Checkmk noch gar nicht im Einsatz haben und sich erstmal darüber informieren möchten, lohnt sich auch ein Blick auf die Grundlagen – z. B. in unserem Beitrag Was ist Checkmk?.

Wenn Sie Checkmk bereits in Ihrem Betrieb einsetzen und es personalisieren möchten, wäre der Artikel Custom Checks in Checkmk: eigene Scripte sauber integrieren und als Local Check ausrollen sicher interessant für Sie.

Brauchen Sie Unterstützung bei der Installation und Konfiguration von Checkmk, schauen Sie sich den Infobereich auf unserer Webseite an oder rufen Sie uns an. Wir helfen gerne!