Analyse av nett- og applikasjonslogger i stor skala

Alle HTTP-servere – Apache, Nginx og Caddy – skriver én linje i en tilgangslogg for hver forespørsel. Å forstå strukturen i disse linjene er grunnlaget for alt arbeid med logganalyse.

En typisk linje i Combined Log Format (CLF) ser slik ut:

• Klient-IP – hvem som sendte forespørselen
• Tidsstempel – når det skjedde
• Forespørselslinje – metode, sti og protokoll
• Statuskode – HTTP-svaret (200, 404, 500…)
• Sendte byte – størrelsen på svarinnholdet
• Referer – kildesiden
• User-Agent – streng som identifiserer nettleseren eller boten

Eksempel på en linje fra /var/log/nginx/access.log:

192.168.1.10 - alice [11/Jun/2026:14:32:01 +0000] "GET /api/orders HTTP/1.1" 200 1482 "-" "curl/7.88.1"

I stor skala vokser disse filene til millioner av linjer per dag. Målet med denne leksjonen er å hente ut, filtrere og aggregere felt fra dem effektivt ved hjelp av standardverktøy i BASH.

Før De skriver en pipeline, bør De undersøke loggen for å forstå strukturen. tail lar Dem følge en strøm i sanntid, mens grep umiddelbart begrenser den til relevante linjer.

Vanlige mønstre:

• tail -n 1000 access.log – de siste 1000 linjene
• tail -f access.log – følg loggen i sanntid
• tail -f access.log | grep '" 5' – bare 5xx-feil etter hvert som de oppstår

Det viktige poenget er at grep sammenligner med hele linjen, så det er viktig å forankre mønsteret riktig. Ved å søke etter ' 500 ' (med mellomrom) unngår De å treffe en URL-sti som inneholder strengen 500 ved et uhell.

cut deler hver linje ved hjelp av et skilletegn og skriver ut valgte felt. I Combined Log Format ligger statuskoden i felt 9 når De deler på mellomrom – men anførselstegnene rundt forespørselslinjen gjør det tryggere å telle fra et kjent ankerpunkt.

Et pålitelig triks er at forespørselslinjen alltid står mellom anførselstegn. Statuskoden er derfor alltid det første tokenet etter det avsluttende anførselstegnet for forespørselsfeltet. Med cut -d'"' -f3 isolerer De alt etter anførselstegnet som avslutter forespørselen, og deretter henter et nytt cut -d' ' -f2 ut statuskoden.

Denne todelte cut-metoden er en klassisk idiom for CLF-logger – rask og uten eksterne avhengigheter.

awk er kraftigere enn cut fordi det kan samle tilstand på tvers av linjer. Det idiomatiske mønsteret for å telle forekomster er en assosiativ tabell med nøkkel basert på verdien De ønsker å telle.

I CLF er felt $9 (indeksert fra 1 og avgrenset med mellomrom) statuskoden. awk behandler hver linje, øker en teller og skriver deretter ut et sortert sammendrag i END-blokken.

Hvorfor foretrekke awk fremfor cut | sort | uniq -c? Fordi awk gjør dette i én enkeltpassering uten å sortere hele filen først – noe som er avgjørende når loggen er på hundrevis av gigabyte.

En av de vanligste driftsoppgavene er å finne ut hvilke klient-IP-er som genererer flest feil. Dette kombinerer filtrering (bare feillinjer) med felthenting (IP-adressen i felt 1).

Pipeline-strategien:

• Bruk awk til å filtrere på statuskodeintervall og hente ut IP-adressen i ett trinn – unngå en separat grep-passering
• Send resultatet videre med sort | uniq -c | sort -rn | head for å få en rask oversikt over de N øverste

Dette mønsteret er raskt nok til å kjøres mot en loggfil på 10 GB på én enkelt server uten å laste filen inn i minnet.

Applikasjonsservere (Rails, Gunicorn, Express med morgan og lignende) logger ofte varigheten på forespørsler. Nginx kan konfigureres til å skrive ut $request_time som et ekstra felt på slutten av hver linje.

Eksempel på et egendefinert Nginx-loggformat i nginx.conf:

log_format timed '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" rt=$request_time';

Når svartiden finnes i loggen, kan De bruke awk til å beregne gjennomsnitt, maksimum og tilnærmede persentiler for millioner av forespørsler uten å laste dataene inn i en database.

Et enkelt gjennomsnitt skjuler haleforsinkelsen. Et histogram viser fordelingen – om de fleste forespørslene er raske og noen få er svært trege (en lang hale), eller om fordelingen er jevn.

Trikset er å plassere hver verdi i et avrundet intervall ved hjelp av heltallsaritmetikk i awk. Ved å multiplisere med 1000 (konvertere sekunder til millisekunder) og deretter bruke heltallsdivisjon får De tydelige intervallgrenser.

Resultatet er et tekstdrevet histogram som De kan lese direkte i en terminal. Det er ofte raskere enn å sende data til Grafana for en rask undersøkelse.

User-Agent-feltet (felt 6 når De deler på ") identifiserer klientene. Crawlere, skrapere og ondsinnede boter forstyrrer ofte måleverdiene og blåser opp feiltallene. Ved å filtrere dem bort får De et tydeligere bilde av trafikken fra faktiske brukere.

Vanlige bot-signaturer: bot, crawler, spider, curl, python-requests, Googlebot, Bingbot.

Bruk grep -iv (invertert søk uten hensyn til store og små bokstaver) for å utelate kjente boter, eller bruk awk til å dele på " og sammenligne UA-feltet direkte.

Ved å vite hvilke endepunkter som mottar mest trafikk – og genererer flest feil – blir det enklere å prioritere optimalisering og kapasitetsplanlegging. Forespørselsstien ligger i det anførselstegninnrammede forespørselsfeltet.

Del på ", ta felt 2 (forespørselslinjen), og fjern deretter metode og protokoll for å isolere stien. For API-er med sti-parametere som /users/12345 kan De også ønske å normalisere ID-er til /users/:id ved hjelp av sed eller et mer komplekst awk-mønster.

Den kraftigste analysen i én enkelt passering kombinerer flere felt samtidig: endepunkt, statuskode og eventuelt svartid. Assosiative tabeller i awk med sammensatte nøkler gjør dette ryddig og raskt.

Mønsteret nedenfor teller 5xx-feil per endepunkt i én passering – uten midlertidige filer og uten mellomliggende sortering før helt til slutt. Dette er fremgangsmåten som brukes i produksjonsskript for observability når De trenger svar på under ett minutt fra en stor logg.

På de fleste servere roteres logger daglig. Eldre filer komprimeres med gzip og får navn som access.log.1.gz, access.log.2.gz og så videre. Standardverktøy kan ikke lese dem direkte, men to fremgangsmåter fungerer godt:

• zcat – dekomprimerer til standardutdata, slik at De kan sende resultatet inn i pipelinen
• zgrep – søker direkte i gzip-filer uten å pakke dem ut

Hvis De vil analysere en hel uke med logger som omfatter både ukomprimerte og komprimerte filer, kan De bruke prosessubstitusjon eller sette sammen filene med zcat. Utdraget nedenfor behandler de siste 7 roterte filene samt den aktive loggen i ett enkelt awk-kall – uten behov for midlertidige filer.

I denne leksjonen bygget De et komplett verktøysett for å analysere web- og applikasjonslogger i stor skala, kun ved hjelp av standardverktøy i BASH.

Viktige teknikker:

• Start med strukturen — Combined Log Format har en forutsigbar feltstruktur. Når De kjenner den, kan De dele opp loggen pålitelig med cut -d'"' eller felthenvisninger i awk.
• Hente ut statuskoder — awk '{ count[$9]++ }' teller alle kodene i én gjennomgang. Filtrer med $9 ~ /^5/ for serverfeil.
• Analysere forsinkelse — tolk det egendefinerte rt=-feltet med awk for å beregne gjennomsnitt, maksimumsverdier og histogramintervaller uten eksterne verktøy.
• Analysere klienter og boter — del på " med -F'"' for å komme til User-Agent-feltet. Send deretter resultatet gjennom grep -iv for å utelate boter før aggregering.
• Normalisere endepunkter — bruk gsub(/\/[0-9]+/, "/:id") i awk for å slå sammen parametriserte stier før opptelling.
• Roterte logger — kombiner cat og zcat i et subshell for å sende alle rotasjonsfilene gjennom én samlet pipeline.

Disse mønstrene kan kombineres: De kan kjede sammen filtrering, uthenting, normalisering og aggregering i én pipeline som behandler hundrevis av millioner linjer på standard maskinvare. Når De behersker disse grunnprinsippene, trenger De sjelden en dedikert loggaggregeringstjeneste for ad hoc-undersøkelser av hendelser.