Cum se remediază un jurnal systemd plin

Jurnalul systemd stochează fiecare mesaj de jurnal generat de serverul dvs. și, pe un VPS cu o partiție root mică, poate consuma în tăcere spațiul disponibil pe disc. Când se întâmplă acest lucru, serviciile nu se mai pornesc, scrierile se blochează și pierdeți chiar diagnosticările de care aveți nevoie pentru a afla ce a mers prost. Acest ghid prezintă modul de diagnosticare a problemei, eliberarea imediată a spațiului și configurarea journald pentru ca acest lucru să nu se mai întâmple.

Diagnosticarea problemei

Începeți prin a verifica cât spațiu ocupă jurnalul:

journalctl --disk-usage

Acesta raportează dimensiunea combinată a tuturor fișierelor jurnal active și arhivate. Comparați acest lucru cu spațiul disponibil pe disc folosind df -h. Pe o partiție root de 20 GB, chiar și 2 GB de jurnale reprezintă peste 10% din spațiul total pe disc, ceea ce este suficient pentru a cauza probleme.

Apoi, aflați care servicii generează cel mai mult zgomot. Această linie de comandă clasează primele 10 surse de jurnale din ultimele 24 de ore:

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

Filtrează erorile în mod specific cu journalctl -p err -b pentru a vedea dacă un singur serviciu este blocat într-o buclă de blocare și inundă jurnalul. De asemenea, puteți verifica dacă journald limitează rata oricărui serviciu:

journalctl -u systemd-journald | grep -i "suppressed"

Mesajele de suprimare înseamnă că un serviciu a depășit pragul implicit de 10.000 de intrări în 30 de secunde. Acesta este vinovatul.

Câteva aspecte sunt deosebit de frecvente pe instanțele VPS. Dacă Storage=auto este setat și /var/log/journal/ există, journald utilizează stocarea persistentă cu o limită implicită de aproximativ 4 GB. Pe o partiție root mică, aceasta se umple rapid. Opririle necorespunzătoare pot lăsa, de asemenea, fișiere jurnal corupte cu sufixul .journal~ . Aceste fișiere nu se rotesc în mod normal și continuă să ocupe spațiu.

Ștergerea jurnalelor în siguranță

Înainte de a șterge ceva, rotiți fișierul jurnal activ, astfel încât jurnalele curente să fie păstrate:

journalctl --rotate

Apoi ștergeți jurnalele arhivate. Puteți selecta în funcție de vechime, dimensiune sau număr de fișiere:

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

Prima opțiune șterge jurnalele mai vechi de 24 de ore. A doua opțiune reduce dimensiunea totală a jurnalului la 100 MB. A treia opțiune păstrează doar cele mai recente cinci fișiere arhivate. Alegeți opțiunea care se potrivește situației dvs.

Dacă discul este complet plin și comenzile journalctl nu răspund, poate fi necesar să ștergeți manual fișierele jurnal:

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

Aceasta este o soluție de ultimă instanță. Șterge toate jurnalele stocate și recreează directorul cu permisiunile corecte. După orice curățare, reporniți daemonul și verificați:

sudo systemctl restart systemd-journald
journalctl --disk-usage

Configurarea limitelor de dimensiune pentru Journald

Setările implicite ale journald sunt generoase. Pe un VPS, sunt prea generoase. Editați configurația pentru a seta limite stricte pentru stocarea jurnalelor. Creați un fișier de suprascriere în loc să editați direct configurația principală, astfel încât modificările dvs. să rămână valabile după actualizările pachetului:

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

Directivele cheie:

Setarea ambelor SystemMaxUse și SystemKeepFree vă oferă o abordare de tip „centură și bretele”: jurnalele sunt limitate la o dimensiune fixă, iar sistemul are întotdeauna spațiu de manevră, indiferent de ce altceva se află pe disc.

Stocare persistentă vs. volatilă

Directiva Storage= directiva controlează unde sunt stocate jurnalele. Setați Storage=persistent pentru a scrie jurnalele pe /var/log/journal/ pe disc. Aceasta este opțiunea recomandată pentru serverele de producție, deoarece jurnalele supraviețuiesc repornirilor și puteți investiga blocările după ce acestea au avut loc. Dacă directorul nu există, creați-l:

sudo mkdir -p /var/log/journal

Alternativa, Storage=volatile, păstrează jurnalele în RAM la /run/log/journal/. Jurnalele dispar la repornire. Aceasta este o opțiune utilă pentru containerele efemere sau pentru serverele care redirecționează toate jurnalele către un sistem extern.

Dezactivarea compresiei pe serverele cu trafic intens

Journald comprimă în mod implicit obiectele de date mai mari de 512 octeți. Pe serverele care gestionează un volum mare de jurnale, acest lucru adaugă o sarcină suplimentară procesorului. Setați Compress=no dacă redirecționați jurnalele către un sistem extern și nu este necesar să reduceți la minimum spațiul de stocare local. Setați, de asemenea, ForwardToConsole=no în producție. Redirecționarea consolei este sincronă, iar o consolă serială virtuală blocată poate bloca complet daemonul journald.

După orice modificare de configurare, reporniți serviciul:

sudo systemctl restart systemd-journald

Automatizarea întreținerii jurnalelor

Curățarea manuală nu este scalabilă. Creați un timer systemd pentru a curăța jurnalele conform unui program. Configurați o unitate de serviciu la /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

Apoi creați un timer corespunzător la /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

Activați-l cu sudo systemctl enable --now journal-vacuum.timer. Cronometrul rulează în fiecare duminică la ora 2:00 și aplică reținerea bazată atât pe timp, cât și pe dimensiune într-o singură trecere.

Un lucru pe care cronometrul nu îl va detecta: fișierele jurnal corupte. După o oprire necorespunzătoare, journald pune în carantină fișierele deteriorate adăugând un ~ la numele fișierului. Aceste .journal~ fișiere sunt încă luate în calcul la utilizarea discului, dar nu vor fi curățate automat. Verificați periodic și eliminați-le pe cele vechi:

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

Redirecționarea jurnalelor către un sistem extern

Pentru serverele unde aveți nevoie de păstrare pe termen lung fără a mări spațiul de stocare local, redirecționați jurnalele către un sistem centralizat. Cea mai simplă abordare este activarea redirecționării syslog în journald.conf:

ForwardToSyslog=yes

Pentru jurnale structurate cu metadate complete (PID, UID, nume de unități), utilizați systemd-journal-remote pentru a trimite intrări în format JSON către o platformă de gestionare a jurnalelor. Stocarea externă a jurnalelor vă protejează, de asemenea, pista de audit în cazul în care discul local se defectează sau serverul este compromis.

Concluzie

Un jurnal systemd complet este ușor de remediat și de prevenit. Pașii cheie:

• Verificați utilizarea cu journalctl --disk-usage și identificați serviciile care generează zgomot.
• Eliberați spațiul imediat cu journalctl --rotate urmat de --vacuum-size sau --vacuum-time.
• Setați limite de dimensiune explicite într-un fișier de suprascriere journald.conf.
• Automatizați curățarea cu un temporizator systemd.
• Redirecționați jurnalele către un sistem extern pentru păstrare pe termen lung.

Planurile VPS și de servere dedicate ale FDC oferă I/O-ul de disc și spațiul de stocare necesare pentru sarcinile de lucru cu jurnale de producție.