Come controllare i log del server su Linux e capire cosa si è rotto davvero

Il tuo sito web presenta un'anomalia di funzionamento, i messaggi del browser risultano troppo generici e il server appare come una risorsa inaccessibile da cui è impossibile estrarre informazioni chiare.

In breve: Sui sistemi operativi Linux, la maggior parte dei file di log di sistema è archiviata nella directory /var/log, mentre molti servizi moderni registrano le proprie attività tramite journalctl, l'utility di interrogazione del journal di sistema di systemd. Per effettuare un'analisi diagnostica efficace, occorre isolare il sintomo, consultare il log di riferimento, analizzare prioritariamente le voci più recenti e individuare stringhe di errore specifiche quali 502 Bad Gateway, permission denied, connection refused o No space left on device.

L'obiettivo di una ricerca diagnostica sui log non è la lettura integrale dei file, ma l'individuazione della singola voce che specifica la causa radice del malfunzionamento.

Dove si trovano i log del server su Linux?

I log di sistema fungono da registro di tracciamento dell'infrastruttura. Ogni servizio essenziale annota le operazioni eseguite, l'esito dei processi e gli eventuali errori riscontrati.

Sulla maggior parte delle distribuzioni Linux, i file di log principali sono posizionati nella directory /var/log:

• /var/log/syslog — Registra gli eventi generali di sistema su distribuzioni Ubuntu e Debian-based.
• /var/log/auth.log — Monitora gli accessi, le sessioni SSH e i tentativi di autenticazione.
• /var/log/nginx/error.log — Raccoglie le eccezioni e gli errori del web server Nginx.
• /var/log/apache2/error.log — Raccoglie le eccezioni e gli errori del web server Apache.
• /var/log/mysql/error.log — Registra i malfunzionamenti del database engine (MySQL/MariaDB).

Diversi servizi moderni non scrivono direttamente su file di log dedicati, ma delegano il tracciamento al log di sistema centralizzato, consultabile tramite il comando journalctl.

Non esiste un unico log globale: l'infrastruttura frammenta il tracciamento in diversi file specialized a seconda del componente di appartenenza.

Quale log occorre analizzare per primo?

La diagnosi deve partire dall'analisi dell'anomalia riscontrata dal client, ripercorrendo il flusso logico della richiesta di rete.

Se un sito non risulta raggiungibile, occorre innanzitutto stabilire se il blocco sia a livello di rete, di web server o di applicazione di backend. Questo approccio layered è approfondito nella nostra guida su perché il mio sito non si carica. Le problematiche legate a filtri DNS o firewall non compaiono nei log applicativi, in quanto le richieste non raggiungono mai l'applicazione di backend.

Di fronte a un errore 502 Bad Gateway, è necessario verificare in prima battuta i log del web server (Nginx o Apache). L'errore 502 indica infatti che il reverse proxy ha ricevuto la richiesta ma il servizio applicativo sottostante non ha fornito una risposta valida.

In caso di problemi di autenticazione, il riferimento principale è il file /var/log/auth.log. Se si verificano fallimenti nel caricamento dei file, occorre verificare sia i log dell'applicazione sia la capienza del disco. Qualora il server risponda con lentezza, l'analisi dei log può evidenziare retry continui, timeout di connessione al database o saturazione di memoria; questi dati devono essere incrociati con i parametri di sistema illustrati in perché il mio server è lento.

La regola fondamentale consiste nel verificare prima il log più vicino all'interfaccia esposta, per poi procedere verso i componenti interni.

Come analizzare un file di log in modo efficace

I file di tracciamento possono raggiungere dimensioni notevoli. Per una lettura efficiente è consigliabile adottare una metodologia di indagine mirata:

1. Verificare i riferimenti temporali (Timestamp): Isolare l'orario esatto in cui si è manifestata l'anomalia. Le righe registrate immediatamente prima e dopo quell'orario forniscono il contesto diagnostico rilevante.
2. Consultare il file a partire dagli eventi più recenti: Evitare di iniziare la lettura dalla testa del file; gli indizi sulla causa corrente sono archiviati in coda (utilizzando ad esempio il comando tail -f o journalctl -e).
3. Isolare le parole chiave critiche: Ricercare termini ad alto valore diagnostico come error, failed, denied, timeout, refused, killed o No space left on device.
4. Isolare la stringa d'errore esatta: Copiare il messaggio di errore esatto generato dal sistema. Un errore di tipo permission denied richiede un intervento sui permessi POSIX, mentre un connection refused indica che il processo di destinazione non è in ascolto sulla porta prevista.
5. Individuare la causa primaria (Primo Domino): Identificare la prima eccezione generata in ordine cronologico. L'interruzione iniziale della connessione a un database può generare a cascata decine di eccezioni secondarie nel web server.

Significato dei messaggi di errore più comuni

Alcuni messaggi di log indicano blocchi critici sul sistema:

• **permission denied** — Il processo applicativo ha tentato di accedere o scrivere su una risorsa (file o directory) priva dei necessari permessi di lettura/scrittura a livello di sistema operativo.
• **connection refused** — Un servizio ha tentato di stabilire una connessione verso un altro componente, ma la porta di destinazione non è risultata attiva o in ascolto.
• **timeout** — Il client o il proxy ha interrotto la connessione poiché il servizio di backend non ha inviato una risposta entro l'intervallo di tempo prestabilito. È spesso sintomo di query SQL non ottimizzate, sovraccarico di CPU o blocchi su chiamate API esterne.
• **No space left on device** — Il file system ha esaurito lo spazio di archiviazione disponibile. Questo stato impedisce la scrittura di sessioni, file temporanei, transazioni sul database e la registrazione degli stessi log.
• **killed (Out Of Memory Killer)** — Il kernel Linux ha terminato forzatamente un processo a causa dell'esaurimento della memoria RAM fisica e dello spazio di Swap.

Se l'architettura utilizza containerization, i servizi registrano i log all'interno dell'ambiente isolato di Docker. In tal caso occorre utilizzare il comando docker logs [container_id] anziché verificare unicamente i log dell'host. Per chiarire l'organizzazione dei log in ambienti containerizzati, consulta la nostra guida Docker su un server per principianti.

FAQ

Qual è il comando principale per verificare i log su un server Linux? Per i servizi gestiti da systemd si utilizza l'utility journalctl (es. journalctl -u nginx -f). Per i servizi tradizionali si analizzano i file posizionati nella directory /var/log mediante comandi quali tail, less o grep.

Quale file di log traccia gli accessi SSH? Sui sistemi Ubuntu e Debian, i tentativi di autenticazione SSH, le connessioni riuscite e i fallimenti di login vengono registrati nel file /var/log/auth.log.

Dove vengono salvati i log di errore di Nginx? I log relativi agli errori di Nginx sono solitamente posizionati nel file /var/log/nginx/error.log, salvo diversa indicazione all'interno dei blocchi di configurazione server.

È sicuro eliminare i file di log per liberare spazio su disco? L'eliminazione diretta di file di log aperti da processi attivi potrebbe non liberare lo spazio effettivo su disco finché il processo stesso non viene riavviato. È preferibile utilizzare l'utility di sistema logrotate o svuotare il contenuto del file mantenendone il descrittore (es. mediante truncate -s 0 /var/log/nomefile.log).

La soluzione intermedia

Server Manager semplifica l'analisi dell'infrastruttura offrendo una vista centralizzata sullo stato dei servizi, l'associazione delle risorse e i log dei singoli progetti.

Questo approccio elimina la frammentazione nella diagnosi delle anomalie: consente di identificare immediatamente se un errore 502 Bad Gateway sia causato da un processo fermo, se vi sia una saturazione dello spazio di archiviazione o se sussistano conflitti di configurazione tra più applicazioni ospitate sulla stessa macchina.

La centralizzazione delle informazioni riduce i tempi di risoluzione dei guasti, consentendo di individuare l'origine esatta degli errori senza dover ricercare manualmente le tracce tra i singoli file del file system.

La risoluzione di un'anomalia si considera conclusa quando l'origine dell'errore viene individuata ed eliminata, la scrittura dei log torna a parametri di regime standard senza segnalazioni di eccezioni e il servizio riprende a erogare prestazioni stabili e prevedibili.