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
grepin/var/log/syslog. Das Systemd Journal (journald) speichert Logs binär, indiziert und strukturiert. Mitjournalctlkö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/journalwerden 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
journalctlFilter (-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 |