linux-ubuntu-debian logging systemd journalctl troubleshooting

Journalctl & Structured Logging – Log Analysis (Artikel 008)

Der ultimative Guide zu Journalctl. Wie man Logs effizient filtert, persistent speichert und strukturierte Metadaten für das Troubleshooting nutzt.

# Journalctl: Die Revolution im Linux-Logging

TL;DR / Management Summary Vergessen Sie grep in /var/log/syslog. Das Systemd Journal (journald) speichert Logs binär, indiziert und strukturiert. Mit journalctl können Sie Logs nach Zeit, Dienst, Priorität oder Kernel-Meldungen filtern, ohne riesige Textdateien durchwühlen zu müssen. Es ist das wichtigste Werkzeug für die Fehlerdiagnose auf modernen Linux-Systemen.


# 1. Einführung & Architektur

Warum binäre Logs besser sind.

Klassisches Logging (Syslog) schreibt unstrukturierten Text. Journald speichert Metadaten (UID, PID, Service-Name) zu jeder Zeile.

  • Speicherort: Standardmäßig /run/log/journal (flüchtig im RAM).
  • Persistenz: Durch Erstellen von /var/log/journal werden Logs dauerhaft gespeichert.
graph LR
    A[Application] -->|stdout/stderr| B[systemd-journald]
    C[Kernel] -->|kmsg| B
    D[Syslog Protocol] -->|/dev/log| B
    B -->|Binary Storage| E[/var/log/journal]
    E -->|Query API| F[journalctl]

# 2. Grundlegende Nutzung

Die Befehle, die jeder Admin kennen muss.

# Live-Monitoring (Tail)

# Alle Logs live sehen (wie tail -f)
journalctl -f

# Nur Logs eines bestimmten Dienstes live
journalctl -u nginx -f

# Filtern nach Zeit

# Logs seit heute Morgen
journalctl --since "today"

# Logs der letzten Stunde
journalctl --since "-1h"

# Logs eines bestimmten Zeitraums
journalctl --since "2023-10-01 12:00" --until "2023-10-01 13:00"

# 3. Fortgeschrittene Filter

Die Nadel im Heuhaufen finden.

# Filter nach Priorität

Zeige nur Fehler (err) und schlimmer (crit, alert, emerg).

journalctl -p err

# Filter nach Kernel-Meldungen (Dmesg-Ersatz)

journalctl -k

# JSON-Output für Automatisierung

Ideal, um Logs an ELK (Elasticsearch) oder externe Tools zu übergeben.

journalctl -u ssh -o json-pretty

# 4. Speicherplatz-Management (Retention)

Damit die Disk nicht volläuft.

Das Journal rotiert automatisch, aber man kann Grenzen setzen. Konfiguration: /etc/systemd/journald.conf

[Journal]
Storage=persistent
# Maximal 1GB Logs aufheben
SystemMaxUse=1G
# Logs maximal 1 Monat behalten
MaxRetentionSec=1month

Manuelles Aufräumen:

# Alles löschen bis auf die letzten 500MB
journalctl --vacuum-size=500M

# Alles löschen, was älter als 2 Wochen ist
journalctl --vacuum-time=2weeks

# 5. Day-2 Operations: Zentrales Logging

Logs gehören nicht auf den Server.

Für Enterprise-Umgebungen empfiehlt es sich, systemd-journal-upload zu nutzen, um Logs an einen zentralen Log-Server zu senden, oder klassisch rsyslog zu konfigurieren, um die Journal-Daten weiterzuleiten.


# 6. Troubleshooting & “War Stories”

Wenn das Loggen selbst Probleme macht.

# Story 1: “Logs sind nach Reboot weg”

Symptom: journalctl -b -1 (Logs vom vorherigen Boot) sagt “Specifying boot ID has no effect, no persistent journal was found”. Ursache: Das Verzeichnis /var/log/journal existiert nicht, daher speichert Systemd nur im RAM (/run). Lösung: mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal && systemctl restart systemd-journald.

# Story 2: “Corrupt Journal Files”

Symptom: Fehlermeldungen beim Lesen des Journals. Ursache: Unsauberer Shutdown oder Disk-Fehler. Lösung: journalctl --verify prüft die Integrität. Defekte Files löschen (rm /var/log/journal/*/*.journal) – Systemd legt neue an.


# 7. Fazit & Empfehlung

  • Lernen Sie journalctl Filter (-u, -p, --since). Es spart Ihnen Stunden.
  • Aktivieren Sie persistentes Logging auf Servern.
  • Nutzen Sie SystemMaxUse, um Disk-Space-Probleme proaktiv zu verhindern.

# Anhang: Cheatsheet

Aufgabe Befehl
Logs vom aktuellen Boot journalctl -b
Logs vom letzten Boot journalctl -b -1
Nur Fehler anzeigen journalctl -p 3 -xb
Logs eines Service journalctl -u <service>
Speicherplatz freigeben journalctl --vacuum-time=2d