≋

Log-Triage

Wichtige Vorfälle erkennen

Eingabe

Aug 22 14:06:11 node1 kernel: Out of memory: Killed process 8492 (java)
Aug 22 14:06:14 node1 sshd[9201]: Failed password for invalid user admin
Aug 22 14:07:02 node1 systemd[1]: backup.service: Failed with result 'exit-code'

Ergebnis3 Befunde

!Speichererschöpfung / OOM-Ereignis — 1 passende Zeile(n).
△Authentifizierungs- oder Zugriffsfehler — 1 passende Zeile(n).
△Dienstfehler oder Zeitüberschreitung — 2 passende Zeile(n).

Einführung

Log-Triage durchsucht eingefügte Journal- oder Syslog-Zeilen und zählt Treffer in vier Kategorien mit hohem Signal: Speichererschöpfung (OOM), Abstürze und Datenintegritätssignale, Authentifizierungsfehler sowie allgemeine Dienstfehler oder Zeitüberschreitungen.

Protokolle sind von Natur aus laut. Die Aufgabe des Werkzeugs ist es, das Rauschen auf die wenigen Zeilen zu reduzieren, die meist eine Incident-Antwort verdienen, damit Sie direkt zum relevanten Kontext springen können.

Ziel

OOM-Kills und Out-of-Memory-Ereignisse zählen, die auf Speicherdruck hinweisen.
Absturz-, Segfault-, Panic- und Korruptionssignale zählen, die auf Stabilitäts- oder Integritätsprobleme hinweisen.
Authentifizierungsfehler zählen, die auf Brute-Force oder Fehlkonfiguration hindeuten können.
Dienstfehler und Zeitüberschreitungen zählen, die Alltagsursache degradierter Systeme.

Eingaben

Eine Einfügung von Journal-Ausgabe (journalctl -n 500 --no-pager), Syslog-Zeilen oder Anwendungsprotokollen.
Eine Protokollzeile pro eingefügter Zeile; jedes Zeitformat ist akzeptiert, da die Übereinstimmung stichwortbasiert ist.

So funktioniert es

Jede eingefügte Zeile wird gegen vier reguläre Ausdrucksgruppen in Reihenfolge getestet: OOM-Stichwörter (out of memory, oom, killed process), Absturz-Stichwörter (segfault, panic, corrupt), Authentifizierungs-Stichwörter (failed password, authentication failure, denied) und Fehler-Stichwörter (failed, error, timeout).

Jeder Treffer erhöht den Zähler seiner Gruppe. Eine Zeile kann in mehreren Gruppen zählen, so wie ein Mensch beim Lesen die Zeile mehrfach markieren würde.

Gruppen ohne Treffer werden im Ergebnis weggelassen, sodass ein ruhiges Protokoll ein einziges sauberes Ergebnis erzeugt.

Testbares Beispiel

Ausprobieren — die Analyse läuft lokal in Ihrem Browser.

Beispiel

Aug 22 14:06:11 node1 kernel: Out of memory: Killed process 8492 (java)
Aug 22 14:06:14 node1 sshd[9201]: Failed password for invalid user admin
Aug 22 14:07:02 node1 systemd[1]: backup.service: Failed with result 'exit-code'

Erwartete Ausgabe

Hoch: Speichererschöpfung / OOM-Ereignis — 1 passende Zeile.
Warnung: Authentifizierungs- oder Zugriffsfehler — 1 passende Zeile.
Warnung: Dienstfehler oder Zeitüberschreitung — 1 passende Zeile.

Ausgabe verstehen

OOM-Ereignisse weisen auf Speicherdruck: cgroup-Limits, Swap und den getöteten Prozess prüfen.
Authentifizierungsfehler verdienen einen Blick darauf, wer es versucht und wie oft; wiederholte Versuche mit ungültigen Benutzern deuten oft auf Scannen oder Brute-Force hin.
Dienstfehler (Failed with result 'exit-code') untersucht man am besten mit journalctl -u <unit> -e, um Exit-Code und umgebende Zeilen zu sehen.

Risiken

Stichwortübereinstimmung erzeugt Fehlalarme und verliert Kontext — eine Zeile mit "no errors found" enthält das Wort error und wird gezählt.
Zählen als Triage behandeln, nicht als Beweis eines Vorfalls.
Das Werkzeug liest Ihre Protokolle nie von der Platte; es sieht nur, was Sie einfügen — das ist das Datenschutzdesign der gesamten Website.

Grenzen

Es parst keine Zeitstempel, korreliert keine Ereignisse über Hosts und erkennt keine Sequenzen.
Die RegExp-Gruppen sind bewusst einfach; benutzerdefinierte Muster werden nicht unterstützt.
Es ist eine Triage-Hilfe, kein SIEM.

Offizielle Referenzen

FAQ

Warum wird eine harmlos aussehende Zeile als Fehler markiert?

Weil die Übereinstimmung stichwortbasiert ist. Eine Zeile wie "no error found" enthält den Begriff error. Wenn das stört, verkleinern Sie die Einfügung auf die relevanten Zeilen.

Was sollte ich nach einem OOM-Ereignis tun?

Den getöteten Prozess identifizieren, sein Speicherlimit und den Speicherdruck des Hosts prüfen, dann entscheiden: Limits erhöhen, Parallelität senken oder Speicher ergänzen.

Kann das mein Monitoring ersetzen?

Nein. Es ist eine manuelle Triage-Hilfe für Einfügungen. Kontinuierliches Monitoring, Alarmierung und Korrelation brauchen eine echte Logging-Umgebung.