Ghid rapid pentru utilizarea journalctl în analiza logurilor

Ghid rapid pentru utilizarea journalctl în analiza logurilor, scris pentru administratorul care primește un mesaj că site-ul nu răspunde și are cinci minute să afle de ce. Pe orice distribuție Linux cu systemd, Ubuntu, Debian, AlmaLinux, Rocky, jurnalul central al sistemului se citește cu journalctl, iar utilizarea journalctl în analiza logurilor înlocuiește deschiderea pe rând a fișierelor din /var/log.

Comenzile de mai jos acoperă ce folosiți în 95% din cazuri. Restul opțiunilor se găsesc în manual, man journalctl.

Ghid rapid pentru utilizarea journalctl în analiza logurilor

systemd-journald colectează mesajele de la kernel, de la servicii și de la aplicațiile care scriu prin syslog, le păstrează într-un format binar indexat și le oferă prin journalctl. Avantajul față de fișierele text: filtrarea este rapidă, pe câmpuri, iar mesajele au timp, serviciu și prioritate atașate.

Dezavantajul: pe unele distribuții jurnalul este doar în memorie și dispare la repornire, exact când aveți nevoie de el. Primul lucru de făcut pe un server nou este să îl faceți persistent.

Jurnal persistent

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Verificați cu journalctl --list-boots: dacă apar mai multe porniri, jurnalul se păstrează pe disc. Setarea explicită se face în /etc/systemd/journald.conf, cu Storage=persistent.

Comenzile de bază

journalctl                 tot jurnalul, de la început, paginat
journalctl -e              sare la sfârșit, la cele mai recente mesaje
journalctl -n 100          ultimele 100 de linii
journalctl -f              urmărire în timp real, ca tail -f
journalctl -r              în ordine inversă, cele mai noi primele

Paginarea folosește less; căutați cu /, ieșiți cu q. Pentru a trimite ieșirea către alte comenzi, adăugați --no-pager.

Filtrarea, unde stă toată valoarea

După serviciu

journalctl -u nginx
journalctl -u lsws -u mariadb        două servicii, intercalate cronologic
journalctl -u ssh -f                 un serviciu, în timp real

Numele unității este cel din systemctl list-units. Un serviciu care nu apare deloc în jurnal fie nu a pornit niciodată, fie scrie în propriile fișiere, cum fac LiteSpeed și Apache pentru jurnalele de acces.

După pornire

journalctl -b                pornirea curentă
journalctl -b -1             pornirea anterioară
journalctl --list-boots      toate pornirile, cu număr și interval

-b -1 este comanda pentru „serverul a repornit singur azi-noapte, de ce?”. Ultimele linii dinaintea repornirii arată de obicei cauza: lipsă de memorie, eroare de kernel, oprire comandată.

După timp

journalctl --since "2026-09-08 13:00" --until "2026-09-08 13:30"
journalctl --since "1 hour ago"
journalctl --since yesterday --until today
journalctl -u php-fpm --since "10 min ago"

Formatele relative, "2 hours ago", yesterday, today, sunt suficiente pentru majoritatea investigațiilor. Orele sunt în fusul serverului.

După severitate

journalctl -p err               erori și mai grav
journalctl -p warning -b        avertismente și mai grav, de la pornire
journalctl -p 3..4              interval: err și warning

Nivelurile, de la 0 la 7: emerg, alert, crit, err, warning, notice, info, debug. -p err -b este comanda de rutină de dimineață: tot ce a mers prost de la ultima pornire, într-un singur ecran.

După proces, utilizator sau cuvânt

journalctl _PID=12345
journalctl _UID=1001
journalctl -t sshd                   după identificatorul syslog
journalctl -g "Out of memory"        căutare cu expresie regulată
journalctl -k                        doar mesajele kernelului

-g filtrează în jurnal, mai rapid decât grep pe toată ieșirea și cu evidențierea potrivirii. Câmpurile disponibile pentru un mesaj se văd cu journalctl -o verbose -n 1.

Formate de ieșire

journalctl -u nginx -o short-iso        timp în format ISO, ușor de sortat
journalctl -u nginx -o json-pretty      JSON, pentru scripturi
journalctl -u nginx -o cat              doar mesajul, fără prefixe

Pentru un raport trimis cuiva, short-iso cu --no-pager redirecționat într-un fișier este forma cea mai citibilă.

Spațiul pe disc

Jurnalul persistent crește. Verificați cât ocupă și curățați:

journalctl --disk-usage
sudo journalctl --vacuum-time=30d         păstrează ultimele 30 de zile
sudo journalctl --vacuum-size=500M        limitează la 500 MB

Limita permanentă se pune în journald.conf: SystemMaxUse=500M. Un server web cu trafic normal produce câteva zeci de MB pe zi, mai mult dacă un serviciu scrie erori în buclă; o creștere bruscă a jurnalului este ea însăși un simptom de urmărit, cum arată ghidul despre monitorizarea performanței cu htop și atop.

Trei scenarii de depanare

Site-ul dă 502 sau 503

journalctl -u php-fpm -u nginx -p warning --since "30 min ago"

Căutați „connection refused”, „upstream timed out”, „max_children”. Ultimul înseamnă că PHP-FPM a rămas fără procese libere și cere fie mai multe procese, fie mai puține cereri.

Serverul a repornit singur

journalctl -b -1 -n 200 --no-pager
journalctl -k -b -1 -g "Out of memory"

Dacă apare „Out of memory: Killed process”, procesul numit acolo a consumat memoria. De obicei este baza de date sau un script PHP scăpat de sub control. Soluția nu este mai multă memorie, ci găsirea cauzei.

Cineva încearcă parole pe SSH

journalctl -u ssh --since today -g "Failed password" | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

Lista arată adresele cu cele mai multe încercări. Blocarea lor și limitarea încercărilor sunt descrise în ghidul despre blocarea atacurilor brute force pe SSH și în cel despre securizarea serverului cu fail2ban, care citește exact acest jurnal.

Ce nu este în journalctl

• Jurnalele de acces ale serverului web: LiteSpeed, Apache și nginx scriu în fișierele proprii, de obicei sub /var/log sau în directorul fiecărui site. Pe cPanel, le citiți din panou, cum arată ghidul despre jurnalele de erori și acces din cPanel.
• Jurnalele aplicațiilor: Laravel scrie în storage/logs, WordPress în debug.log dacă este activat.
• Jurnalele bazei de date: MariaDB scrie erorile în fișierul ei, deși pornirea și oprirea apar și în journalctl.

Când căutați o problemă, începeți cu journalctl -p err -b pentru sistem și servicii, apoi treceți la fișierele aplicației. Comenzile de bază ale terminalului, care completează journalctl, sunt adunate în ghidul despre comenzile de bază Linux pentru administratori.

Permisiuni

Utilizatorii obișnuiți văd doar propriile mesaje. Pentru tot jurnalul, rulați cu sudo sau adăugați utilizatorul în grupul systemd-journal:

sudo usermod -aG systemd-journal utilizator

Este preferabil față de sudo pe un cont de monitorizare: citește jurnalul, nu poate schimba nimic. Crearea unui astfel de cont este descrisă în ghidul despre crearea unui utilizator cu acces limitat.

Comenzi pe care le veți folosi zilnic

• journalctl -p err -b: erorile de la ultima pornire, primul lucru de dimineață.
• journalctl -u serviciu -f: urmărirea unui serviciu în timp ce reproduceți o problemă.
• journalctl --since "1 hour ago" -p warning: ce s-a întâmplat în ultima oră, fără zgomotul de nivel info.
• journalctl -b -1 -n 200: de ce a repornit serverul.
• journalctl --disk-usage: cât ocupă jurnalul, înainte să umple discul.
• journalctl -u serviciu --since today -o short-iso --no-pager > raport.txt: un extras de trimis cuiva.

Combinarea filtrelor

Filtrele se combină liber, iar combinația este de obicei ce vă duce la cauză. Un serviciu, un interval și un nivel de severitate într-o singură comandă:

journalctl -u lsws -p err --since "2026-09-08 13:00" --until "2026-09-08 13:30" -o short-iso

Rezultatul este exact lista erorilor serverului web din jumătatea de oră în care clienții au raportat problema, cu ore precise, gata de pus într-un raport. Aceeași structură, cu alt serviciu și alt interval, acoperă majoritatea investigațiilor pe un server web.

Când nu știți ce serviciu a produs problema, porniți fără -u, cu intervalul și severitatea, și citiți coloana cu numele procesului din fiecare linie.

Un exemplu complet, de la simptom la cauză

Simptomul: un magazin online raportează că, în fiecare noapte în jurul orei 3, comenzile se blochează câteva minute. Ziua totul merge.

1. journalctl --since "02:50" --until "03:20" -p warning arată, în fiecare noapte, mesaje de la MariaDB despre conexiuni refuzate și, cu un minut înainte, un proces de backup pornit de cron.
2. journalctl -u mariadb --since "02:55" --until "03:10" confirmă: baza de date raportează „too many connections” exact în intervalul în care rulează copia de siguranță.
3. journalctl _COMM=mysqldump --since yesterday arată că exportul durează 9 minute și ține tabelele blocate.

Cauza: copia de siguranță rula fără opțiunea de tranzacție unică și bloca tabelele, iar comenzile de noapte așteptau. Rezolvarea a fost o linie schimbată în cron, iar jurnalul a confirmat a doua zi că avertismentele au dispărut. Fără journalctl, investigația ar fi însemnat ore de citit fișiere separate.

Ce faceți cu ce ați găsit

Păstrați extrasul de jurnal lângă nota despre rezolvare, în jurnalul de administrare al serverului. Următoarea problemă asemănătoare se rezolvă din arhivă, în cinci minute.

De reținut

journalctl cu -u, -b, --since și -p răspunde la aproape orice întrebare despre ce s-a întâmplat pe server și când. Faceți jurnalul persistent, limitați-i dimensiunea, și obișnuiți-vă cu journalctl -p err -b ca prim pas. Documentația distribuției, de exemplu documentația Ubuntu Server, descrie configurarea jurnalului, iar mesajele kernelului pe care le vedeți cu -k sunt explicate în documentația kernelului Linux.

Dacă serverul dvs. dă erori pe care nu le puteți urmări, sau vreți un jurnal citit periodic de cineva, administrarea serverelor face parte din serviciile de SEO tehnic de la GOAI, iar starea generală a site-ului o aflați din auditul SEO gratuit.