Logs und Journal: Felder, Filter, Aufbewahrung

Nach dem Neustart, den du zur Behebung gemacht hast, sind genau die Meldungen weg, die den Ausfall erklärt hätten. Während der Störung bricht die Protokollierung für eine Minute ab, obwohl der Dienst durchlief. Und die häufigste Meldung im Journal ist fast nie die Ursache, sondern nur die, die am schnellsten wiederholt wird. Dieses Modul zeigt dir, wie das Journal wirklich funktioniert: dass ein Eintrag ein Satz benannter Felder ist statt einer Textzeile, welche davon du nicht fälschen kannst, warum Meldungen still verworfen werden — und in welcher Reihenfolge man sucht, um die Ursache statt des lautesten Symptoms zu finden.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-03

Ein Logeintrag ist keine Textzeile mehr

Früher war ein Log eine Datei mit Zeilen, und Fehlersuche hieß grep. Auf einem systemd-System ist ein Logeintrag stattdessen ein Satz benannter Felder: Text, Zeitpunkt, Priorität, welcher Prozess, welche Unit, welcher Bootvorgang. Der lesbare Text ist nur eines dieser Felder.

Das ist der Grund, warum du das Journal nicht mit grep durchsuchst, sondern mit Filtern abfragst. Nach dem Text zu suchen ist die schwächste aller Möglichkeiten — sie findet, was zufällig gleich formuliert ist, und übersieht alles andere.

journald — Der Dienst, der diese Einträge einsammelt und in einem eigenen, binären Format ablegt. Er nimmt entgegen, was Dienste auf die Standardausgabe schreiben, was über die klassische Syslog-Schnittstelle kommt und was der Kernel meldet.

Zwei Sorten Felder — und nur einer davon kannst du trauen

Die Feldnamen folgen einer Konvention, die im Betrieb wichtiger ist, als sie aussieht: Felder mit führendem Unterstrich fügt das Journal selbst hinzu, und ein Client kann sie nicht verändern. Alles ohne Unterstrich kommt von dem, der die Meldung geschrieben hat.

_SYSTEMD_UNIT: Aus welcher Unit die Meldung stammt. Vom Journal gesetzt, fälschungssicher.
_PID, _UID, _COMM: Prozessnummer, Benutzernummer und Programmname des Absenders. Ebenfalls vom Journal.
_BOOT_ID: Die Kennung des Bootvorgangs, in dem die Meldung entstand.
MESSAGE: Der lesbare Text — vom Absender geliefert und damit beliebig.
PRIORITY: Die Dringlichkeit von 0 bis 7 — ebenfalls vom Absender behauptet.

Warum das mehr als eine Feinheit istWenn du wissen willst, ob eine Meldung wirklich von einem bestimmten Dienst kommt, ist der Text darin kein Beleg — ein anderer Prozess kann denselben Text schreiben. _SYSTEMD_UNIT ist einer. Deshalb filtert man auf die Unit und liest den Text, nicht umgekehrt.

Sichtbar werden die Felder mit einer ausführlichen Ausgabe oder als JSON (-o json) — das ist auch der Weg, das Journal maschinell auszuwerten, statt Text zu zerschneiden.

Warum das Journal nach dem Reboot leer sein kann

Ein Fehlerbild, das viele einmal ratlos macht: Nach einem Neustart sind alle Meldungen von vorher weg. Das ist kein Defekt, sondern eine Voreinstellung.

Die Option Storage= in der journald-Konfiguration kennt vier Werte: volatile, persistent, auto und none. Und auto — der übliche Fall — verhält sich wie `persistent`, wenn das Verzeichnis `/var/log/journal` existiert, und sonst wie `volatile`. Existiert das Verzeichnis nicht, landet das Journal im Arbeitsspeicher und ist mit dem Neustart weg.

Die Konsequenz für die FehlersucheGenau die Meldungen, die einen Absturz oder einen fehlgeschlagenen Bootvorgang erklären würden, sind dann nicht mehr da — und zwar nach dem Neustart, den man zur Behebung gemacht hat. Auf jedem Server, dessen Störungen man später untersuchen will, gehört persistentes Journal eingerichtet, bevor die erste Störung kommt.

Ist das Journal persistent, kannst du gezielt einen früheren Bootvorgang abfragen — -b mit einem negativen Offset zeigt den vorherigen. Das ist der Standardgriff bei jedem Problem, nach dem ein Neustart stattgefunden hat.

Filtern statt lesen

Ein Journal enthält die Meldungen aller Dienste gleichzeitig. Ungefiltert ist es eine Zeitleiste des ganzen Systems — für eine Fehlersuche unbrauchbar. Vier Filter erledigen fast alles:

-u <unit>: Nur Meldungen dieser Unit. Der wichtigste Filter überhaupt.
--since / --until: Zeitfenster, auch in Klartext wie „vor 10 Minuten“.
-p <prio>: Nur ab einer Dringlichkeit — filtert das Rauschen der Informationsmeldungen weg.
-b / -b -1: Nur der aktuelle oder der vorherige Bootvorgang.
-k: Nur Kernel-Meldungen — für Hardware-, Treiber- und Dateisystemfehler.
-f: Laufend mitlesen, während man etwas auslöst.

Die Filter lassen sich kombinieren, und genau darin liegt der Nutzen: Unit plus Zeitfenster plus Mindestpriorität macht aus zehntausenden Meldungen ein Dutzend, das man tatsächlich liest.

Ein Dienst startet nach einer Änderung nicht mehr

Szenario

Um 14:07 wurde eine Konfiguration angepasst, seitdem steht die Unit auf failed. Der Statustext zeigt nur die letzten Zeilen und endet mit einem allgemeinen Exitcode.

Anforderungen

Die erste aussagekräftige Meldung finden, nicht die lauteste
Nur den betroffenen Dienst und das Änderungsfenster betrachten
Abhängigkeiten im Blick behalten, ohne im ganzen System zu suchen

Schritte

Auf die Unit und das Zeitfenster ab der Änderung eingrenzen — damit fallen alle unbeteiligten Dienste heraus.
Die Meldungen von vorne lesen, nicht von hinten: Der erste spezifische Fehler steht am Anfang, die allgemeine Abbruchmeldung am Ende.
Bleibt es unklar, die Priorität lockern — eine Warnung kurz vor dem Fehler erklärt oft mehr als der Fehler selbst.
Erst wenn der Dienst selbst nichts hergibt, dasselbe Zeitfenster ohne Unit-Filter ansehen: Dann geht es um eine Abhängigkeit, nicht um den Dienst.

Merksatz: Die letzte Meldung ist die Folge, die erste die Ursache. Wer von hinten liest, findet zuverlässig das Symptom.

Die Prioritätsskala, die niemand auswendig kann

0–2 · emerg, alert, crit: Etwas ist kaputt oder gleich kaputt. Hier fängt jede Suche an.
3 · err: Ein konkreter Fehler. Der häufigste sinnvolle Einstiegsfilter.
4 · warning: Etwas ist auffällig, aber noch nicht gescheitert — oft die eigentliche Erklärung.
5–7 · notice, info, debug: Normalbetrieb. Nützlich, wenn man den Ablauf nachvollziehen will, sonst Rauschen.

Ein Filter auf eine Priorität zeigt immer diese und alles Dringendere. Der Einstieg ist deshalb meistens err, und wenn dort nichts steht, lockert man auf warning.

Die Grenze dieser SkalaDie Priorität behauptet der Absender. Manche Programme melden echte Fehler als Information, andere schreiben Routinemeldungen als Warnung. Ein Prioritätsfilter ist ein guter erster Schnitt, aber kein Beweis, dass es nichts gab — bei einer ergebnislosen Suche gehört er gelockert.

Die Meldungen, die du nie zu sehen bekommst

Das ist der unangenehmste Teil dieses Moduls, weil er still passiert. journald begrenzt, wie viel ein einzelner Dienst in kurzer Zeit protokollieren darf.

Die Regel steht in der Dokumentation unmissverständlich: Werden in dem durch RateLimitIntervalSec= festgelegten Zeitraum mehr Meldungen als in RateLimitBurst= erlaubt geschrieben, werden alle weiteren Meldungen bis zum Ende des Intervalls verworfen. Die Voreinstellung liegt bei 10.000 Meldungen in 30 Sekunden.

Warum das genau im Ernstfall zuschlägtEin Dienst, der in eine Fehlerschleife läuft, protokolliert um Größenordnungen mehr als im Normalbetrieb — und überschreitet die Grenze genau dann, wenn die Meldungen am wertvollsten wären. Das Journal vermerkt die Zahl der verworfenen Meldungen; wer diesen Hinweis übersieht, hält eine Lücke für Ruhe.

Kurzcheck

Während eines Ausfalls bricht die Protokollierung eines Dienstes für rund eine Minute ab und setzt danach wieder ein. Der Dienst lief durchgehend. Was ist die naheliegendste Erklärung?

Die Ratenbegrenzung hat gegriffen — der Dienst hat zu viele Meldungen in zu kurzer Zeit geschrieben.
Das Journal war voll und hat ältere Einträge gelöscht, um Platz für neue zu schaffen.
Die Systemuhr wurde während des Ausfalls korrigiert, dadurch liegen die Einträge außerhalb des abgefragten Fensters.

Treffer. Genau. Über der Grenze werden alle weiteren Meldungen bis zum Ende des Intervalls verworfen. Das Journal hält die Zahl der verworfenen Einträge fest — dieser Hinweis ist der Beleg.

Wie viel Platz das Journal nehmen darf

Ein persistentes Journal wächst. Wie weit, steuert SystemMaxUse= — die Obergrenze für den Platz, den die Journaldateien belegen dürfen. Den aktuellen Verbrauch fragst du direkt ab, statt ihn im Dateisystem zu suchen.

Zum Aufräumen gibt es zwei Wege, die beide nur archivierte Dateien anfassen: nach Größe (die ältesten entfernen, bis der Platz unter einen Wert fällt) oder nach Alter (alles älter als eine Zeitspanne entfernen). Das ist auch der Grund, warum der tatsächliche Verbrauch nach dem Aufräumen über der eingestellten Grenze liegen kann — die gerade beschriebene Datei bleibt.

Was du nicht tun solltestJournaldateien von Hand zu löschen, während journald läuft, ist der schlechteste Weg zu freiem Platz: Der Dienst hält die Datei offen, der Platz kommt gar nicht zurück, und die Struktur des Journals kann Schaden nehmen. Für dasselbe Ziel gibt es die vorgesehenen Aufräumbefehle.

Für Dienste, die weiterhin eigene Textdateien schreiben, gilt eine andere Mechanik: Dort rotiert ein separates Werkzeug die Dateien nach Größe oder Alter und teilt dem Dienst mit, dass er neu öffnen soll. Beides existiert auf denselben Systemen nebeneinander — wer nur an das Journal denkt, übersieht die Hälfte des belegten Platzes.

Wie eine Meldung überhaupt ins Journal kommt

Ein Dienst unter systemd muss sich nicht um Logdateien kümmern: Was er auf die Standardausgabe und die Standardfehlerausgabe schreibt, landet ohne Zutun im Journal, versehen mit Unit, Prozessnummer und Zeitstempel. Das ist der einfachste und robusteste Weg — und der Grund, warum moderne Dienste oft gar keine eigene Logdatei mehr anlegen.

Daneben existieren zwei ältere Wege weiter. Manche Programme schreiben über die klassische Syslog-Schnittstelle, andere legen weiterhin eigene Textdateien unter /var/log an — typischerweise Webserver und Datenbanken, die ihr eigenes Format brauchen.

Standardausgabe des Dienstes: Landet automatisch im Journal, mit allen vertrauenswürdigen Feldern. Der Normalfall unter systemd.
Syslog-Schnittstelle: Der klassische Weg. journald nimmt diese Meldungen ebenfalls entgegen.
Eigene Datei unter `/var/log`: Am Journal vorbei. Braucht eine eigene Rotation und taucht in keiner journalctl-Abfrage auf.

Die praktische FalleAuf demselben Server existieren fast immer beide Welten. Wer bei einer Störung nur das Journal durchsucht, übersieht die Anwendung, die ihre Fehler in eine eigene Datei schreibt — und umgekehrt. Zur Fehlersuche gehört deshalb die Frage, wohin dieser konkrete Dienst überhaupt protokolliert, bevor man anfängt zu filtern.

Zeitstempel: die Voraussetzung für jede Korrelation

Sobald mehr als ein System beteiligt ist, hängt jede Auswertung an einer Annahme: dass die Uhren übereinstimmen. Ist die Zeit auf einem Host um zwei Minuten versetzt, erscheint seine Ursache nach ihrer Wirkung auf dem anderen — und die Kette wird falsch herum gelesen.

Deshalb sind zwei Dinge Voraussetzung, bevor man Logs mehrerer Systeme nebeneinanderlegt: synchronisierte Uhren und eine gemeinsame Zeitbasis in der Darstellung. Das Journal zeigt Zeitstempel standardmäßig in lokaler Zeit; für den Vergleich über Hosts hinweg ist eine Anzeige in UTC die verlässlichere Wahl.

Woran man einen Zeitsprung erkenntWenn Einträge in der Ausgabe scheinbar rückwärts laufen oder eine Lücke von exakt der Größe einer Zeitkorrektur klafft, hat die Uhr gestellt — nicht der Dienst geschwiegen. Das ist die dritte Ursache für scheinbar fehlende Meldungen, neben flüchtiger Ablage und Ratenbegrenzung.

Ursache oder Folge? Die Reihenfolge entscheidet

Ein Ausfall erzeugt eine Kette: Etwas geht kaputt, ein Schutzmechanismus reagiert, ein Dienst weiter vorne meldet einen Fehler, und ganz am Ende sieht ein Nutzer eine unspezifische Fehlerseite. Alle vier stehen im Journal, und die letzte ist die lauteste.

Deshalb ist die zeitliche Ordnung das eigentliche Werkzeug. Der erste spezifische Fehler im betroffenen Zeitfenster grenzt den Untersuchungsort ein; alles danach ist meistens Folge. Wer bei der letzten Meldung anfängt, behandelt zuverlässig das Symptom.

Häufigkeit ist kein KausalitätsnachweisDie häufigste Meldung im Journal ist fast nie die Ursache — sie ist die, die am schnellsten wiederholt wird. Eine einzelne Meldung kurz vor dem Beginn des Ausfalls trägt mehr Information als zehntausend gleichlautende danach.

Eine typische Kette sieht so aus: Ein Zertifikat läuft ab. Die Datenbankverbindung wird abgelehnt. Der Anwendungsserver läuft in ein Zeitlimit und wirft Verbindungsfehler — im Sekundentakt. Der Reverse Proxy davor antwortet mit einem allgemeinen Serverfehler. Vier Ebenen, und die Meldung, die man zuerst sieht, ist die letzte.

Nach Häufigkeit sortiert gewinnt hier die dritte Ebene mit Abstand — die eigentliche Ursache steht ein einziges Mal ganz am Anfang. Deshalb ist die erste Frage bei jedem Ausfall nicht „was steht am häufigsten da“, sondern „wann genau fing es an, und was war die erste ungewöhnliche Meldung davor“.

Praktisch heißt das: Das Zeitfenster wird bewusst vor dem gemeldeten Beginn aufgemacht. Wer erst ab dem Zeitpunkt sucht, an dem die Nutzer etwas gemerkt haben, hat den Anfang der Kette bereits abgeschnitten.

Wenn das Log den Host verlassen muss

Ein Journal auf dem Host beantwortet Fragen über diesen Host. Zwei Fälle sprengen das: Ein Ausfall betrifft mehrere Systeme, oder der Host selbst ist nicht mehr erreichbar — und dann sind auch seine Logs weg.

Für beides werden Meldungen an ein zentrales Ziel weitergeleitet. Das ist keine reine Bequemlichkeit: Bei einem Sicherheitsvorfall ist ein Log, das nur auf dem betroffenen System liegt, im Zweifel von genau der Person manipulierbar, deren Handeln es belegen soll. Eine Kopie außerhalb ist die einzige, auf die man sich stützen kann.

Der PreisZentrale Protokollierung ist eine eigene Infrastruktur mit eigener Kapazitäts-, Aufbewahrungs- und Datenschutzfrage — und mit einem Ausfallverhalten, das mitbedacht sein will. Für viele Systeme ist ein persistentes lokales Journal mit vernünftiger Obergrenze der ehrlichere erste Schritt.

Wenn weitergeleitet wird, stellt sich sofort die nächste Frage: was verlässt den Host. Alles zu senden ist teuer und erzeugt an anderer Stelle dasselbe Rauschproblem; nur Fehler zu senden verliert genau die Warnung, die den Fehler erklärt hätte. Die brauchbare Mitte ist meistens, nach Dienst zu entscheiden statt nach Priorität — von den wenigen wichtigen Diensten alles, vom Rest die höheren Stufen.

Ein zweiter Punkt betrifft den Inhalt. Logs enthalten regelmäßig personenbezogene Daten — Benutzernamen, IP-Adressen, manchmal ganze Anfragen. Sobald sie den Host verlassen und zentral aufbewahrt werden, wird aus einer technischen Entscheidung eine mit Aufbewahrungsfrist und Zugriffsregelung. Das ist kein Grund, es nicht zu tun; es ist ein Grund, die Frist vorher festzulegen statt Jahre später beim Aufräumen.

Und schließlich: Ein zentrales Ziel ist selbst ein System, das ausfallen kann. Wie sich die Weiterleitung verhält, wenn das Ziel nicht erreichbar ist — puffern, verwerfen oder den schreibenden Dienst blockieren —, gehört zu den Eigenschaften, die man kennt, bevor man sich darauf verlässt.

Die Reihenfolge bei einer Logsuche

Zeitfenster festlegen — wann fing es an, wann hörte es auf→Auf die betroffene Unit eingrenzen und von vorne lesen→Priorität als Schnitt benutzen, bei Ergebnislosigkeit lockern→Auf verworfene Meldungen achten, bevor du eine Lücke für Ruhe hältst→Erst danach die Abhängigkeiten im selben Fenster ansehen

Was du mitnehmen solltestVier Sätze tragen dieses Modul. Ein Eintrag ist ein Satz Felder — filtere auf die vertrauenswürdigen, lies den Text. Ohne `/var/log/journal` ist nach dem Reboot alles weg — und zwar genau das, was du dann brauchst. Über der Ratengrenze wird verworfen — eine Lücke ist keine Ruhe. Und die erste Meldung ist die Ursache, die letzte nur die lauteste.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität6 Primärquellen · zuletzt geprüft: 2026-09-03