Protokolldatei-Parser

Rohe Protokolldateien sind Wände aus Zeitstempeln, Ebenen und Freitextnachrichten. Fügen Sie ein Nginx-Zugriffsprotokoll, ein Apache-Fehlerprotokoll, einen Syslog-Dump oder eine Laravel-Kanaldatei ein, und der Parser teilt es in strukturierte Zeilen auf, ermöglicht das Filtern nach ISO-Datumsbereich, Schweregrad (DEBUG bis EMERGENCY), Client-IP oder Regex gegen die Nachricht und hebt Treffer hervor, sodass Sie tatsächlich sehen können, was im Vorfallfenster passiert ist.

So parsen Sie eine Protokolldatei

  1. 1

    Protokollinhalt einfügen

    Fügen Sie den rohen Protokolltext ein. Häufige Formate (kombiniert, allgemein, syslog, JSON-Zeilen) werden automatisch erkannt.

  2. 2

    Datumsfilter festlegen

    Verwenden Sie einen Start-/Endzeitstempel, um sich auf das Vorfallfenster zu konzentrieren.

  3. 3

    Nach Ebene oder IP filtern

    Wählen Sie Schweregrade aus, geben Sie eine IP ein oder geben Sie ein Regex-Muster ein, um Nachrichten zuzuordnen.

  4. 4

    Tabelle lesen

    Jede Zeile zeigt Zeitstempel, Ebene, Quelle und Nachricht mit hervorgehobenen Übereinstimmungen.

Formate, die der Parser erkennt

Format Beispiel Quelle
Nginx kombiniert 1.2.3.4 - - [18/Apr/2026:10:00:00 +0000] "GET / HTTP/1.1" 200 1234 Webzugriffsprotokolle
Apache allgemein Dasselbe wie oben, ohne Referer und User-Agent klassische LAMP-Stacks
Syslog RFC 5424 <34>1 2026-04-18T10:00:00Z host app - ID47 - msg Linux-System-Daemons
Laravel täglich [2026-04-18 10:00:00] production.ERROR: Nachricht Laravel-Protokollkanal
JSON-Zeilen {"ts":"...","level":"ERROR","msg":"..."} strukturierte Logger, Loki, ELK

Standardprotokollebene

Von lautesten bis leisesten aufgelistet. Die meisten Apps folgen der syslog / PSR-3-Reihenfolge:

  1. EMERGENCY, System unbrauchbar.
  2. ALERT, sofortige Maßnahmen erforderlich.
  3. CRITICAL, kritischer Zustand, z.B. Datenbank ausgefallen.
  4. ERROR, Laufzeitfehler, der untersucht werden sollte.
  5. WARNING, außergewöhnlicher Zustand, kein Fehler.
  6. NOTICE, normales, aber bedeutendes Ereignis.
  7. INFO, allgemeine Betriebsnachrichten.
  8. DEBUG, niedrigstufige Diagnose, laut in der Produktion.

Filtertipps

  • Zuerst nach Datum eingrenzen. Die meisten Produktionsprotokolle sind riesig; das Eingrenzen auf das Vorfallfenster macht jeden anderen Filter schnell.
  • Verwenden Sie Regex für Nachrichten. Die Suche nach timeout|connection refused|5\d\d erfasst die meisten Netzwerkfehler in einem Durchgang.
  • Einen IP isolieren. Bei der Untersuchung eines verdächtigen Clients alles andere herausfiltern und ihre Anfragen chronologisch lesen.
  • Crawler ausschließen. User-Agent-Teilstrings wie bot, crawl, spider filtern den meisten Lärm aus Analysen heraus.

Leistungsnotizen

  • Der Parser läuft clientseitig, sodass die Zeilen auf Ihrem Gerät bleiben. Das bedeutet auch, dass sehr große Dateien (100 MB+) den Browser verlangsamen, teilen Sie sie zuerst mit split -l oder streamen Sie sie über ein serverseitiges Tool.

Häufig gestellte Fragen

Nein. Parsing und Filtern erfolgen in Ihrem Browser. Das Protokoll, das Sie einfügen, verlässt niemals Ihr Gerät, was wichtig ist für Dateien, die IPs, Tokens oder PII enthalten können.

Ja, Zeilen, die mit Leerzeichen oder at ... beginnen, werden an den vorherigen Protokolleintrag angehängt, sodass ein vollständiger Ausnahme-Stack in einer Zeile bleibt.

Verwenden Sie den Regex-Filter für die Nachrichten-Spalte. Bei strukturierten JSON-Protokollen sind alle Schlüssel als Klartext in der Nachricht durchsuchbar.

Nicht direkt, zuerst mit gunzip oder einem Dateitool dekomprimieren und den rohen Text einfügen. Der Parser erwartet unkomprimierte Protokollzeilen.

Es gibt kein festes Limit, aber alles über 10 MB kann das Filtern verlangsamen. Bei großen Archiven zuerst auf dem Server mit grep filtern und die gefilterte Ausgabe hier einfügen.

Verwandte Tools

Tool in anderen Sprachen verfügbar