Cum monitorizezi un fișier de log în timp real cu tail, less și journalctl

Când un site afișează eroarea 502, SSH refuză conexiunea sau un serviciu se oprește, logurile trebuie verificate în timp ce reproduci problema. În Linux, cele mai utile instrumente pentru această sarcină sunt tail, less și journalctl.

Ele nu sunt interschimbabile. tail urmărește rapid un fișier text, less îți permite să navighezi și să cauți în același fișier, iar journalctl interoghează jurnalul structurat al serviciilor administrate prin systemd.

Găsește logul potrivit

Locația depinde de aplicație și distribuție. Exemple frecvente pe Ubuntu și Debian:

/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/apache2/error.log
/var/log/auth.log
/var/log/apt/history.log

Verifică existența și permisiunile fișierului:

sudo ls -lh /var/log/nginx/error.log

Unele loguri pot fi citite numai de root sau de membrii unui grup administrativ. Nu schimba permisiunile doar pentru a le putea deschide; folosește sudo pentru investigație.

Urmărește ultimele linii cu tail

Pentru ultimele zece linii:

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

Pentru ultimele 100:

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

Monitorizarea în timp real se face cu:

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

Terminalul rămâne deschis și afișează liniile adăugate. Reprodu problema într-un browser sau într-un al doilea terminal, apoi oprește monitorizarea cu Ctrl+C.

Pentru loguri supuse rotației, folosește mai bine:

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

Diferența contează. tail -f urmărește în mod obișnuit descriptorul fișierului deja deschis. tail -F urmărește numele și încearcă să redeschidă fișierul dacă acesta este redenumit, șters și recreat de logrotate. GNU documentează -F ca echivalent pentru --follow=name --retry.

Poți urmări două loguri simultan:

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

tail va afișa și numele fișierului din care provine fiecare grup de mesaje.

Folosește less când ai nevoie și de context

tail este potrivit pentru fluxul live, dar nu poți naviga comod în istoricul mare. Deschide logul cu:

sudo less /var/log/nginx/error.log

Comenzi utile în interiorul less:

G             mergi la final
g             mergi la început
/error        caută înainte cuvântul error
?timeout      caută înapoi cuvântul timeout
n             următorul rezultat
N             rezultatul anterior
q             ieșire

Pentru a ajunge direct la final și a urmări liniile noi:

sudo less +F /var/log/nginx/error.log

În modul live, apasă Ctrl+C pentru a opri temporar urmărirea. Poți apoi naviga, căuta un mesaj și apăsa F pentru a reveni la monitorizarea în timp real. Manualul less precizează că această comandă continuă să citească după atingerea finalului fișierului, într-un mod asemănător cu tail -f.

Aceasta este metoda potrivită când vrei să observi o eroare nouă, dar și să verifici mesajele apărute cu câteva minute înainte.

Monitorizează serviciile systemd cu journalctl

Nu toate aplicațiile scriu într-un fișier separat. systemd-journald colectează mesaje de kernel, evenimente syslog și ieșirile standard ale serviciilor systemd într-un jurnal indexat.

Pentru ultimele 100 de evenimente Nginx:

sudo journalctl -u nginx -n 100

Pentru monitorizare live:

sudo journalctl -u nginx -f

Pentru SSH pe Ubuntu:

sudo journalctl -u ssh -f

Filtrează numai bootul curent:

sudo journalctl -u nginx -b

Sau doar un interval recent:

sudo journalctl -u nginx \
  --since "10 minutes ago"

Pentru mesaje de eroare din sistem:

sudo journalctl -p err -b

journalctl permite filtrarea după unitate, boot, perioadă și prioritate, fără să fie necesar să cauți manual prin toate fișierele din /var/log.

Scenariu practic: Nginx returnează 502

Deschide primul terminal:

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

În al doilea verifică serviciile:

systemctl status nginx
systemctl status php8.3-fpm

Urmărește PHP-FPM:

sudo journalctl -u php8.3-fpm -f

Apoi reprodu eroarea:

curl -I http://localhost

Corelează ora cererii cu mesajele din Nginx și PHP-FPM. Astfel poți identifica un socket inexistent, un serviciu oprit, permisiuni greșite sau un timeout.

Nu șterge logurile în timpul investigației și nu presupune că fiecare mesaj warning este cauza. Notează ora, serviciul, acțiunea care a declanșat problema și primul mesaj relevant. Logurile sunt utile când le corelezi cu un eveniment concret, nu când le citești fără context.

Surse folosite

GNU Coreutils — comportamentul tail, opțiunile -f, -F și urmărirea fișierelor după rotație.

Less Manual — navigare, căutare și modul de monitorizare F.

systemd Documentation — journalctl și colectarea evenimentelor prin systemd-journald.