Hoe een vol systemd-journaal te repareren

Het systemd-journaal slaat elk logbericht op dat uw server produceert, en op een VPS met een kleine rootpartitie kan het stilletjes uw beschikbare schijfruimte opslokken. Wanneer dat gebeurt, kunnen services niet meer starten, lopen schrijfbewerkingen vast en verliest u juist de diagnostische gegevens die u nodig hebt om uit te zoeken wat er mis is gegaan. Deze handleiding behandelt hoe u het probleem kunt diagnosticeren, onmiddellijk ruimte kunt vrijmaken en journald kunt configureren zodat dit niet opnieuw gebeurt.

Het probleem diagnosticeren

Controleer eerst hoeveel ruimte het logboek in beslag neemt:

journalctl --disk-usage

Dit geeft de totale grootte weer van alle actieve en gearchiveerde logbestanden. Vergelijk dat met uw beschikbare schijfruimte met df -h. Op een rootpartitie van 20 GB vertegenwoordigt zelfs 2 GB aan logbestanden meer dan 10% van de totale schijfruimte, wat voldoende is om problemen te veroorzaken.

Zoek vervolgens uit welke services de meeste logbestanden genereren. Deze éénregelige opdracht rangschikt de top 10 logbronnen van de afgelopen 24 uur:

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

Filter specifiek op fouten met journalctl -p err -b om te zien of een enkele service vastzit in een crash-loop en het journaal overspoelt. U kunt ook controleren of journald de snelheid van bepaalde services beperkt:

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

Onderdrukte berichten betekenen dat een service de standaarddrempel van 10.000 vermeldingen binnen 30 seconden heeft overschreden. Dat is de boosdoener.

Een paar zaken komen vooral vaak voor op VPS-instances. Als Storage=auto is ingesteld en /var/log/journal/ bestaat, gebruikt journald permanente opslag met een standaardlimiet van ongeveer 4 GB. Op een kleine rootpartitie raakt die snel vol. Onjuiste afsluitingen kunnen ook beschadigde journaalbestanden achterlaten met een .journal~ achtervoegsel. Deze bestanden worden niet normaal geroteerd en blijven ruimte innemen.

Logs veilig wissen

Voordat u iets verwijdert, moet u het actieve logbestand roteren, zodat de huidige logs bewaard blijven:

journalctl --rotate

Verwijder vervolgens de gearchiveerde logbestanden. U kunt filteren op leeftijd, grootte of aantal bestanden:

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

De eerste optie verwijdert logbestanden die ouder zijn dan 24 uur. De tweede optie verkleint de totale logboekgrootte tot 100 MB. De derde optie behoudt alleen de vijf meest recente gearchiveerde bestanden. Kies de optie die het beste bij uw situatie past.

Als de schijf volledig vol is en journalctl-opdrachten niet reageren, moet u de journaalbestanden mogelijk handmatig verwijderen:

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

Dit is een laatste redmiddel. Hiermee worden alle opgeslagen logbestanden gewist en wordt de map opnieuw aangemaakt met de juiste machtigingen. Start na elke opschoning de daemon opnieuw op en controleer:

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

De groottelimieten van Journald configureren

De standaardinstellingen voor journald zijn ruim. Op een VPS zijn ze te ruim. Bewerk de configuratie om harde limieten in te stellen voor logopslag. Maak een override-bestand in plaats van de hoofdconfiguratie rechtstreeks te bewerken, zodat uw wijzigingen behouden blijven bij pakketupdates:

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

De belangrijkste richtlijnen:

Beide instellen SystemMaxUse en SystemKeepFree geeft je een dubbele beveiliging: logbestanden worden beperkt tot een vaste grootte en het systeem heeft altijd ruimte, ongeacht wat er verder op de schijf staat.

Permanente versus vluchtige opslag

De Storage= -richtlijn bepaalt waar logs naartoe gaan. Stel Storage=persistent in om logs op /var/log/journal/ op schijf. Dit is wat u wilt voor productieservers, omdat logs herstarts overleven en u crashes achteraf kunt onderzoeken. Als de map niet bestaat, maak deze dan aan:

sudo mkdir -p /var/log/journal

Het alternatief, Storage=volatile, bewaart logbestanden in het RAM-geheugen /run/log/journal/. Logbestanden verdwijnen bij het opnieuw opstarten. Dit is zinvol voor tijdelijke containers of servers die alle logbestanden doorsturen naar een extern systeem.

Compressie uitschakelen op servers met veel verkeer

Journald comprimeert standaard gegevensobjecten groter dan 512 bytes. Op servers die een hoge logboekdoorvoer verwerken, zorgt dit voor extra CPU-belasting. Stel Compress=no als u logs extern doorstuurt en lokale opslag niet hoeft te minimaliseren. Stel dit ook ForwardToConsole=no in productie. Het doorsturen naar de console is synchroon en een vastgelopen virtuele seriële console kan de journald-daemon volledig blokkeren.

Start de service opnieuw op na elke configuratiewijziging:

sudo systemctl restart systemd-journald

Logboekonderhoud automatiseren

Handmatig opschonen is niet schaalbaar. Maak een systemd-timer om logbestanden volgens een schema op te ruimen. Stel een service-unit in op /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

Maak vervolgens een bijbehorende timer aan bij /etc/systemd/system/journal-vacuum.timer:

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

Schakel deze in met sudo systemctl enable --now journal-vacuum.timer. De timer draait elke zondag om 02.00 uur en past zowel op tijd als op grootte gebaseerde bewaartermijnen in één keer toe.

Eén ding dat de timer niet opmerkt: beschadigde journaalbestanden. Na een onjuiste afsluiting plaatst journald beschadigde bestanden in quarantaine door een ~ aan de bestandsnaam toe te voegen. Deze .journal~ bestanden tellen nog steeds mee voor het schijfgebruik, maar worden niet automatisch opgeruimd. Controleer regelmatig of er oude bestanden zijn en verwijder deze:

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

Logs extern doorsturen

Voor servers waar u langdurige bewaring nodig hebt zonder dat de lokale opslag groeit, kunt u logbestanden doorsturen naar een gecentraliseerd systeem. De eenvoudigste aanpak is het inschakelen van syslog-doorsturing in journald.conf:

ForwardToSyslog=yes

Gebruik voor gestructureerde logs met volledige metadata (PID, UID, unitnamen) systemd-journal-remote om vermeldingen in JSON-formaat naar een logboekbeheerplatform te verzenden. Externe logboekopslag beschermt ook uw audittrail als de lokale schijf uitvalt of de server wordt gecompromitteerd.

Conclusie

Een vol systemd-logboek is eenvoudig op te lossen en gemakkelijk te voorkomen. De belangrijkste stappen:

• Controleer het gebruik met journalctl --disk-usage en identificeer storende services.
• Maak onmiddellijk ruimte vrij met journalctl --rotate gevolgd door --vacuum-size of --vacuum-time.
• Stel expliciete groottelimieten in in een journald.conf-overridebestand.
• Automatiseer het opschonen met een systemd-timer.
• Stuur logbestanden extern door voor langdurige opslag.

De VPS- en dedicated server-pakketten van FDC bieden de schijf-I/O en opslagruimte die nodig zijn voor logboekworkloads in de productieomgeving.