File di log Linux da monitorare per individuare problemi

Quando un server Linux inizia a comportarsi male, il primo errore è quasi sempre lo stesso: guardare troppo tardi i log giusti, o guardare quelli sbagliati troppo a lungo. Se l’obiettivo è capire dove si rompe la catena — DNS, rete, kernel, systemd, web server, PHP, database, storage, sicurezza — serve una mappa pratica dei file di log da tenere sotto osservazione, con un ordine sensato e con un minimo di disciplina operativa.

La regola utile non è “leggi tutto”, ma “leggi prima quello che può spiegare il sintomo”. Un 502 non si tratta come un disco pieno, un login fallito non si indaga come un crash del kernel. Sotto trovi i log che uso più spesso su sistemi Linux recenti, con il perché, cosa aspettarsi e come incrociarli senza perdere tempo.

Ordine di lettura: dal sintomo al layer

Se il sito è giù o lento, l’ordine corretto è questo: prima lo stato del servizio, poi i log applicativi, poi kernel e storage, infine i log di rete e sicurezza. In pratica: systemd e web server per capire se il processo è vivo, PHP-FPM o runtime applicativo per i 500, database per i timeout, kernel per OOM o I/O, autenticazione e firewall per i blocchi laterali.

La lettura deve essere sempre correlata con un timestamp. Se un errore compare alle 10:14:22, cerca nello stesso minuto nei log di web server, runtime e database. Senza correlazione temporale si finisce a interpretare eventi scollegati.

Log di sistema: il primo posto da cui partire

Su sistemi con systemd, il punto di partenza non è un file ma il journal. È il contenitore più utile quando non sai ancora quale componente sta cedendo. Ti dice se un servizio è morto, se è stato riavviato, se ha saturato memoria o se il kernel ha tagliato qualcosa di brutto.

Comandi pratici:

journalctl -p err -b
journalctl -u nginx -b
journalctl -u php-fpm -b
journalctl --since "10 min ago"

Usa -b per limitarti al boot corrente e -p err per alzare il rumore utile. Se vedi ripetizioni come Start request repeated too quickly o Main process exited, il problema non è “il sito”: è il servizio che non regge l’avvio o viene ucciso dal sistema.

Se il journal è persistente, vale la pena verificare anche lo spazio occupato e la retention. Non è raro che il journal cresca abbastanza da nascondere il resto del problema, soprattutto su macchine piccole.

Kernel log: OOM, I/O e guasti di basso livello

Il kernel log è quello che ti dice quando il sistema ha deciso di sacrificare un processo, quando il disco ha iniziato a rispondere male o quando un driver ha generato rumore serio. Su Linux moderno lo leggi ancora via journal, ma il contenuto è kernel puro.

journalctl -k -b
dmesg -T | tail -n 100

Cerca parole chiave come Out of memory, Killed process, I/O error, EXT4-fs error, nvme timeout, blocked for more than. Se trovi un OOM killer, il problema non è nel web server: è la pressione memoria o un processo fuori controllo. Se trovi errori I/O, il layer storage va messo sotto lente prima di fare qualsiasi altra ipotesi.

Un dettaglio pratico: se il server è in degrado intermittente, il kernel log spesso è più affidabile dei log applicativi, perché registra la causa a monte anche quando il processo applicativo non riesce più a scrivere nulla.

Web server: Apache, Nginx e proxy reversi

Per un sito web, i log del front-end HTTP sono quasi sempre il secondo livello da controllare. Su Apache e Nginx trovi la differenza tra errore di rete, upstream assente, timeout e risposta applicativa anomala. Sono i file che più spesso chiariscono se il problema è davanti o dietro al proxy.

Percorsi tipici:

/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/apache2/access.log
/var/log/apache2/error.log
/var/log/httpd/access_log
/var/log/httpd/error_log

Se hai un reverse proxy davanti a un’app PHP o a un backend Node/Java, il log di errore del proxy ti dice spesso se l’upstream è morto, lento o irraggiungibile. Cerca righe tipo connect() failed (111: Connection refused), upstream timed out, bad gateway, client intended to send too large body.

Nel log di accesso, gli indicatori utili sono status code, tempo di risposta e dimensione della risposta. Una serie di 499 o 408 spesso indica timeout lato client o latenza eccessiva; una serie di 502 o 504 punta invece all’upstream.

PHP-FPM e runtime applicativi: dove nascono i 500 “silenziosi”

Quando la pagina è bianca o il sito risponde con 500 senza dettagli, il file di log di PHP-FPM o del runtime applicativo è spesso decisivo. Il web server può limitarsi a registrare il fallimento dell’upstream, ma la causa reale sta nel pool PHP, in un fatal error, in un timeout o in un problema di permessi.

Percorsi tipici di PHP-FPM:

/var/log/php-fpm/error.log
/var/log/php8.2-fpm.log
/var/log/php8.3-fpm.log
journalctl -u php8.2-fpm -b

Per applicazioni CMS o framework, cerca errori di bootstrap, classi mancanti, variabili non inizializzate, timeout verso servizi esterni e problemi di permessi su cache e upload. Un pattern classico è il seguente: il web server mostra 502, PHP-FPM mostra server reached pm.max_children o processi bloccati, e l’applicazione registra query lente o chiamate HTTP esterne in timeout.

Se il pool è saturo, non basta alzare i processi senza guardare memoria e CPU. È un intervento che può peggiorare il collo di bottiglia. Prima misura il carico reale, poi decidi se aumentare pm.max_children o ridurre il costo per richiesta.

Database: MySQL, MariaDB e PostgreSQL

Il database è spesso il colpevole quando il sito “si apre ma non fa nulla” oppure quando tutto sembra vivo ma i tempi esplodono. I log del DB servono a distinguere una semplice query lenta da un guasto più serio: crash, lock, replica ferma, storage degradato o autenticazione fallita.

File tipici:

/var/log/mysql/error.log
/var/log/mysqld.log
/var/log/postgresql/postgresql-16-main.log
journalctl -u mariadb -b
journalctl -u postgresql -b

In MySQL/MariaDB cerca segni di crash recovery, InnoDB corruption, deadlock frequenti, access denied, table full, aborted connection. In PostgreSQL cerca could not write to file, FATAL, deadlock detected, connection refused, too many connections. Se il database rifiuta connessioni, l’applicazione a valle può sembrare “rotta” anche se il web server è perfetto.

Per i problemi di performance, il log da solo non basta: va incrociato con slow query log, metriche connessioni attive, buffer pool, I/O disco e latenza storage. Il log ti dice che qualcosa è andato male; il resto ti dice perché.

Autenticazione, sudo e sicurezza: non solo attacchi, anche errori operativi

I log di autenticazione servono sia per la sicurezza sia per capire errori banali che sembrano incidenti. Un cambio di password, una chiave SSH non più accettata, un account bloccato o un PAM mal configurato possono impedire l’accesso quanto un guasto di rete.

File comuni:

/var/log/auth.log
/var/log/secure
journalctl -u ssh -b

Qui trovi login falliti, escalation sudo, chiavi negate, tentativi brute force e blocchi su policy. Se un servizio smette di partire dopo una modifica di permessi, spesso il primo indizio è proprio nei log di autenticazione o nei messaggi del daemon coinvolto.

Dal punto di vista sicurezza, questi log vanno protetti con accesso ristretto e retention coerente. Contengono dati sensibili operativi, e in alcuni casi anche indirizzi IP, username e dettagli di policy. Non serve esporli a più persone del necessario per “comodità”.

Firewall, kernel networking e blocchi di rete

Quando il problema è “non risponde più”, i log di rete sono quelli che separano il guasto applicativo dal blocco per policy. Se usi ufw, firewalld, nftables o un IDS/IPS, il traffico può essere rifiutato prima ancora di arrivare al servizio.

Controlli utili:

journalctl -u ufw -b
journalctl -u firewalld -b
nft list ruleset
ss -tulpn

Se il servizio ascolta ma non è raggiungibile, la coppia ss -tulpn e log firewall è molto più utile del tentativo casuale di riavviare tutto. Un errore frequente è confondere un bind su 127.0.0.1 con un servizio morto: il processo c’è, ma è esposto solo in locale.

In ambienti con CDN o bilanciatori, aggiungi i log del reverse proxy o del layer edge. Un 403 può essere un blocco WAF, non un errore dell’applicazione. Un 525 o un timeout TLS può dipendere dal certificato o dalla catena trust, non dal backend.

Log mail: quando il problema non è il sito ma la posta

Su server che gestiscono anche SMTP, IMAP o notifiche applicative, i log mail sono spesso ignorati fino a quando qualcosa smette di arrivare. Eppure sono fondamentali per capire blocchi di consegna, code ferme, DNS mal configurato, relay rifiutato o autenticazioni fallite.

File tipici:

/var/log/mail.log
/var/log/maillog
journalctl -u postfix -b
journalctl -u dovecot -b

Qui cerca code in crescita, bounce, errori SPF/DKIM/DMARC, problemi di relay e connessioni rifiutate. Se il sito invia notifiche email e queste non partono, il problema non è sempre l’app: può essere il MTA o una policy esterna che respinge il traffico.

Log di storage: il dettaglio che spesso arriva troppo tardi

Dischi pieni, filesystem in sola lettura, errori SMART o latenze elevate si manifestano prima nei log che nei monitor. Se l’applicazione è lenta o si blocca in scrittura, il filesystem o il volume sottostante possono essere la causa reale.

Oltre al kernel log, controlla lo stato del filesystem e dei volumi. Se usi LVM, RAID o storage virtualizzato, i messaggi possono comparire in punti diversi della catena. Un errore di disco che non viene visto subito può trasformarsi in corruzione applicativa dopo ore.

df -h
lsblk
mount | column -t
smartctl -a /dev/sdX

Il log non sostituisce il check dello spazio libero, ma lo completa. Un No space left on device in un file di log applicativo è spesso il punto d’arrivo, non l’inizio del problema.

Come leggere i log senza annegare nel rumore

La tecnica più utile è filtrare per tempo, servizio e sintomo. Non aprire file enormi con scrolling casuale: usa grep, journalctl con intervallo temporale e, quando serve, incrocia più fonti nello stesso minuto.

journalctl --since "2026-04-12 10:00" --until "2026-04-12 10:15"
grep -E "error|fail|fatal|timeout|denied|refused" /var/log/nginx/error.log
grep -R "Killed process" /var/log/journal 2>/dev/null

Un approccio ordinato evita due errori classici: confondere il sintomo con la causa e toccare la configurazione prima di averla osservata. Se il servizio è instabile, il primo obiettivo non è “sistemare tutto”, ma ridurre l’incertezza.

Una mini-checklist operativa da tenere a portata

Quando ricevi una segnalazione, questa sequenza copre la maggior parte dei casi reali:

1. Controlla il sintomo esterno con curl -I o con il monitoraggio, per capire se il problema è HTTP, DNS o timeout.
2. Guarda journalctl -p err -b per errori sistemici immediati.
3. Apri il log del web server o del proxy per cercare 5xx, upstream down e timeout.
4. Se c’è PHP o un runtime applicativo, controlla il suo log per fatal error e saturazione dei worker.
5. Se il problema sembra lato dati, verifica i log del database e lo stato del disco.
6. Se ci sono blocchi di accesso, passa ai log di autenticazione e firewall.

Questo ordine riduce i tempi perché segue la catena di dipendenza reale. Se il database è fermo, il resto è rumore. Se il kernel ha ucciso un processo per OOM, il web server è solo la vittima visibile.

Conclusione pratica: pochi log, ma scelti bene

I file di log da monitorare non sono tanti, ma vanno scelti in funzione del layer. Il journal di sistema, il kernel log, i log del web server, PHP-FPM, database, autenticazione, firewall e storage coprono quasi tutti i casi che incontrerai su Linux in produzione. La differenza non la fa il numero di file aperti, ma la capacità di leggerli in sequenza e di correlare il timestamp con il sintomo.

Se vuoi davvero individuare i problemi in fretta, tieni sempre presente questa regola: prima osserva, poi modifica. Un log letto bene vale più di tre riavvii alla cieca.