Cosa sono i file Log e come si utilizzano
Quando un sito rallenta, una pagina restituisce un errore o un’applicazione smette di rispondere, la prima domanda che viene posta all’assistenza è sempre la stessa: cosa è successo esattamente? La risposta raramente si trova nella schermata di errore mostrata al visitatore, che segnala il sintomo senza spiegarne l’origine. Si trova invece in un file di testo che il server aggiorna in continuazione, riga dopo riga, registrando ogni evento nell’istante in cui accade.
Quel file è il log. È il diario di bordo di qualsiasi sistema informatico e rappresenta la fonte più attendibile per ricostruire la sequenza di eventi che ha portato a un malfunzionamento. Chi impara a consultarlo riduce sensibilmente i tempi di diagnosi e smette di procedere per tentativi.
Che cos’è un file di log
Un file di log è un documento generato automaticamente da un sistema operativo, da un server o da un’applicazione, nel quale vengono annotati gli eventi rilevanti che si verificano durante il funzionamento. Ogni riga corrisponde a un singolo evento e riporta almeno il momento in cui si è verificato, insieme alle informazioni che il programma considera utili per descriverlo.
L’estensione più diffusa è .log, anche se molti sistemi usano .txt oppure nessuna estensione. Al di là del nome, il contenuto resta testo semplice, leggibile con qualsiasi editor. La differenza sostanziale rispetto a un normale file di testo riguarda l’origine: un .txt viene creato e compilato da una persona, mentre un log viene scritto dal software in modo automatico e progressivo, senza alcun intervento manuale.
Le informazioni che compaiono in una riga di log variano secondo il servizio che la produce, ma alcuni elementi ricorrono con regolarità:
- il timestamp, ovvero data e ora esatte dell’evento;
- l’identità di chi ha generato la richiesta, tipicamente un indirizzo IP o un nome utente;
- la descrizione dell’evento, che può essere un accesso, una query, un avvio di servizio o un’eccezione;
- l’esito dell’operazione, spesso codificato in un numero o in un livello di gravità;
- il componente coinvolto, come un processo di sistema, un modulo dell’applicazione o il kernel.
Questa struttura ripetitiva è ciò che rende i log analizzabili in modo automatico. Migliaia di righe formattate allo stesso modo possono essere filtrate, contate e aggregate da uno script o da una piattaforma di monitoraggio.
I principali tipi di file di log
Ogni componente dell’infrastruttura produce i propri registri e conviene sapere dove cercare a seconda del problema riscontrato.
Log di sistema e log applicativi. I primi documentano l’attività del sistema operativo: avvio e arresto dei servizi, riconoscimento dell’hardware, messaggi del kernel, aggiornamenti installati. Su Linux si trovano generalmente in /var/log/ con nomi come syslog o messages. I secondi vengono scritti dalle singole applicazioni e ne raccontano il comportamento interno, comprese eccezioni e avvisi. Un esempio tipico:
2026-08-19 08:15:12 - User logged in: user1 2026-08-19 08:17:33 - Error: Invalid file format (user1)
Access log ed error log. Sono i due registri che interessano più da vicino chi gestisce un sito. L’access log annota ogni singola richiesta ricevuta dal web server, mentre l’error log raccoglie le richieste che hanno prodotto un malfunzionamento, insieme al messaggio restituito dal linguaggio di scripting. Il primo descrive il traffico, il secondo spiega i guasti; consultarli insieme permette di capire quali visitatori hanno incontrato il problema e in quale momento.
Log di sicurezza, audit e transazioni. Registrano tentativi di accesso riusciti e falliti, modifiche ai permessi, operazioni compiute dagli amministratori e transazioni eseguite su un database. Sono la base di ogni indagine successiva a un incidente e, in molti settori regolamentati, la loro conservazione risponde a un obbligo normativo prima ancora che a un’esigenza tecnica.
I log su un servizio di hosting
Su un servizio di cloud hosting i registri vengono generati dal web server e resi disponibili all’interno dello spazio assegnato all’account. La posizione dipende dalla configurazione, ma di norma i file si trovano in una directory dedicata all’interno della home, separati per dominio, così che ogni sito ospitato abbia il proprio access log e il proprio error log.
Il modo più immediato per recuperarli passa dal pannello di controllo. Nella guida a cPanel di VHosting sono descritte le sezioni che permettono di scaricare i registri grezzi, consultare l’elenco degli ultimi errori e visualizzare i grafici relativi a richieste HTTP e consumo di risorse. Chi dispone di accesso SSH può leggere gli stessi file direttamente da terminale, con il vantaggio di poterli filtrare senza scaricarli.
Vale la pena imparare a leggere una riga di access log nel formato combined, quello adottato dalla maggior parte delle configurazioni Apache e LiteSpeed:
93.45.112.8 - - [19/Aug/2026:10:42:17 +0200] "GET /prodotti/scarpe HTTP/1.1" 200 5120 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
I campi si susseguono in ordine fisso: l’indirizzo IP del visitatore, la data e l’ora della richiesta, il metodo HTTP con la risorsa richiesta e il protocollo, il codice di stato restituito dal server, il numero di byte trasferiti, la pagina di provenienza e infine lo user agent, ovvero l’identificativo del browser o del bot. Con questi otto elementi si ricostruisce chi ha chiesto cosa, quando e con quale esito.
Come aprire e leggere un file di log
Trattandosi di testo semplice, un log si apre con qualunque strumento capace di visualizzare caratteri. La scelta dipende dalla dimensione del file e dall’obiettivo dell’analisi.
Gli editor di testo integrati nei sistemi operativi, come Blocco note su Windows, TextEdit su macOS o Gedit su molte distribuzioni Linux, sono adatti a file di poche migliaia di righe. Oltre quella soglia diventano lenti e poco maneggevoli. Gli editor di codice come Visual Studio Code, Notepad++ o Sublime Text gestiscono file più corposi, evidenziano la sintassi e offrono una ricerca con espressioni regolari, che velocizza parecchio l’individuazione di uno schema ricorrente.
Il lavoro più efficiente si svolge però da riga di comando. Su Linux e macOS quattro comandi coprono la quasi totalità delle esigenze:
- cat, che stampa a schermo l’intero contenuto del file;
- less, che consente di scorrerlo pagina per pagina senza caricarlo tutto in memoria;
- tail -f, che mostra le ultime righe e resta in ascolto, aggiornandosi in tempo reale a ogni nuovo evento;
- grep, che estrae solo le righe contenenti un determinato termine.
L’ultimo è quello che cambia davvero il modo di lavorare. Un comando come grep ” 500 ” access.log isola in un istante tutte le richieste terminate con un errore interno del server, indipendentemente dal fatto che il file ne contenga centomila righe. Su Windows la stessa logica si applica tramite PowerShell con il cmdlet Get-Content, mentre gli eventi di sistema restano consultabili attraverso il Visualizzatore eventi, raggiungibile cercandolo dal menu Start.
Come cercare informazioni all’interno dei log
Quando un file di log contiene migliaia o milioni di righe, leggerlo dall’inizio alla fine non è praticabile. Si parte invece da un dato conosciuto: un indirizzo IP, un URL, un codice HTTP, un messaggio di errore oppure l’orario nel quale si è verificato il problema.
Su Linux uno degli strumenti più utilizzati è grep, che cerca una stringa all’interno di un file e restituisce soltanto le righe che la contengono. Per cercare, ad esempio, tutte le richieste provenienti da un determinato indirizzo IP si può utilizzare:
grep "93.45.112.8" access.log
Lo stesso principio si applica alla ricerca di una pagina specifica:
grep "/wp-login.php" access.log
Oppure a un messaggio presente nell’error log:
grep "PHP Fatal error" error.log
Cercare codici di stato HTTP
Negli access log è spesso necessario isolare le richieste che hanno restituito un determinato codice di stato HTTP. Se il formato del log prevede il codice subito dopo la richiesta HTTP, una ricerca semplice può essere eseguita in questo modo:
grep ' 500 ' access.log
In questo modo si cercano le righe contenenti 500 delimitato da spazi, evitando almeno le corrispondenze più banali con numeri più lunghi. Per cercare contemporaneamente diversi errori della famiglia 5xx si può utilizzare grep con un’espressione regolare:
grep -E ' 50[0-9] ' access.log
Il comando individua i codici compresi tra 500 e 509. Per un’analisi rigorosa del codice HTTP è comunque preferibile elaborare il campo specifico del formato di log, perché una semplice ricerca testuale può trovare la stessa sequenza di caratteri anche in altri campi.
Seguire un log in tempo reale
Quando si sta riproducendo un errore, può essere più utile osservare il registro mentre viene scritto. Il comando tail con l’opzione -f mantiene aperto il file e mostra le nuove righe appena vengono aggiunte:
tail -f error.log
Si può quindi aprire la pagina che genera il problema e osservare immediatamente cosa viene scritto nell’error log. È possibile anche combinare tail e grep per visualizzare soltanto determinati eventi:
tail -f access.log | grep "/wp-login.php"
In questo caso vengono mostrate in tempo reale soltanto le nuove richieste che contengono /wp-login.php.
Contare le occorrenze
La ricerca diventa ancora più utile quando non interessa soltanto sapere se un evento esiste, ma anche quante volte si è verificato. L’opzione -c di grep restituisce il numero delle righe corrispondenti:
grep -c "/wp-login.php" access.log
Per contare, ad esempio, quante righe contengono un codice 404:
grep -c ' 404 ' access.log
Individuare gli IP più presenti
Su un access log nel quale l’indirizzo IP rappresenta il primo campo della riga, si possono combinare awk, sort, uniq e head per ottenere una classifica degli indirizzi che compaiono più spesso:
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head
awk estrae il primo campo, sort ordina gli indirizzi, uniq -c conta le occorrenze e sort -nr ordina il risultato partendo dal valore numerico più alto. head limita infine l’output alle prime righe.
Il risultato può assumere una forma simile:
1842 93.45.112.8 973 185.220.101.3 521 66.249.66.1
Un numero elevato di richieste provenienti dallo stesso IP non indica automaticamente un attacco. Può trattarsi di un crawler, di un proxy, di un sistema di monitoraggio o di traffico legittimo. Il dato serve quindi a individuare cosa approfondire, non a stabilire da solo la natura dell’attività.
Cercare nei log ruotati e compressi
Un evento meno recente potrebbe non essere più presente nel file corrente. Quando è attiva la rotazione dei log si possono trovare file come access.log.1, access.log.2.gz oppure archivi con una data nel nome.
Se il file non è compresso si utilizza normalmente grep:
grep "93.45.112.8" access.log.1
Per i file compressi con gzip non è necessario estrarre preventivamente l’archivio. Si può utilizzare zgrep:
zgrep "93.45.112.8" access.log.2.gz
Quando occorre cercare lo stesso dato nel log corrente e in quelli ruotati si possono interrogare più file contemporaneamente, compatibilmente con i nomi utilizzati dal sistema:
grep "93.45.112.8" access.log access.log.1 zgrep "93.45.112.8" access.log.*.gz
Restringere progressivamente la ricerca
Il metodo più efficace consiste nel partire dall’informazione certa e restringere progressivamente il risultato. Se viene segnalato un errore avvenuto alle 15:42, per esempio, si cerca prima quella fascia oraria. Se dalle righe ottenute emerge un determinato IP o URL, la ricerca successiva viene effettuata su quel valore. Access log ed error log possono poi essere confrontati utilizzando i timestamp.
È questo il vero vantaggio dei registri: non serve leggere tutto. Si isolano pochi eventi significativi all’interno di una quantità molto più grande di dati e si ricostruisce, passo dopo passo, cosa è successo sul server.
Cosa cercare in un log
Aprire un registro senza sapere cosa cercare porta soltanto a scorrere righe. L’analisi diventa produttiva quando si parte da un’ipotesi e si usano i log per confermarla o smentirla.
I codici di stato HTTP sono il primo indicatore. Le risposte 404 segnalano risorse mancanti e, se si concentrano su una pagina che dovrebbe esistere, indicano un collegamento rotto o una regola di riscrittura configurata male. Le risposte 403 riguardano permessi negati. I codici della famiglia 5xx spostano l’attenzione sul server: un 500 rimanda quasi sempre a un errore nel codice o a permessi errati sui file, un 502 e un 504 a un processo che non ha risposto entro il tempo previsto.
I tentativi di accesso ripetuti meritano attenzione costante. Decine di richieste POST verso la pagina di login provenienti dallo stesso indirizzo IP nell’arco di pochi minuti descrivono un attacco a forza bruta in corso. Allo stesso modo, URL contenenti stringhe SQL anomale o percorsi che tentano di risalire l’albero delle directory rivelano una scansione automatizzata alla ricerca di vulnerabilità.
Il traffico non umano occupa una quota rilevante delle richieste ricevute da qualsiasi sito. Lo user agent permette di distinguere i crawler dei motori di ricerca dagli scraper che copiano contenuti o consumano risorse senza restituire alcun valore. Un picco improvviso di richieste concentrate su poche ore, tutte con lo stesso user agent, spiega spesso rallentamenti che a prima vista sembrano inspiegabili.
Le richieste lente emergono confrontando i timestamp e, dove disponibile, il tempo di risposta registrato. Individuare le pagine che impiegano sistematicamente più tempo indica dove intervenire con la cache o con l’ottimizzazione delle query.
Rotazione, spazio su disco e conservazione
Un log cresce senza sosta e su un sito con traffico significativo può arrivare a occupare centinaia di megabyte nel giro di poche settimane. Lasciato senza controllo, arriva a saturare lo spazio disponibile e a rendersi ingestibile.
La soluzione adottata dai sistemi Linux si chiama rotazione. L’utility logrotate chiude periodicamente il file corrente, lo rinomina aggiungendo un progressivo o una data, lo comprime e ne apre uno nuovo, eliminando le copie più vecchie oltre una soglia stabilita. La configurazione tipica prevede una rotazione giornaliera o settimanale con la conservazione di un numero limitato di archivi.
Per definire quanto a lungo conservare i registri occorre bilanciare due esigenze. Un’analisi tecnica raramente ha bisogno di dati più vecchi di qualche settimana, mentre un’indagine su un incidente di sicurezza può richiedere il recupero di eventi risalenti a mesi prima. Chi ha necessità di archivi estesi può spostare i log compressi su uno storage esterno, liberando lo spazio dell’hosting senza rinunciare allo storico.
Un aspetto spesso trascurato riguarda la natura dei dati contenuti. Gli access log registrano indirizzi IP, che nel quadro del GDPR costituiscono dati personali. Ne consegue che la loro conservazione va limitata al tempo necessario e documentata nel registro dei trattamenti, con accesso riservato al personale autorizzato.
Strumenti e buone pratiche per il monitoraggio
Su un singolo sito i comandi da terminale bastano. Quando i server diventano diversi, o i servizi da sorvegliare si moltiplicano, la lettura manuale non regge più il passo e serve una raccolta centralizzata.
Le piattaforme più diffuse seguono tutte lo stesso principio: raccogliere i registri provenienti da fonti eterogenee, normalizzarli in un formato comune, indicizzarli per renderli interrogabili e presentarli attraverso dashboard e avvisi. Lo stack ELK, composto da Elasticsearch, Logstash e Kibana, rappresenta la soluzione open source di riferimento; Graylog offre un’alternativa più immediata da configurare, mentre Splunk e Datadog propongono servizi gestiti con funzionalità di analisi avanzate.
Alcune abitudini rendono il lavoro sui log più efficace, indipendentemente dagli strumenti impiegati:
- configurare avvisi automatici sugli eventi critici, così da essere informati prima che siano gli utenti a segnalare il disservizio;
- verificare che l’orario dei server sia sincronizzato via NTP, perché timestamp discordanti rendono impossibile correlare eventi tra macchine diverse;
- adottare un livello di dettaglio proporzionato al contesto, riservando il log di debug agli ambienti di sviluppo;
- controllare che nessun dato sensibile, come password o token di sessione, finisca scritto in chiaro nei registri;
- dedicare qualche minuto a una lettura periodica anche in assenza di problemi, per riconoscere quale sia il comportamento normale del sistema.
Quest’ultimo punto è probabilmente il più sottovalutato. Chi conosce l’aspetto abituale dei propri log individua un’anomalia in pochi secondi, mentre chi li apre soltanto durante un’emergenza si trova davanti a migliaia di righe indistinguibili proprio nel momento in cui il tempo scarseggia.
