So beheben Sie ein volles systemd-Journal

Das systemd-Journal speichert jede Protokollmeldung, die Ihr Server erzeugt, und auf einem VPS mit einer kleinen Root-Partition kann es unbemerkt Ihren verfügbaren Speicherplatz aufbrauchen. Wenn das passiert, können Dienste nicht gestartet werden, Schreibvorgänge stocken, und Sie verlieren genau die Diagnosedaten, die Sie benötigen, um herauszufinden, was schiefgelaufen ist. Dieser Leitfaden behandelt, wie Sie das Problem diagnostizieren, sofort Speicherplatz freigeben und journald so konfigurieren, dass es nicht wieder passiert.

Diagnose des Problems

Überprüfen Sie zunächst, wie viel Speicherplatz das Journal belegt:

journalctl --disk-usage

Hier wird die Gesamtgröße aller aktiven und archivierten Journal-Dateien angezeigt. Vergleichen Sie diese mit Ihrem verfügbaren Speicherplatz df -h. Auf einer 20-GB-Root-Partition machen selbst 2 GB an Logs über 10 % der gesamten Festplattenkapazität aus, was bereits ausreicht, um Probleme zu verursachen.

Finden Sie als Nächstes heraus, welche Dienste die meisten Protokolleinträge erzeugen. Dieser Einzeiler listet die Top 10 der Protokollquellen der letzten 24 Stunden auf:

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

Filtern Sie gezielt nach Fehlern mit journalctl -p err -b , um zu sehen, ob ein einzelner Dienst in einer Absturzschleife feststeckt und das Journal überflutet. Sie können auch überprüfen, ob journald die Rate eines Dienstes begrenzt:

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

Unterdrückungsmeldungen bedeuten, dass ein Dienst den Standardschwellenwert von 10.000 Einträgen innerhalb von 30 Sekunden überschritten hat. Das ist der Übeltäter.

Einige Probleme treten auf VPS-Instanzen besonders häufig auf. Wenn Storage=auto gesetzt ist und /var/log/journal/ existiert, verwendet journald persistenten Speicher mit einer Standardobergrenze von etwa 4 GB. Auf einer kleinen Root-Partition ist dieser schnell voll. Unsachgemäße Herunterfahren können zudem beschädigte Journal-Dateien mit dem Suffix .journal~ . Diese Dateien werden nicht normal rotiert und belegen weiterhin Speicherplatz.

Sicheres Löschen von Protokollen

Bevor Sie etwas entfernen, rotieren Sie die aktive Protokolldatei, damit die aktuellen Protokolle erhalten bleiben:

journalctl --rotate

Löschen Sie anschließend die archivierten Protokolle. Sie können nach Alter, Größe oder Dateianzahl filtern:

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

Der erste Befehl löscht Protokolle, die älter als 24 Stunden sind. Der zweite reduziert die Gesamtgröße des Journals auf 100 MB. Der dritte behält nur die fünf neuesten archivierten Dateien bei. Wählen Sie die Option, die zu Ihrer Situation passt.

Wenn die Festplatte vollständig voll ist und die journalctl-Befehle nicht mehr reagieren, müssen Sie die Journal-Dateien möglicherweise manuell löschen:

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

Dies ist ein letzter Ausweg. Dabei werden alle gespeicherten Protokolle gelöscht und das Verzeichnis mit den richtigen Berechtigungen neu erstellt. Starten Sie nach jeder Bereinigung den Daemon neu und überprüfen Sie:

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

Konfigurieren der Speichergrenzen für Journald

Die Standard-Einstellungen für Journald sind großzügig. Auf einem VPS sind sie zu großzügig. Bearbeiten Sie die Konfiguration, um feste Obergrenzen für die Protokollspeicherung festzulegen. Erstellen Sie eine Übersteuerungsdatei, anstatt die Hauptkonfiguration direkt zu bearbeiten, damit Ihre Änderungen auch nach Paket-Updates erhalten bleiben:

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

Die wichtigsten Anweisungen:

Einstellung beider SystemMaxUse und SystemKeepFree bietet Ihnen einen doppelten Sicherheitsansatz: Logs werden auf eine feste Größe begrenzt, und das System verfügt immer über genügend Spielraum, unabhängig davon, was sich sonst noch auf der Festplatte befindet.

Persistenter vs. flüchtiger Speicher

Die Storage= Steuert, wohin Logs geschrieben werden. Setzen Sie Storage=persistent , um Protokolle auf /var/log/journal/ auf die Festplatte. Dies ist für Produktionsserver empfehlenswert, da die Protokolle einen Neustart überstehen und Sie Abstürze nachträglich untersuchen können. Falls das Verzeichnis nicht existiert, erstellen Sie es:

sudo mkdir -p /var/log/journal

Die Alternative, Storage=volatilebewahrt Protokolle im RAM unter /run/log/journal/. Die Protokolle gehen beim Neustart verloren. Dies ist sinnvoll für kurzlebige Container oder Server, die alle Protokolle an ein externes System weiterleiten.

Deaktivieren der Komprimierung auf Servern mit hohem Datenverkehr

Journald komprimiert standardmäßig Datenobjekte, die größer als 512 Byte sind. Auf Servern mit hohem Protokoll-Durchsatz verursacht dies zusätzlichen CPU-Aufwand. Setzen Sie Compress=no , wenn Sie Protokolle extern weiterleiten und den lokalen Speicherplatz nicht minimieren müssen. Setzen Sie ForwardToConsole=no in der Produktion. Die Konsolenweiterleitung erfolgt synchron, und eine blockierte virtuelle serielle Konsole kann den journald-Daemon vollständig blockieren.

Starten Sie den Dienst nach jeder Konfigurationsänderung neu:

sudo systemctl restart systemd-journald

Automatisierung der Protokollpflege

Manuelle Bereinigung ist nicht skalierbar. Erstellen Sie einen systemd-Timer, um Protokolle nach einem Zeitplan zu bereinigen. Richten Sie eine Service-Einheit unter /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

Erstellen Sie dann einen entsprechenden Timer unter /etc/systemd/system/journal-vacuum.timer:

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

Aktivieren Sie ihn mit sudo systemctl enable --now journal-vacuum.timer. Der Timer läuft jeden Sonntag um 2 Uhr morgens und wendet sowohl zeit- als auch größenbasierte Aufbewahrung in einem Durchgang an.

Eine Sache, die der Timer nicht erfasst: beschädigte Journal-Dateien. Nach einem unsauberen Herunterfahren stellt journald beschädigte Dateien unter Quarantäne, indem es ~ an den Dateinamen. Diese .journal~ Dateien werden weiterhin auf die Festplattennutzung angerechnet, werden aber nicht automatisch bereinigt. Überprüfen Sie regelmäßig, ob alte Dateien vorhanden sind, und entfernen Sie diese:

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

Externe Weiterleitung von Protokollen

Für Server, bei denen eine langfristige Aufbewahrung erforderlich ist, ohne den lokalen Speicher zu vergrößern, leiten Sie die Protokolle an ein zentrales System weiter. Der einfachste Ansatz ist die Aktivierung der Syslog-Weiterleitung in journald.conf:

ForwardToSyslog=yes

Für strukturierte Protokolle mit vollständigen Metadaten (PID, UID, Unit-Namen) verwenden Sie systemd-journal-remote , um Einträge im JSON-Format an eine Protokollverwaltungsplattform zu übermitteln. Die externe Protokollspeicherung schützt zudem Ihren Prüfpfad, falls die lokale Festplatte ausfällt oder der Server kompromittiert wird.

Fazit

Ein volles systemd-Journal lässt sich einfach beheben und leicht verhindern. Die wichtigsten Schritte:

• Überprüfen Sie die Nutzung mit journalctl --disk-usage und identifizieren Sie ressourcenintensive Dienste.
• Schaffen Sie sofort Platz mit journalctl --rotate gefolgt von --vacuum-size oder --vacuum-time.
• Legen Sie explizite Größenbeschränkungen in einer journald.conf-Überschreibungsdatei fest.
• Automatisieren Sie die Bereinigung mit einem systemd-Timer.
• Leiten Sie Protokolle zur langfristigen Aufbewahrung extern weiter.

Die VPS- und Dedicated-Server-Tarife von FDC bieten die für Produktions-Log-Workloads erforderliche Festplatten-E/A und den benötigten Speicherplatz.