Hur man åtgärdar en full systemd-journal

Systemd-journalen lagrar alla loggmeddelanden som din server producerar, och på en VPS med en liten rotpartition kan den i tysthet äta upp ditt tillgängliga diskutrymme. När det händer misslyckas tjänsterna med att starta, skrivningarna avstannar och du förlorar just den diagnostik du behöver för att ta reda på vad som gick fel. Denna guide beskriver hur du diagnostiserar problemet, frigör utrymme omedelbart och konfigurerar journald så att det inte händer igen.

Diagnostisera problemet

Börja med att kontrollera hur mycket utrymme journalen använder:

journalctl --disk-usage

Detta visar den sammanlagda storleken på alla aktiva och arkiverade loggfiler. Jämför det med ditt tillgängliga diskutrymme med df -h. På en rotpartition på 20 GB utgör även 2 GB loggar över 10 % av den totala disken, vilket är tillräckligt för att orsaka problem.

Ta sedan reda på vilka tjänster som genererar mest brus. Denna enradare rangordnar de 10 största loggkällorna från de senaste 24 timmarna:

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

Filtrera specifikt efter fel med journalctl -p err -b för att se om en enskild tjänst har fastnat i en kraschloop och översvämmar journalen. Du kan också kontrollera om journald begränsar hastigheten för några tjänster:

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

Undertryckningsmeddelanden betyder att en tjänst har överskridit standardtröskeln på 10 000 poster inom 30 sekunder. Det är din bov i dramat.

Några saker är särskilt vanliga på VPS-instanser. Om Storage=auto är inställt och /var/log/journal/ finns, använder journald beständig lagring med en standardgräns på ungefär 4 GB. På en liten rotpartition fylls den snabbt. Oren avstängning kan också lämna korrupta journalfiler med ett .journal~ . Dessa filer roterar inte normalt och fortsätter att ta upp utrymme.

Rensa loggar på ett säkert sätt

Innan du tar bort något ska du rotera den aktiva loggfilen så att aktuella loggar bevaras:

journalctl --rotate

Rensa sedan arkiverade loggar. Du kan sortera efter ålder, storlek eller antal filer:

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

Det första alternativet raderar loggar som är äldre än 24 timmar. Det andra alternativet minskar den totala loggstorleken till 100 MB. Det tredje alternativet behåller endast de fem senaste arkiverade filerna. Välj det alternativ som passar din situation.

Om disken är helt full och journalctl-kommandona inte svarar kan du behöva ta bort journalfilerna manuellt:

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

Detta är en sista utväg. Det raderar alla lagrade loggar och återskapar katalogen med korrekta behörigheter. Efter varje rensning, starta om daemonen och verifiera:

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

Konfigurera storleksbegränsningar för Journald

Standardinställningarna för journald är generösa. På en VPS är de för generösa. Redigera konfigurationen för att ställa in hårda gränser för logglagring. Skapa en överskrivningsfil istället för att redigera huvudkonfigurationen direkt, så att dina ändringar bevaras vid paketuppdateringar:

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

De viktigaste direktiven:

Ställ in båda SystemMaxUse och SystemKeepFree ger dig en extra säkerhetsåtgärd: loggarna begränsas till en fast storlek, och systemet har alltid utrymme oavsett vad som annars finns på disken.

Persistent vs. flyktigt lagringsutrymme

Direktivet Storage= styr vart loggarna ska sparas. Ställ in Storage=persistent för att skriva loggar till /var/log/journal/ på disken. Detta är vad du vill ha för produktionsservrar, eftersom loggarna överlever omstarter och du kan undersöka krascher i efterhand. Om katalogen inte finns, skapa den:

sudo mkdir -p /var/log/journal

Alternativet, Storage=volatileär att spara loggarna i RAM-minnet /run/log/journal/. Loggarna försvinner vid omstart. Detta är lämpligt för kortlivade containrar eller servrar som vidarebefordrar alla loggar till ett externt system.

Inaktivera komprimering på servrar med hög trafik

Journald komprimerar som standard dataobjekt som är större än 512 byte. På servrar som hanterar stor logggenomströmning medför detta extra belastning på processorn. Ställ in Compress=no om du vidarebefordrar loggar externt och inte behöver minimera lokal lagring. Ställ även in ForwardToConsole=no i produktion. Konsolviderbefordran är synkron, och en fastnat virtuell seriell konsol kan blockera journald-daemonen helt.

Efter varje konfigurationsändring ska du starta om tjänsten:

sudo systemctl restart systemd-journald

Automatisera logghantering

Manuell rensning är inte skalbar. Skapa en systemd-timer för att rensa loggar enligt ett schema. Konfigurera en serviceenhet på /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

Skapa sedan en matchande timer vid /etc/systemd/system/journal-vacuum.timer:

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

Aktivera den med sudo systemctl enable --now journal-vacuum.timer. Timern körs varje söndag kl. 02.00 och tillämpar både tids- och storleksbaserad lagring i ett enda steg.

En sak som timern inte fångar upp: skadade journalfiler. Efter en oren avstängning sätter journald skadade filer i karantän genom att lägga till ett ~ till filnamnet. Dessa .journal~ filerna räknas fortfarande in i diskanvändningen men rensas inte automatiskt. Kontrollera regelbundet efter och ta bort gamla filer:

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

Vidarebefordra loggar externt

För servrar där du behöver långsiktig lagring utan att utöka det lokala lagringsutrymmet, vidarebefordra loggar till ett centraliserat system. Det enklaste sättet är att aktivera syslog-vidarebefordran i journald.conf:

ForwardToSyslog=yes

För strukturerade loggar med fullständig metadata (PID, UID, enhetsnamn), använd systemd-journal-remote för att skicka JSON-formaterade poster till en logghanteringsplattform. Extern logglagring skyddar också din revisionsspår om den lokala disken går sönder eller servern utsätts för intrång.

Slutsats

En fullständig systemd-journal är enkel att åtgärda och lätt att förebygga. De viktigaste stegen:

• Kontrollera användningen med journalctl --disk-usage och identifiera störande tjänster.
• Rensa utrymme omedelbart med journalctl --rotate följt av --vacuum-size eller --vacuum-time.
• Ange uttryckliga storleksgränser i en journald.conf-överskrivningsfil.
• Automatisera rensningen med en systemd-timer.
• Vidarebefordra loggar externt för långsiktig lagring.

FDC:s VPS- och dedikerade serverpaket tillhandahåller den disk-I/O och lagringskapacitet som krävs för loggarbetsbelastningar i produktion.