Loggfilanalysator

Råa loggfiler består av massor av tidsstämplar, nivåer och fristående textmeddelanden. Klistra in en Nginx-åtkomstlogg, en Apache-fellogg, en syslog-dump eller en Laravel-kanalfil – parsern delar sedan in innehållet i strukturerade rader och gör det möjligt att filtrera efter ISO-datumintervall, allvarlighetsgrad (från DEBUG till EMERGENCY), klientens IP-adress eller reguljärt uttryck i meddelandet. Dessutom markerar den de relevanta händelserna så att du kan se exakt vad som inträffade under den aktuella händelseperioden.

Hur man analyserar en loggfil

  1. 1

    Klistra in loggdata

    Klistra in den råa loggtexten. Vanliga format (combined, common, syslog, JSON-lines) upptäcks automatiskt.

  2. 2

    Sätt datumfilter

    Använd en start- och sluttidstempel för att förstora händelsefönsteret.

  3. 3

    Filtrera efter nivå eller IP-adress

    Markera allvarlighetsnivåer, ange en IP-adress eller ett reguljärt uttryck för att matcha meddelanden.

  4. 4

    Läs tabellen

    Varje rad visar tidsstämpel, nivå, källa och meddelande, där motsvarande segment är markerade.

Format som parsern känner igen

Format Exempel Källa
Nginx kombinerad 1.2.3.4 - - [18/Apr/2026:10:00:00 +0000] "GET / HTTP/1.1" 200 1234 webbåtkomstloggar
Apache Common Samma som ovan, med undantag för Referer och User-Agent klassiska LAMP-stackar
Syslog RFC 5424 <34>1 2026-04-18T10:00:00Z host app - ID47 - msg Linux-systemdemoner
Laravel dagligt [2026-04-18 10:00:00] production.ERROR: message Laravel logkanal
JSON-rader {"ts":"...","level":"ERROR","msg":"..."} strukturerade loggverktyg, Loki, ELK

Standardloggnivåer

Utsorterade från mest till minst ljudstarka. De flesta appar följer ordningen syslog/PSR-3:

  1. EMERGENCY – systemet är oanvändbart.
  2. ALERT – omedelbar åtgärd krävs.
  3. CRITICAL – kritiskt tillstånd, t.ex. nedstängd databas.
  4. ERROR – körfel som bör undersökas.
  5. WARNING – exceptionellt tillstånd, inte ett fel.
  6. NOTICE – normal men betydande händelse.
  7. INFO – allmänna driftmeddelanden.
  8. DEBUG – diagnostik på låg nivå, brusig under produktionen.

Tips för filtrering

  • Begränsa först efter datum. De flesta produktionsloggar är mycket omfattande; att begränsa dem till händelseperioden gör alla andra filter snabbare.
  • Använd regex för meddelanden. Att söka efter timeout|connection refused|5\d\d identifierar de flesta nätverksfel i ett enda svep.
  • Isolera en IP-adress. När du undersöker en misstänkt klient, filtrera bort allt annat och läs dess förfrågningar i kronologisk ordning.
  • Uteslut sökrobotar. Delsträngar i User-Agent som bot, crawl och spider filtrerar bort största delen av bruset från analysinriktade undersökningar.

Prestandaanmärkningar

  • Parsern körs på klientsidan, så raderna stannar på din dator. Det innebär också att mycket stora filer (över 100 MB) kan bromsa webbläsaren – dela upp dem först med split -l eller strömma dem via ett verktyg på serversidan.

Vanliga frågor

Nej, analys och filtrering sker i din webbläsare. Det loggar som du klistrar in lämnar aldrig din enhet – vilket är särskilt viktigt för filer som kan innehålla IP-adresser, token eller personuppgifter (PII).

Ja – rader som börjar med blanksteg eller at ... kopplas till den föregående loggposten, så att hela undantagsstacken förblir på en enda rad.

Använd regex-filtret på meddelandekolumnen. För strukturerade JSON-loggar kan alla nycklar sökas i meddelandet som vanlig text.

Inte direkt – komprimera först med gunzip eller ett filverktyg och klistra in den råa texten. Parsern kräver okomprimerade logglinjer.

Det finns ingen strikt gräns, men allt som överstiger 10 MB kan bromsa filtreringen. För stora arkiv rekommenderas att du först använder grep på servern och sedan klistrar in den filtrerade utdatan här.

Relaterade verktyg

Verktyget finns på andra språk