Grep su Linux: trovare un errore nei log

Un cat /var/log/syslog su un server attivo dà soprattutto una cosa: troppe righe. Quando un servizio cade o si verifica un errore, cercate prima il nome del servizio, l’ora e il messaggio preciso. grep permette di ridurre il rumore senza perdere le righe che spiegano ciò che è accaduto poco prima.

Questo metodo funziona su un file sotto /var/log come sull’uscita di journalctl. Non sostituisce il diario completo: serve a trovare un punto di partenza affidabile, poi ad allargare intorno a quel punto.

Iniziare con una ricerca leggibile

Aggiungi i numeri di riga e ignora il maiuscolo se il programma mescola Error, ERROR o error:

grep -n -i 'error' /var/log/il-mio-servizio.log

-n mostra il numero di riga. Diventa utile quando devi riprendere il file in less, confrontare due ricerche o copiare il brano in un ticket. Le apostrofe evitano che la shell interpreti caratteri speciali nel modello. Il manuale di grep dettagli le opzioni di ricerca e di contesto.

• -i cerca senza distinguere tra maiuscole e minuscole.
• -n aggiunge il numero di riga.
• -F tratta il testo come una stringa letterale, utile per un errore contenente ., [ o ?.
• -E attiva le espressioni regolari estese.
• -C 3 mostra tre righe prima e dopo ogni corrispondenza.

Per un errore esatto, preferisci -F. Un indirizzo IP, un percorso o un messaggio con parentesi quadre può altrimenti essere interpretato come un’espressione regolare:

grep -n -F 'connection refused [127.0.0.1:5432]' /var/log/il-mio-servizio.log

Mantenere le righe che spiegano l’errore

Una riga contrassegnata con ERROR indica raramente la causa da sola. Mostra il contesto prima di concludere:

grep -n -i -C 3 'error' /var/log/il-mio-servizio.log

grep -n -i -A 5 'failed' /var/log/il-mio-servizio.log

grep -n -i -B 5 'panic' /var/log/il-mio-servizio.log

-C 3 mantiene tre righe da ogni lato. -A mostra solo le righe seguenti, -B solo le precedenti. Se ci sono più errori lontani, grep separa i gruppi con --. Questo separatore non fa parte del diario.

Quando conosci più sintomi, assemblali con -E:

grep -n -i -E 'error|failed|timeout|refused' /var/log/il-mio-servizio.log

Questo comando restituisce anche messaggi che non riguardano necessariamente il tuo incidente. Aggiungi poi il nome del processo, la porta o l’identificativo della richiesta piuttosto che allungare la lista di parole chiave a caso.

Filtrare journalctl prima di passare a grep

Con systemd, inizia limitando il diario all’unità e al periodo dell’incidente. Eviti di mescolare i messaggi di altri servizi:

journalctl -u nginx --since '30 minuti fa' --no-pager
journalctl -u nginx --since '30 minuti fa' --no-pager | grep -n -i -C 2 'error'

Sostituisci nginx con il nome reale dell’unità, ad esempio postgresql, docker o il tuo servizio applicativo. Se l’incidente segue un riavvio, aggiungi -b per rimanere sull’avvio corrente. Il manuale di journalctl descrive anche i filtri per unità e periodo. La nostra guida su journalctl e i log dell’ultimo avvio dettaglia questo filtro.

Non avviare una ricerca su anni di diari prima di aver inquadrato l’ora del problema. Un errore visto alle 14:12 merita una finestra breve attorno alle 14:12, poi una lettura più ampia se nessuna causa appare.

Seguire il servizio durante la riproduzione

Per un problema riproducibile, apri un secondo terminale e guarda solo le nuove righe:

journalctl -fu nginx

tail -F /var/log/nginx/error.log | grep --line-buffered -i -E 'error|warn|failed'

journalctl -f segue il diario in tempo reale. tail -F continua anche dopo una rotazione del file, il che è più sicuro di tail -f su molti log applicativi. L’opzione --line-buffered mantiene il flusso leggibile dopo il pipe verso grep.

Poi attiva una sola volta l’azione che fallisce: una richiesta HTTP, un riavvio controllato o una connessione di test. Se avvii più test contemporaneamente, non saprai più quale riga appartiene a quale tentativo. Per seguire un file classico, puoi anche consultare il nostro metodo con tail.

Quando hai trovato un errore, annota l’ora, l’unità o il processo interessato, poi le righe attorno al messaggio. È più utile di un copia e incolla di mille righe di log e evita di modificare una configurazione prima di aver identificato il servizio colpevole.

n