Logs auswerten mit journalctl – Anleitung

Wenn ein Dienst streikt, liegt die Antwort fast immer im Log. Auf modernen Linux-Systemen sammelt systemd alle Protokolle zentral im „Journal“. Mit journalctl durchsuchst du sie gezielt. In dieser Anleitung lernst du, Logs mit journalctl auszuwerten: filtern, Fehler finden und live mitlesen.

Wenn ein Dienst streikt, liegt die Antwort fast immer im Log. Auf modernen Linux-Systemen sammelt systemd alle Protokolle zentral im sogenannten Journal, und mit journalctl durchsuchst du sie gezielt – nach Dienst, Zeitraum oder Schweregrad. Das ist deutlich mächtiger als das Durchwühlen einzelner Textdateien unter /var/log. In dieser Anleitung lernst du, Logs mit journalctl auszuwerten: filtern, Fehler finden, live mitlesen, die Ausgabe formatieren und das Journal dauerhaft speichern, damit deine Protokolle auch einen Neustart überleben.

Das systemd-Journal

Das Journal ist die zentrale Sammelstelle für die Logs von Kernel, Diensten und dem System. Statt in vielen einzelnen Dateien zu suchen, stellst du mit journalctl präzise Anfragen. Besonders nützlich ist das bei eigenen systemd-Services.

Nach einem Dienst filtern

Der wichtigste Filter ist -u für eine bestimmte Unit. So siehst du nur die Logs des SSH-Servers:

journalctl -u ssh

journalctl -u ssh

Mit -f folgst du den Logs live – ideal beim Debuggen:

journalctl -u ssh -f

journalctl -u ssh -f

Nach Zeit filtern

Oft interessiert nur ein bestimmter Zeitraum. journalctl versteht dafür auch natürliche Angaben:

journalctl --since "2026-09-01" --until "2026-09-02"
journalctl --since "1 hour ago"
journalctl -b

journalctl --since "2026-09-01" --until "2026-09-02"
journalctl --since "1 hour ago"
journalctl -b

Der Parameter -b zeigt nur Einträge seit dem letzten Systemstart.

Gezielt nach Fehlern suchen

Mit -p filterst du nach Priorität. So bekommst du ausschließlich Fehler und Schlimmeres:

journalctl -p err -b

journalctl -p err -b

Das Journal aufräumen

Auch das Journal belegt Speicher. Wie viel, verrät:

journalctl --disk-usage

journalctl --disk-usage

Verkleinern kannst du es nach Größe oder Alter:

sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=14d

sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=14d

Läuft die Platte allgemein voll, hilft Speicherplatz analysieren.

Das Journal dauerhaft speichern

Standardmäßig legt systemd das Journal auf manchen Systemen nur flüchtig im Arbeitsspeicher ab – nach einem Neustart sind die alten Einträge dann verschwunden. Für die Fehlersuche ist das ärgerlich, denn oft willst du gerade wissen, was vor dem letzten Boot passiert ist. Ein persistentes Journal löst das Problem.

Dazu genügt es, das Verzeichnis /var/log/journal anzulegen (oder in /etc/systemd/journald.conf die Option Storage=persistent zu setzen) und den Dienst neu zu starten. Ab dann bleiben Logs über Neustarts hinweg erhalten, und du kannst mit journalctl --list-boots gezielt einen früheren Systemstart auswählen.

• Aktueller Boot: journalctl -b zeigt nur Meldungen seit dem letzten Start.
• Vorheriger Boot: journalctl -b -1 springt einen Neustart zurück.
• Alle Boots auflisten: journalctl --list-boots.

Ausgabe formatieren und live mitlesen

journalctl kann seine Ausgabe in verschiedene Formate bringen – praktisch für Skripte oder zum schnellen Überfliegen. Mit -o wählst du das Format, mit -f folgst du dem Log in Echtzeit, ähnlich wie beim klassischen tail -f. Gerade beim Nachstellen eines Fehlers ist das Live-Mitlesen unschlagbar.

Ein bewährter Ablauf: In einem Terminal journalctl -u dienst -f laufen lassen und in einem zweiten den Fehler auslösen. So siehst du unmittelbar, welche Meldung der Dienst dabei ausgibt.

Prioritätsstufen gezielt nutzen

Jede Log-Meldung trägt eine Priorität, von emerg (Katastrophe) bis debug (Detailrauschen). Mit -p filterst du nach Schweregrad und blendest so das Grundrauschen aus. journalctl -p err zeigt zum Beispiel alles ab Fehlerstufe aufwärts – ideal, um schnell zum Kern eines Problems zu kommen.

Kombiniere die Priorität ruhig mit anderen Filtern, etwa journalctl -u nginx -p err --since today. Wie du auf gefundene Probleme reagierst und Dienste im Blick behältst, ergänzt der Beitrag zum Überwachen von RAM und Prozessen.

Gezielt nach Prozess, Benutzer oder Kernel filtern

Neben Dienst, Zeit und Priorität kennt journalctl noch feinere Filter, die bei der Ursachensuche helfen. Du kannst nach einem konkreten Prozess, einem Benutzerkonto oder ausschließlich nach Kernel-Meldungen filtern. Das grenzt die Datenmenge stark ein und führt schneller zur eigentlichen Ursache.

• Nur Kernel-Meldungen: journalctl -k zeigt ausschließlich das, was der Kernel meldet – ideal bei Hardware- oder Treiberproblemen.
• Nach Prozess-ID: journalctl _PID=1234 filtert auf einen bestimmten Prozess.
• Nach Programm: journalctl /usr/sbin/sshd zeigt Meldungen genau dieses Programms.
• Kombinieren: mehrere Filter lassen sich verketten, um exakt den relevanten Ausschnitt zu erhalten.

Diese Feldfilter beruhen auf den Metadaten, die systemd zu jeder Meldung speichert. Mit journalctl -o verbose siehst du alle verfügbaren Felder einer Zeile und lernst so, wonach du überhaupt filtern kannst – ein starker Vorteil gegenüber reinen Textlogs.

Häufige Fragen

Beim Arbeiten mit dem Journal tauchen einige Fragen immer wieder auf. Hier die wichtigsten Antworten.

Warum sind meine Logs nach einem Neustart verschwunden?

Dann speichert systemd das Journal nur flüchtig im RAM. Lege das Verzeichnis /var/log/journal an oder setze Storage=persistent in /etc/systemd/journald.conf und starte den Dienst neu. Danach überstehen die Protokolle jeden Neustart.

Wie folge ich einem Log in Echtzeit?

Mit journalctl -f siehst du neue Einträge, sobald sie entstehen. Für einen bestimmten Dienst kombinierst du es mit -u, etwa journalctl -u ssh -f. Beenden kannst du das Mitlesen jederzeit mit Strg+C.

Was ist der Unterschied zu den Dateien in /var/log?

Das Journal speichert Logs in einem strukturierten, binären Format mit Metadaten wie Dienst, Priorität und Zeit – dadurch kannst du sehr gezielt filtern. Viele Dienste schreiben zusätzlich klassische Textdateien nach /var/log. journalctl ist die zentrale, durchsuchbare Sicht auf all das.

Fazit

Mit journalctl -u, den Zeitfiltern und -p err findest du die Ursache jedes Problems in Sekunden statt Minuten. Denk daran, die Journalgröße im Zaum zu halten. Für die Logs deiner Container gilt übrigens ein eigener Mechanismus – siehe Docker Logs verwalten.