Wenn auf einem Linux-Server etwas schiefgeht, ist Ihr erster Instinkt, die Logs zu pruefen. Auf jeder modernen Linux-Distribution mit systemd ist das primaere Werkzeug dafuer journalctl. Es bietet eine einheitliche Schnittstelle zur Abfrage strukturierter Logs von jedem Dienst, dem Kernel und dem Boot-Prozess selbst — alles indexiert und filterbar nach Zeit, Prioritaet, Service-Unit und Dutzenden weiterer Felder.

Dieser Leitfaden behandelt alles, was Sie wissen muessen, um journalctl effektiv fuer die taegliche Administration und die Fehlerbehebung bei Vorfaellen einzusetzen, von grundlegenden Abfragen bis hin zu erweiterter Filterung, Konfiguration persistenter Speicherung und Integration mit externen Log-Analyse-Tools.

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass Sie Folgendes haben:

  • Ein Linux-System mit systemd (Ubuntu 20.04+, Debian 11+, RHEL/CentOS 8+, Fedora, Arch oder aehnlich)
  • Terminal-Zugang mit sudo-Berechtigungen
  • Grundlegende Vertrautheit mit systemd-Diensten (systemctl start, systemctl status)

Das systemd-Journal verstehen

Das systemd-Journal ist ein zentralisiertes Logging-System, das vom Dienst systemd-journald verwaltet wird. Im Gegensatz zum traditionellen Syslog, das Klartext in Dateien unter /var/log/ schreibt, speichert das Journal Eintraege in einem strukturierten Binaerformat, das Metadaten mit jeder Log-Zeile enthaelt:

  • Zeitstempel mit Mikrosekunden-Praezision
  • Boot-ID — welche Boot-Sitzung den Eintrag erzeugt hat
  • Unit-Name — welcher systemd-Dienst ihn generiert hat
  • PID und UID — Prozess- und Benutzer-Identifikatoren
  • Prioritaetsstufe — von Notfall (0) bis Debug (7)
  • Maschinen-ID — nuetzlich in Multi-Host-Setups

Diese Struktur macht journalctl so leistungsstark: Sie koennen nach jeder Kombination dieser Felder filtern, ohne komplexe grep-Muster schreiben zu muessen.

Pruefen Sie, ob journald auf Ihrem System laeuft:

systemctl status systemd-journald

Sehen Sie, wie viel Festplattenplatz das Journal aktuell belegt:

journalctl --disk-usage

Grundlegende journalctl-Nutzung

Alle Logs anzeigen

journalctl

Dies oeffnet das vollstaendige Journal in einem Pager (normalerweise less). Druecken Sie q zum Beenden, / zum Suchen und G, um ans Ende zu springen (neueste Eintraege).

Neueste Eintraege anzeigen

# Die letzten 50 Zeilen anzeigen
journalctl -n 50

# Die letzten 100 Zeilen ohne Pager anzeigen (direkte Ausgabe)
journalctl -n 100 --no-pager

Logs in Echtzeit verfolgen

journalctl -f

Dies funktioniert wie tail -f, aber fuer das gesamte Journal. Druecken Sie Strg+C zum Stoppen. Sie koennen -f mit jedem Filter kombinieren:

# Nur nginx-Logs verfolgen
journalctl -f -u nginx.service

Umgekehrte Reihenfolge (Neueste zuerst)

journalctl -r

Filterung nach Zeit

Zeitbasierte Filterung ist eine der nuetzlichsten Funktionen von journalctl fuer die Untersuchung von Vorfaellen.

Absolute Zeitbereiche

# Logs seit einem bestimmten Datum und Uhrzeit
journalctl --since "2025-12-26 08:00:00"

# Logs zwischen zwei Zeitstempeln
journalctl --since "2025-12-25 18:00" --until "2025-12-26 06:00"

# Logs eines bestimmten Tages (ganzer Tag)
journalctl --since "2025-12-25" --until "2025-12-26"

Relative Zeitbereiche

# Logs der letzten Stunde
journalctl --since "1 hour ago"

# Logs der letzten 30 Minuten
journalctl --since "30 min ago"

# Seit gestern
journalctl --since yesterday

# Nur heute
journalctl --since today

Aktueller Boot vs. vorherige Boots

# Logs nur vom aktuellen Boot
journalctl -b

# Logs vom vorherigen Boot
journalctl -b -1

# Logs von zwei Boots zurueck
journalctl -b -2

# Alle verfuegbaren Boots auflisten
journalctl --list-boots

Die Ausgabe von --list-boots zeigt Boot-IDs und Zeitstempel, was unschaetzbar ist, um zu untersuchen, was vor einem unerwarteten Neustart passiert ist.

Filterung nach Service-Unit

Hier spart journalctl die meiste Zeit im Vergleich zur traditionellen Log-Analyse.

Einzelner Dienst

# Alle Logs von nginx
journalctl -u nginx.service

# Alle Logs vom SSH-Daemon
journalctl -u sshd.service

# Alle Logs von PostgreSQL
journalctl -u postgresql.service

Mehrere Dienste

# Logs von nginx und PHP-FPM
journalctl -u nginx.service -u php8.1-fpm.service

Service- und Zeitfilter kombinieren

# nginx-Fehler der letzten 2 Stunden
journalctl -u nginx.service --since "2 hours ago" -p err

Benutzer-Dienste

# Logs eines Benutzer-Dienstes
journalctl --user -u myapp.service

Filterung nach Prioritaet

Syslog-Prioritaetsstufen reichen von 0 (Notfall) bis 7 (Debug):

PrioritaetSchluesselwortBeschreibung
0emergSystem nicht benutzbar
1alertSofortige Aktion erforderlich
2critKritische Bedingungen
3errFehlerbedingungen
4warningWarnungsbedingungen
5noticeNormal, aber bedeutsam
6infoInformativ
7debugDebug-Nachrichten

Nach maximaler Prioritaet filtern

# Fehler und hoeher anzeigen (0-3)
journalctl -p err

# Warnungen und hoeher anzeigen (0-4)
journalctl -p warning

# Kritisch und hoeher anzeigen (0-2)
journalctl -p crit

Prioritaetsbereich

# Nur Warnungen und Fehler anzeigen (Kritisch/Notfall ausschliessen)
journalctl -p warning..err

Mit anderen Filtern kombinieren

# nginx-Fehler der letzten 24 Stunden
journalctl -u nginx.service -p err --since "24 hours ago"

Filterung nach anderen Feldern

journalctl kann nach jedem im Journal gespeicherten Feld filtern. Verfuegbare Felder auflisten:

journalctl --fields

Gaengige Feld-Filter

# Logs einer bestimmten PID
journalctl _PID=1234

# Logs eines bestimmten Benutzers
journalctl _UID=1000

# Kernel-Logs
journalctl -k
# oder gleichwertig:
journalctl _TRANSPORT=kernel

# Logs eines bestimmten Programms
journalctl /usr/sbin/sshd

# Logs eines bestimmten Hostnamens (in Multi-Host-Setups)
journalctl _HOSTNAME=webserver01

Feld-Filter kombinieren

Wenn Sie mehrere verschiedene Felder angeben, werden sie mit UND-Logik kombiniert:

# Logs von UID 1000 UND Prioritaet Fehler
journalctl _UID=1000 -p err

Wenn Sie dasselbe Feld mehrmals angeben, werden sie mit ODER-Logik kombiniert:

# Logs von PID 1234 ODER PID 5678
journalctl _PID=1234 _PID=5678

Ausgabeformate

journalctl unterstuetzt mehrere Ausgabeformate fuer verschiedene Anwendungsfaelle:

# Standard-Kurzformat (aehnlich wie Syslog)
journalctl -o short

# Kurzformat mit ISO-Zeitstempeln
journalctl -o short-iso

# Vollstaendige strukturierte Ausgabe
journalctl -o verbose

# JSON-Format (ein Objekt pro Zeile)
journalctl -o json

# Formatiertes JSON fuer bessere Lesbarkeit
journalctl -o json-pretty

# Nur die Nachricht (ohne Metadaten)
journalctl -o cat

# Binaeres Export-Format (fuer journalctl --merge)
journalctl -o export

JSON-Ausgabe fuer Log-Analyse

Das JSON-Format ist besonders nuetzlich fuer die Weiterleitung an Analyse-Tools:

# Alle nginx-Fehler als JSON extrahieren
journalctl -u nginx.service -p err -o json --no-pager | jq '.'

# Bestimmte Felder abrufen
journalctl -u sshd.service -o json --no-pager | jq '{timestamp: .__REALTIME_TIMESTAMP, message: .MESSAGE, pid: ._PID}'

Konfiguration persistenter Speicherung

Standardmaessig speichern einige Distributionen Journal-Logs nur im Arbeitsspeicher (/run/log/journal/), was bedeutet, dass sie beim Neustart verloren gehen.

Persistente Speicherung aktivieren

# Verzeichnis fuer persistente Speicherung erstellen
sudo mkdir -p /var/log/journal

# Korrekte Eigentuemer setzen
sudo systemd-tmpfiles --create --prefix /var/log/journal

# journald neu starten
sudo systemctl restart systemd-journald

Aufbewahrungslimits konfigurieren

Bearbeiten Sie /etc/systemd/journald.conf:

[Journal]
# Maximaler Festplattenplatz fuer Journal-Dateien
SystemMaxUse=500M

# Maximale Groesse einzelner Journal-Dateien
SystemMaxFileSize=50M

# Maximale Aufbewahrungsdauer fuer Eintraege
MaxRetentionSec=1month

# Maximaler Festplattenplatz fuer Laufzeit-Journal (fluechtiger Speicher)
RuntimeMaxUse=100M

Nach der Bearbeitung starten Sie den Dienst neu:

sudo systemctl restart systemd-journald

Manuelle Bereinigung

# Eintraege aelter als 2 Wochen entfernen
sudo journalctl --vacuum-time=2weeks

# Journal auf maximal 500 MB reduzieren
sudo journalctl --vacuum-size=500M

# Nur die 5 neuesten Journal-Dateien behalten
sudo journalctl --vacuum-files=5

Einstellungen ueberpruefen

# Aktuelle Festplattennutzung pruefen
journalctl --disk-usage

# Journal-Konfiguration anzeigen
systemd-analyze cat-config systemd/journald.conf

Kernel-Nachrichten

Fuer die Fehlersuche auf Kernel-Ebene ersetzt journalctl den Befehl dmesg mit besserer Filterung:

# Alle Kernel-Nachrichten
journalctl -k

# Kernel-Nachrichten des aktuellen Boots
journalctl -k -b

# Nur Kernel-Fehler
journalctl -k -p err

# Kernel-Nachrichten eines vorherigen Boots
journalctl -k -b -1

Dies ist unverzichtbar fuer die Diagnose von Hardware-Problemen, Treiber-Fehlern, Dateisystem-Fehlern und OOM-Kills (Speichermangel).

Praktische Beispiele zur Fehlersuche

Einen Service-Absturz untersuchen

# Pruefen, wann der Dienst zuletzt fehlgeschlagen ist
systemctl status myapp.service

# Die letzten 200 Zeilen vor dem Absturz anzeigen
journalctl -u myapp.service -n 200 --no-pager

# Nach OOM-Kills zum gleichen Zeitpunkt suchen
journalctl -k --since "1 hour ago" | grep -i "oom\|killed process"

SSH-Anmeldefehler diagnostizieren

# Alle SSH-Authentifizierungsnachrichten
journalctl -u sshd.service | grep -i "failed\|invalid\|accepted"

# Fehlgeschlagene SSH-Versuche der letzten 24 Stunden
journalctl -u sshd.service --since "24 hours ago" -p warning

Festplatten- und Dateisystem-Probleme ueberwachen

# Dateisystem-Fehler vom Kernel
journalctl -k | grep -i "ext4\|xfs\|btrfs\|i/o error\|read-only"

# Festplattenbezogene Nachrichten
journalctl -k | grep -i "sd[a-z]\|nvme\|ata"

Boot-Probleme pruefen

# Vollstaendiges Log des letzten fehlgeschlagenen Boots
journalctl -b -1 -p err

# Alle Boots auflisten, um den problematischen zu finden
journalctl --list-boots

# Nur Dienste anzeigen, die beim Boot nicht gestartet werden konnten
journalctl -b -p err | grep "Failed to start"

Integration mit externen Tools

An rsyslog weiterleiten

Wenn Sie traditionelle Log-Dateien neben dem Journal benoetigen, konfigurieren Sie rsyslog zum Lesen aus dem Journal. In /etc/rsyslog.conf:

module(load="imjournal")

Fuer Elasticsearch/Loki exportieren

# Als JSON fuer die Aufnahme exportieren
journalctl -o json --since "1 hour ago" --no-pager > /tmp/journal-export.json

# An einen Remote-Endpunkt streamen
journalctl -f -o json | curl -X POST -H "Content-Type: application/json" -d @- http://logserver:9200/journal/_bulk

Mit systemd-journal-remote verwenden

Fuer zentralisiertes Logging ueber mehrere Server bietet systemd systemd-journal-remote:

# Auf dem zentralen Server installieren
sudo apt install systemd-journal-remote

# Den Empfaenger aktivieren
sudo systemctl enable --now systemd-journal-remote.socket

Fehlerbehebung

Beschaedigte Journal-Dateien

# Journal-Integritaet pruefen
journalctl --verify

# Wenn beschaedigt, rotieren und neu starten
sudo journalctl --rotate
sudo journalctl --vacuum-time=1s

Keine Logs von einem bestimmten Dienst

  1. Pruefen Sie, ob der Dienst Standard-Ausgabe verwendet:
systemctl show myapp.service | grep -i "standard\|log"
  1. Stellen Sie sicher, dass die Unit-Datei die Ausgabe ans Journal weiterleitet:
[Service]
StandardOutput=journal
StandardError=journal

journalctl ist langsam bei grossen Journals

# Verwenden Sie --since, um den Suchbereich einzuschraenken
journalctl --since "1 hour ago" -u myapp.service

# Reduzieren Sie die Journal-Groesse
sudo journalctl --vacuum-size=200M

Zusammenfassung

journalctl ist das Standardwerkzeug zur Abfrage von Logs auf systemd-basierten Linux-Systemen. Wichtige Erkenntnisse:

  • Verwenden Sie -u zum Filtern nach Dienst, -p zum Filtern nach Prioritaet und --since/--until fuer Zeitbereiche
  • Kombinieren Sie Filter fuer gezielte Suchen: journalctl -u nginx -p err --since "1 hour ago"
  • Verwenden Sie -b, um Abfragen auf den aktuellen oder vorherige Boot-Sitzungen einzuschraenken
  • Aktivieren Sie persistente Speicherung mit mkdir -p /var/log/journal, wenn Ihre Distribution standardmaessig fluechtige Speicherung verwendet
  • Konfigurieren Sie Aufbewahrungslimits in /etc/systemd/journald.conf, um Festplattenerschoepfung zu verhindern
  • Verwenden Sie -o json fuer die Integration mit Log-Analyse-Pipelines wie Elasticsearch oder Loki
  • Verwenden Sie journalctl -f anstelle von tail -f fuer Echtzeitueberwachung mit Filterung

Fuer verwandte Themen lesen Sie unsere Anleitungen zu Logrotate: Log-Dateien unter Linux verwalten und Elasticsearch-Setup fuer Log-Analyse.