Tail in Linux: monitorare un log in tempo reale senza dover rieseguire il comando ogni dieci secondi

Quando un servizio Linux smette di rispondere o un’applicazione inizia a generare errori, eseguire lo stesso comando ogni dieci secondi diventa rapidamente noioso. Questa è esattamente il tipo di situazione in cui coda Offre un servizio: visualizza le ultime righe di un file, permettendoti poi di seguire in tempo reale cosa succede.

Lo uso principalmente per controllare i log durante il riavvio di un servizio, una connessione SSH, un errore di Nginx o la scrittura di uno script su un file. Non è uno strumento diagnostico miracoloso, ma spesso è il modo più rapido per verificare se sta effettivamente accadendo qualcosa.

Qual è lo scopo di tail in Linux?

L’ordine coda Visualizza la fine di un file. Senza alcuna opzione, mostra le ultime dieci righe:

coda /var/log/syslog

Su Debian o Ubuntu, a seconda della configurazione, potresti anche incontrare file come /var/log/auth.log, /var/log/nginx/error.log o registri delle applicazioni inseriti in /var/log/service-name/.

Prima di procedere oltre, la prima cosa da fare è verificare che il file esista e che si disponga dei diritti di lettura.

ls -lh /var/log/syslog
sudo tail /var/log/syslog

Se il comando non restituisce nulla, non è necessariamente un errore. Il file potrebbe essere vuoto, mancante nella tua distribuzione o sostituito dal log di systemd.

Visualizza più o meno righe con tail -n

Di default, dieci righe raramente sono sufficienti quando si cerca di capire un errore. Con -NÈ possibile scegliere il numero di righe da visualizzare:

tail -n 50 /var/log/syslog
sudo tail -n 100 /var/log/nginx/error.log

Ti consiglio di iniziare con 50 o 100 righe. Se richiedi 5000 righe, perdi il vantaggio di `tail` e a volte sarebbe meglio aprire il file con meno oppure per filtrare direttamente.

Per un file molto dettagliato, puoi anche combinare tail con grep :

sudo tail -n 200 /var/log/syslog | grep -i "error"

Attenzione però: filtrare troppo presto può farvi perdere il messaggio immediatamente precedente all’errore. Quando non so ancora cosa sto cercando, leggo prima le righe grezze.

Segui un registro in tempo reale con tail -f

L’opzione più utile è -FMantiene aperto il prompt dei comandi e visualizza le nuove righe non appena vengono scritte nel file:

sudo tail -f /var/log/syslog

A questo punto è possibile aprire un secondo terminale, riavviare il servizio, ristabilire la connessione problematica o riprodurre l’errore nell’applicazione. Le nuove righe vengono aggiunte man mano che vengono elaborate.

sudo systemctl restart nginx
sudo tail -f /var/log/nginx/error.log

Per uscire dal tracciamento, è sufficiente utilizzare Ctrl+CNon chiudere bruscamente la sessione SSH se sei connesso a un server remoto, soprattutto se stai intervenendo per risolvere un problema di un servizio importante.

C’è anche coda -Fcon la F maiuscola. Questa opzione segue il nome del file ed è più resistente alla rotazione del log. Ciò è utile quando il file può essere ricreato da logrotate durante la tua diagnosi

sudo tail -F /var/log/nginx/error.log

Filtra i contenuti mentre guardi, senza perdere il flusso in diretta.

È possibile tracciare un file e filtrarlo contemporaneamente. Per cercare un errore specifico:

sudo tail -f /var/log/syslog | grep --line-buffered -i "failed"

L’opzione --line-buffered impedisce grep Mantiene le righe in sospeso troppo a lungo. Senza di esso, potresti pensare che non stia succedendo nulla, mentre in realtà il filtro sta bloccando la visualizzazione.

Per semplici diagnosi, spesso preferisco aprire due terminali: uno con il log completo e un altro con il filtro. Questo mi impedisce di perdere un avviso che non contiene la parola esatta che sto cercando.

Quando è preferibile utilizzare journalctl anziché tail?

Nelle distribuzioni recenti con systemd, molte informazioni passano attraverso journalctlSe stai cercando i log di un servizio systemd, journalctl è spesso più pulito di tail su un file in /var/log.

sudo journalctl -u ssh -n 50
sudo journalctl -u ssh -f

Con -u, stai prendendo di mira un’unità systemd. Con -n 50Stai visualizzando le ultime 50 righe. Con -FPuoi seguire le notizie in diretta, proprio come con Tails.

Se si sta riavviando un servizio, è quindi possibile combinare i due approcci:

sudo systemctl restart ssh
sudo systemctl status ssh --no-pager
sudo journalctl -u ssh -f

Di solito uso tail quando so esattamente quale file dell’applicazione monitorare. Per un servizio systemd, un processo di avvio o un errore di avvio, di solito uso journalctl. Se vuoi approfondire l’argomento, consulta l’articolo su journalctl e i log dell’ultimo avvio L’ordine è stato completato alla perfezione.

Errori comuni con la coda

Il primo errore è seguire il file sbagliato. Prima di rimanere bloccati a fissare un registro senza messaggi di log, controllate il servizio e i file aperti:

systemctl status nginx --no-pager
sudo journalctl -u nginx -n 50
sudo ls -lh /var/log/nginx/

Secondo errore: dimenticare i permessi. Su un server, molti log richiedono sudoSe hai un messaggio Autorizzazione negataNon modificare i permessi dei file in modo casuale. Piuttosto, riavvia l’operazione di lettura utilizzando sudo.

Terzo errore: confondere l’assenza di log con l’assenza di un problema. Un’applicazione può scrivere altrove, inviare i suoi log a systemd o registrare solo determinati livelli di errore.

Per verificare lo stato del server in modo più completo, è possibile esaminare anche i servizi non funzionanti utilizzando systemd:

systemctl --non riuscito
systemctl list-jobs

Se il problema riguarda una porta di rete o un servizio che non è più in ascolto, l’articolo su netstat, ss e porte aperte in Linux può anche aiutarti a verificare cosa viene effettivamente visualizzato.

Un metodo semplice per la diagnosi, senza divagazioni.

Quando devo controllare un servizio che si è appena interrotto, utilizzo un metodo rapido:

• identificare il servizio o il file di registro in questione;
• visualizza le ultime righe con coda -n 50 O journalctl -n 50 ;
• inizia a monitorare con coda -f, coda -F O journal ctl -f ;
• riprodurre l’azione problematica;
• Annota l’ora esatta e il messaggio prima di modificare la configurazione.

Quest’ultimo punto impedisce di intervenire alla cieca. Leggere un registro al momento giusto è meglio di tre riavvii senza capire cosa sia successo.

Per la documentazione di riferimento, è possibile consultare la pagina GNU Coreutils su coda e la pagina systemd su journalctl.

sudo apt update && sudo apt upgrade