- journalctl ist das zentrale Werkzeug zur Auswertung von systemd-Logs unter Linux.
- Mit Filtern nach Zeit, Dienst und Priorität findest du Fehler schnell und gezielt.
- Die dauerhafte Speicherung des Journals verhindert Datenverlust bei Neustarts.
- JSON-Ausgabe ermöglicht die Integration in Monitoring-Systeme.
- Typische Fehler wie fehlende sudo-Rechte oder volle Logs lassen sich einfach vermeiden.
Grundlagen: Was ist journalctl und warum ist es so mächtig?
Bevor wir uns in die Tiefen der Log-Auswertung stürzen, sollten wir die fundamentalen Prinzipien verstehen. journalctl ist das Kommandozeilen-Werkzeug, um auf das Journal von systemd zuzugreifen. Dieses Journal ist eine zentrale, binäre Logging-Datenbank, die strukturierte Metadaten zu jedem Log-Eintrag speichert. (Das ist ein entscheidender Vorteil gegenüber klassischen Textdateien.)
Kurz gesagt :
- journalctl ist das zentrale Tool für systemd-Logs und bietet strukturierte Metadaten statt klassischer Textdateien.
- Filter nach Zeit (–since/–until), Dienst (-u) und Priorität (-p) ermöglichen gezielte Fehlersuche.
- JSON-Ausgabe (-o json-pretty) erlaubt die Integration in Monitoring-Systeme und Skripte.
- Dauerhafte Journal-Speicherung verhindert Datenverlust bei Neustarts; typische Fehler wie fehlende sudo-Rechte sind vermeidbar.
Der Unterschied zwischen klassischen Log-Dateien und dem Journal
Früher lagen Logs verstreut unter /var/log/ in verschiedenen Textdateien. Mit systemd wurde alles in einem Journal gebündelt. Das bietet Vorteile: strukturierte Metadaten, zuverlässige Speicherung und einfache Filterung. Sie müssen nicht mehr verschiedene Dateien durchsuchen, sondern haben alles an einem Ort.
Erste Schritte: Die Basiskommandos
Die Syntax ist einfach: journalctl [OPTIONEN]. Ohne Optionen zeigt es alle Logs an, aber Achtung: Ohne sudo sehen Sie nur Ihre eigenen Benutzer-Logs. Für System-Logs benötigen Sie root-Rechte. (Ich empfehle, sich das direkt anzugewöhnen.)
Die wichtigsten journalctl-Befehle für die tägliche Arbeit
Hier zeige ich Ihnen die Befehle, die ich täglich nutze. Sie decken 90% der Anforderungen ab.
Logs in Echtzeit verfolgen (Tail)
Mit journalctl -f verfolgen Sie Logs live. Das ist ideal, um einen Dienst beim Start zu beobachten oder Fehler in Echtzeit zu erkennen. (Ich nutze das ständig bei der Fehlersuche.)
Nach Zeit und Datum filtern
Mit –since und –until grenzen Sie den Zeitraum ein. Das ist besonders nützlich, wenn Sie wissen, wann ein Fehler aufgetreten ist.
- journalctl –since “-01-15 10:00:00”
- journalctl –since “1 hour ago”
- journalctl –since “today” –until “-01-15 12:00:00”
Nach Systemdiensten und Einheiten filtern
Der wichtigste Befehl ist journalctl -u nginx.service. Sie können ihn mit Zeitfiltern kombinieren, z.B. journalctl -u sshd –since “2 days ago”. Das grenzt die Suche enorm ein.
Logs nach Priorität und Schweregrad auswerten
Die Prioritäten reichen von 0 (emerg) bis 7 (debug). Je niedriger die Zahl, desto schwerwiegender das Ereignis. Für die Fehlersuche ist die Auswahl des richtigen Levels entscheidend.
Die Log-Level verstehen (emerg bis debug)
systemd definiert 8 Prioritäten: 0=emerg, 1=alert, 2=crit, 3=err, 4=warning, 5=notice, 6=info, 7=debug. Ich filtere meist auf err oder warning, um Rauschen zu vermeiden.
Filtern nach Fehlern und Warnungen
Mit journalctl -p err sehen Sie nur Fehler. Mit journalctl -p warning -b zeigen Sie Warnungen des letzten Boots. (Das ist Gold wert bei der Analyse von Startproblemen.)
- Identifizieren Sie die betroffene Einheit mit systemctl status <dienst>.
- Rufen Sie die Logs ab mit journalctl -u <dienst> -p err.
- Erhöhen Sie die Detailstufe bei Bedarf mit -p debug, um die Ursache zu finden.
Fortgeschrittene Filterung mit Metadaten und JSON
Jetzt wird es spannend: Sie können nach Feldern wie Prozess-ID oder Benutzer filtern. Das ist präziser als Textsuche.
Mit Feldern filtern (z.B. nach Prozess-ID oder Benutzer)
Die Syntax lautet journalctl _PID=1234 oder journalctl _UID=1000. Diese Filter nutzen die strukturierten Metadaten des Journals. (Das ist ein Riesenvorteil gegenüber grep.)
Die JSON-Ausgabe für die Skript-Integration
Mit journalctl -o json-pretty erhalten Sie die Logs als JSON. Das eignet sich perfekt für Monitoring-Tools oder zur Verarbeitung mit jq. So können Sie Logs automatisiert auswerten.
Den Boot-Verlauf im Blick behalten
Mit journalctl –list-boots sehen Sie alle vergangenen Boots. Mit journalctl -b -1 zeigen Sie die Logs vom vorherigen Boot. (Das hilft, wenn ein Problem erst nach einem Neustart auftritt.)
Den Log-Umfang verwalten und die Log-Persistenz sicherstellen
Standardmäßig speichert das Journal Logs nur im RAM (/run/log/journal), wenn der Speicher knapp ist. Das führt dazu, dass Logs bei einem Neustart verloren gehen. (Das habe ich selbst erlebt – ärgerlich!)
Warum Logs verschwinden können (und wie du das verhinderst)
Um das zu verhindern, aktivieren Sie die dauerhafte Speicherung. Das ist in drei Schritten erledigt:
- Erstellen Sie das Verzeichnis: sudo mkdir -p /var/log/journal.
- Setzen Sie die Berechtigungen: sudo chown root:systemd-journal /var/log/journal.
- Starten Sie den Dienst neu: sudo systemctl restart systemd-journald.
Speicherplatz-Limits setzen
In /etc/systemd/journald.conf können Sie mit SystemMaxUse=500M ein Limit setzen. Das ist wichtig auf Servern mit hoher Log-Aktivität, z.B. Datenbanken. Ohne Limit kann das Journal den gesamten Speicherplatz fressen.
Typische Fehler und Stolperfallen vermeiden
Hier sind die häufigsten Fehler, die ich in der Praxis sehe. Vermeiden Sie sie, sparen Sie sich viel Ärger.
Fehler 1: journalctl ohne sudo verwenden
Ohne sudo sehen Sie nur Ihre eigenen Logs. Das führt zu Verwirrung. Lösung: Immer mit sudo arbeiten, wenn Sie System-Logs benötigen. (Ich habe das am Anfang oft vergessen.)
Fehler 2: Das Journal ist voll und der Server wird langsam
Ein volles Journal kann die Performance beeinträchtigen. Lösung: Regelmäßig mit journalctl –vacuum-size=200M aufräumen oder eine Log-Rotation einrichten. (Ich habe einen Server, der ohne Limit nach 2 Wochen 10 GB Logs hatte.)
Fehler 3: Falsche Zeitangaben im Filter
Häufige Ursache ist ein falsches Datumsformat (JJJJ-MM-TT) oder fehlende Zeitzonen-Angabe. Tipp: Verwenden Sie relative Angaben wie “yesterday” oder “1 hour ago”, das ist einfacher und weniger fehleranfällig.
Häufig gestellte Fragen (FAQ)
Wie kann ich die Logs eines Dienstes seit dem letzten Neustart anzeigen?
Nutzen Sie journalctl -u <dienst> –since “today” oder besser -b (aktueller Boot). Das zeigt nur die Logs des aktuellen Boots.
Was ist der Unterschied zwischen journalctl -p err und journalctl _TRANSPORT=syslog?
Der erste filtert nach dem Schweregrad, der zweite nach der Quelle des Logs (Syslog-Transport vs. Kernel). Beide sind nützlich, aber für unterschiedliche Zwecke.
Wie exportiere ich Logs für die Weitergabe an den Support?
Verwenden Sie journalctl -b > ~/logs_$(date +%Y%m%d).txt oder journalctl -u <dienst> -o json-pretty > log.json. So haben Sie alle relevanten Daten in einer Datei.
Fazit: journalctl ist das Schweizer Taschenmesser der Log-Analyse
Mit diesen Befehlen können Sie systematisch Fehler finden und die Systemstabilität verbessern. Testen Sie die vorgestellten Befehle direkt in Ihrer Konsole und vertiefen Sie Ihr Wissen mit den Manpages (man journalctl). (Ich versichere Ihnen, es lohnt sich.)
Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …
Tous les articles de Anna Berger →
