Analizzare log web e applicativi su larga scala

Ogni server HTTP — Apache, Nginx, Caddy — scrive una riga in un log degli accessi per ogni richiesta. Comprendere la struttura di queste righe è il fondamento di qualsiasi attività di analisi dei log.

Una riga tipica nel Combined Log Format (CLF) è simile alla seguente:

• IP del client — chi ha effettuato la richiesta
• Timestamp — quando si è verificata
• Riga della richiesta — metodo, percorso, protocollo
• Codice di stato — risposta HTTP (200, 404, 500…)
• Byte inviati — dimensione del corpo della risposta
• Referer — pagina di origine
• User-Agent — stringa del browser o del bot

Esempio di riga da /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"

Su larga scala, questi file arrivano a contenere milioni di righe al giorno. L'obiettivo di questa lezione è estrarre, filtrare e aggregare in modo efficiente i campi utilizzando gli strumenti BASH standard.

Prima di scrivere una pipeline, esamini il log per comprenderne la struttura. tail consente di osservare un flusso in tempo reale; grep lo restringe immediatamente alle righe pertinenti.

Pattern comuni:

• tail -n 1000 access.log — ultime 1000 righe
• tail -f access.log — segue il file in tempo reale
• tail -f access.log | grep '" 5' — solo gli errori 5xx man mano che arrivano

L'intuizione fondamentale è che grep esegue la corrispondenza sull'intera riga, quindi è importante delimitare correttamente il pattern. Cercare ' 500 ' (con gli spazi) evita di trovare accidentalmente un percorso URL che contiene la stringa 500.

cut suddivide ogni riga in base a un delimitatore e stampa i campi selezionati. Nel Combined Log Format il codice di stato si trova al campo 9 quando si suddivide in base agli spazi, ma le virgolette intorno alla riga della richiesta rendono più sicuro contare a partire da un punto di riferimento noto.

Un metodo affidabile consiste nel considerare che la riga della richiesta è sempre racchiusa tra virgolette: il codice di stato è quindi sempre il primo token dopo la virgoletta di chiusura del campo della richiesta. Utilizzando cut -d'"' -f3 si isola tutto ciò che segue la virgoletta della richiesta; un secondo cut -d' ' -f2 seleziona il codice di stato.

Questo cut in due passaggi è un idioma classico per i log CLF: è veloce e non richiede dipendenze esterne.

awk è più potente di cut perché può mantenere uno stato tra le righe. Il pattern idiomatico per contare le occorrenze consiste nell'utilizzare un array associativo indicizzato dal valore di interesse.

Nel CLF, il campo $9 (indicizzato a partire da 1 e delimitato dagli spazi) contiene il codice di stato. awk elabora ogni riga, incrementa un contatore e poi stampa un riepilogo ordinato nel blocco END.

Perché preferire awk a cut | sort | uniq -c? Perché awk esegue tutto in un unico passaggio, senza ordinare prima l'intero file — un aspetto fondamentale quando il log ha dimensioni di centinaia di gigabyte.

Una delle attività operative più comuni consiste nell'individuare gli IP dei client che generano il maggior numero di errori. Questa operazione combina il filtraggio (solo le righe con errori) con l'estrazione dei campi (l'IP al campo 1).

Strategia della pipeline:

• Utilizzi awk per filtrare in base all'intervallo del codice di stato ed estrarre l'IP in un unico passaggio — eviti un passaggio separato con grep
• Passi il risultato a sort | uniq -c | sort -rn | head per ottenere rapidamente una vista dei primi N risultati

Questo pattern è sufficientemente veloce da poter essere eseguito su un file di log da 10 GB su un singolo server, senza caricare il file in memoria.

I server applicativi (Rails, Gunicorn, Express con morgan e altri) registrano spesso la durata delle richieste. Nginx può essere configurato per emettere $request_time come campo aggiuntivo alla fine di ogni riga.

Esempio di formato di log Nginx personalizzato in nginx.conf:

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

Una volta registrata la latenza nel log, può utilizzare awk per calcolare media, massimo e approssimazioni dei percentili su milioni di richieste, senza caricare i dati in un database.

Una singola media nasconde la latenza nella coda della distribuzione. Un istogramma mostra la distribuzione: indica se la maggior parte delle richieste è rapida e alcune sono molto lente (coda lunga), oppure se la distribuzione è uniforme.

Il trucco consiste nel raggruppare ogni valore in un intervallo arrotondato utilizzando l'aritmetica intera all'interno di awk. Moltiplicare per 1000 (convertendo i secondi in millisecondi) e poi utilizzare la divisione intera produce limiti dei gruppi ordinati.

Il risultato è un istogramma testuale leggibile direttamente in un terminale, spesso più rapido dell'invio dei dati a Grafana per un'analisi veloce.

Il campo User-Agent (campo 6 quando si suddivide in base a ") identifica i client. Crawler, scraper e bot dannosi spesso alterano le metriche e aumentano artificialmente il conteggio degli errori. Filtrarli consente di ottenere un'immagine più accurata del traffico degli utenti reali.

Firme comuni dei bot: bot, crawler, spider, curl, python-requests, Googlebot, Bingbot.

Utilizzi grep -iv (inversione senza distinzione tra maiuscole e minuscole) per escludere i bot conosciuti, oppure utilizzi awk per suddividere in base a " e confrontare direttamente il campo UA.

Sapere quali endpoint ricevono più traffico — e generano più errori — aiuta a stabilire le priorità per l'ottimizzazione e la pianificazione della capacità. Il percorso della richiesta si trova all'interno del campo della richiesta racchiuso tra virgolette.

Suddivida in base a ", selezioni il campo 2 (la riga della richiesta), quindi estragga il metodo e il protocollo per isolare il percorso. Per le API con parametri nel percorso, come /users/12345, potrebbe anche voler normalizzare gli ID in /users/:id utilizzando sed o un pattern awk più complesso.

L'analisi single-pass più potente combina contemporaneamente più campi: endpoint, codice di stato e, facoltativamente, latenza. Gli array associativi di awk indicizzati da valori composti rendono questa operazione semplice e veloce.

Il pattern seguente conta gli errori 5xx per endpoint in un unico passaggio: nessun file temporaneo e nessun ordinamento intermedio fino alla fine. Questo è l'approccio utilizzato negli script di observability in produzione quando servono risposte in meno di un minuto su un log di grandi dimensioni.

Nella maggior parte dei server i log vengono ruotati ogni giorno. I file più vecchi vengono compressi con gzip come access.log.1.gz, access.log.2.gz e così via. Gli strumenti standard non possono leggerli direttamente, ma due approcci funzionano senza problemi:

• zcat — decomprime verso lo standard output e passa il risultato alla pipeline
• zgrep — esegue grep direttamente nei file gzip senza estrarli

Per analizzare un'intera settimana di log comprendenti file non compressi e compressi, utilizzi la sostituzione di processo oppure concateni i file con zcat. Il frammento seguente elabora gli ultimi 7 file ruotati e il log corrente in tempo reale in un'unica chiamata a awk, senza bisogno di file temporanei.

In questa lezione ha creato un toolkit completo per analizzare su larga scala i log web e delle applicazioni utilizzando solo le utility BASH standard.

Tecniche principali trattate:

• Prima la struttura — il Combined Log Format ha una disposizione dei campi prevedibile; conoscerla consente di suddividere i dati in modo affidabile con cut -d'"' o con i riferimenti ai campi di awk.
• Estrazione del codice di stato — awk '{ count[$9]++ }' conta tutti i codici in un'unica passata; utilizzi $9 ~ /^5/ per filtrare gli errori del server.
• Analisi della latenza — analizzi il campo personalizzato rt= con awk per calcolare medie, valori massimi e intervalli dell'istogramma senza strumenti esterni.
• Analisi di client e bot — suddivida il contenuto in corrispondenza di " con -F'"' per raggiungere il campo User-Agent; utilizzi una pipe verso grep -iv per escludere i bot prima dell'aggregazione.
• Normalizzazione degli endpoint — utilizzi gsub(/\/[0-9]+/, "/:id") all'interno di awk per accorpare i percorsi parametrizzati prima del conteggio.
• Log ruotati — combini cat e zcat in una subshell per inviare tutti i file delle rotazioni a un'unica passata della pipeline.

Questi schemi possono essere combinati: può concatenare filtraggio, estrazione, normalizzazione e aggregazione in un'unica pipeline che elabora centinaia di milioni di righe su hardware standard. Padroneggiando queste primitive, raramente avrà bisogno di un servizio dedicato di aggregazione dei log per le analisi ad hoc durante un'indagine su un incidente.