Parser di file di log

I file di log grezzi sono muri di timestamp, livelli e messaggi di testo libero. Incolla un log di accesso Nginx, un log di errore Apache, un dump di syslog o un file di canale Laravel e il parser lo suddivide in righe strutturate, permettendoti di filtrare per intervallo di date ISO, gravità (DEBUG fino a EMERGENCY), IP del client o regex contro il messaggio, e evidenzia i colpi in modo da poter vedere effettivamente cosa è successo nella finestra dell’incidente.

Come analizzare un file di log

  1. 1

    Incolla il contenuto del log

    Trascina il testo del log grezzo. I formati comuni (combined, common, syslog, JSON-lines) vengono rilevati automaticamente.

  2. 2

    Imposta il filtro di data

    Usa un timestamp di inizio/fine per concentrarti sulla finestra dell'incidente.

  3. 3

    Filtra per livello o IP

    Seleziona i livelli di gravità, digita un IP o inserisci un modello regex per abbinare i messaggi.

  4. 4

    Leggi la tabella

    Ogni riga mostra timestamp, livello, sorgente e messaggio con segmenti corrispondenti evidenziati.

Formati riconosciuti dal parser

Formato Esempio Sorgente
Nginx combined 1.2.3.4 - - [18/Apr/2026:10:00:00 +0000] "GET / HTTP/1.1" 200 1234 log di accesso web
Apache common Stesso di sopra meno Referer e User-Agent stack LAMP classici
Syslog RFC 5424 <34>1 2026-04-18T10:00:00Z host app - ID47 - msg demoni di sistema Linux
Laravel daily [2026-04-18 10:00:00] production.ERROR: message canale di log Laravel
JSON lines {"ts":"...","level":"ERROR","msg":"..."} logger strutturati, Loki, ELK

Livelli di log standard

Elencati dal più forte al più debole. La maggior parte delle app segue l’ordine syslog / PSR-3:

  1. EMERGENCY, sistema inutilizzabile.
  2. ALERT, azione immediata richiesta.
  3. CRITICAL, condizione critica, ad es. database non disponibile.
  4. ERROR, errore di runtime che dovrebbe essere indagato.
  5. WARNING, condizione eccezionale, non un errore.
  6. NOTICE, evento normale ma significativo.
  7. INFO, messaggi operativi generali.
  8. DEBUG, diagnostica a basso livello, rumorosa in produzione.

Suggerimenti per il filtraggio

  • Ristretto per data prima. La maggior parte dei log di produzione è enorme; ridurre alla finestra dell’incidente rende ogni altro filtro veloce.
  • Usa regex per i messaggi. Cercare timeout|connection refused|5\d\d cattura la maggior parte dei guasti di rete in un colpo solo.
  • Isola un IP. Quando indaghi su un client sospetto, filtra tutto il resto e leggi le loro richieste in ordine cronologico.
  • Escludi crawler. Sottostringhe di User-Agent come bot, crawl, spider filtrano la maggior parte del rumore da indagini in stile analytics.

Note sulle prestazioni

  • Il parser funziona lato client, quindi le righe rimangono sul tuo dispositivo. Ciò significa anche che file molto grandi (oltre 100 MB) rallenteranno il browser, dividili prima con split -l o trasmettili tramite uno strumento lato server.

Domande frequenti

No. L’analisi e il filtraggio avvengono nel tuo browser. Il log che incolli non lascia mai il tuo dispositivo, il che è importante per i file che possono contenere IP, token o PII.

Sì, le righe che iniziano con spazi bianchi o at ... sono collegate all’elemento di log precedente, quindi un’intera eccezione rimane in una riga.

Usa il filtro regex contro la colonna del messaggio. Per i log JSON strutturati, tutte le chiavi sono ricercabili come testo semplice nel messaggio.

Non direttamente, decomprimi prima con gunzip o uno strumento di file e incolla il testo grezzo. Il parser si aspetta righe di log non compresse.

Non c’è un limite rigido, ma qualsiasi cosa oltre 10 MB potrebbe rallentare il filtraggio. Per archivi grandi, usa grep sul server prima e incolla qui l’output filtrato.

Strumenti correlati

Strumento disponibile in altre lingue