Systemd-Logs mit Journalctl anzeigen und manipulieren

System- und Prozessprotokollierung sind nur zwei der wichtigsten Vorteile von systemd. Wenn Protokolle im gesamten System verstreut sind, sich über mehrere Anwendungen erstrecken und von verschiedenen Prozessen und Daemons verarbeitet werden, kann ihre Interpretation eine Herausforderung sein. Systemd bietet eine zentralisierte Lösung für die Verwaltung aller Kernel- und Userland-Prozessprotokolle in einem Sammelmedium, das als Journal bekannt ist. Mehr über systemd erfahren Sie in unserem Tutorial zur Verwaltung von systemd-Diensten und -Units mit systemctl. Alle von Diensten, initrd, Kerneln usw. in einem Journal erzeugten Meldungen werden vom Journal-Daemon verarbeitet. Der Zweck dieses Leitfadens ist es zu veranschaulichen, wie Sie mithilfe von journalctl auf die Daten des Journals zugreifen und diese manipulieren können.

Grundprinzip

Unabhängig davon, woher eine Meldung stammt, besteht eines der Hauptziele von systemd darin, deren Verwaltung zu zentralisieren. Da viele der Boot-Prozesse und ein Großteil der Dienstverwaltung vom systemd-Prozess übernommen werden, sollte die Art und Weise, wie die Protokolle zusammengestellt und aufgerufen werden, standardisiert werden. Journald sammelt Daten aus allen verfügbaren Quellen in einem allumfassenden Tool und speichert sie in einem Binärformat. Dadurch sind die Daten für eine dynamische und einfache Bearbeitung leicht verfügbar.

Dieser Ansatz bietet mehrere entscheidende Vorteile. Durch einen zentralen Ort zum Sammeln aller Daten können Administratoren filtern und nur die Daten anzeigen, die sie benötigen. Beispielsweise kann man Boot-Daten von vor drei Systemstarts anzeigen. Es könnte auch die sequenzielle Protokollierung von Einträgen verwandter Dienste bedeuten und ein Kommunikationsproblem zwischen ihnen effektiver aufspüren.

Dank der binären Speicherung können Daten je nach den aktuellen Anforderungen des Benutzers in einer Vielzahl von Ausgabeformaten angezeigt werden. Beispielsweise kann ein tägliches Protokoll in einem Standard-syslog-Format angezeigt werden. Wenn Sie jedoch Dienstunterbrechungen in Form eines Diagramms darstellen möchten, kann der Eintrag als JSON-Objekt ausgegeben werden, wodurch es mit einem Diagrammdienst kompatibel ist. Wenn Sie Formate je nach situativen Anforderungen ändern müssen, ist keine Konvertierung erforderlich, da die Daten binär sind und nicht als Klartext auf die Festplatte geschrieben werden.

Je nach Bedarf können Sie das systemd-Journal mit einem vorhandenen Syslog implementieren oder es kann dessen Funktionalität ersetzen. Systemd kann sogar bestehende Protokollierungsmechanismen ergänzen. Beispielsweise können bei mehreren Diensten auf einem einzigen System deren zusammengestellte Daten mit dem systemd-Journal auf einem einzigen System miteinander verflochten werden.

Einstellen der Systemzeit

Systemd zeigt die Ergebnisse standardmäßig in der Ortszeit an, ein Vorteil der binären Journalprotokollierung bei der Anzeige von Protokolleinträgen. Alternativ können sie in UTC angezeigt werden. Daher ist es wichtig, sicherzustellen, dass die Zeitzone korrekt eingerichtet ist, bevor Sie mit der Journalprotokollierung beginnen. Zu diesem Zweck ist systemd mit einem Tool namens timedatectl ausgestattet. Wir beginnen damit, uns anzusehen, welche Zeitzonen zur Verfügung stehen, indem wir eine Liste mit den Optionen list-timezones anzeigen:

Nachdem Sie die passende Zeitzone für den Standort Ihres Servers gefunden haben, kann die Zeitzone mit der Option set-timezone eingestellt werden:

Um zu testen und zu überprüfen, ob die Zeitzone nun korrekt angezeigt wird, können Sie den Befehl timedatectl entweder allein oder unter Hinzufügung von „status:“ verwenden

Die erste Zeile stellt die Ortszeit dar. Diese Zeile sollte die korrekte Uhrzeit für Ihre lokale Region enthalten.

Allgemeine Protokollanzeige

Der Befehl journalctl ermöglicht es Ihnen, die vom journald-Daemon gesammelten Protokolle anzuzeigen. Wenn Sie journalctl verwenden, wird jeder Journaleintrag des Systems auf der Bildschirmseite angezeigt, wobei die ältesten Einträge weiter oben aufgeführt sind. Die vollständige Datenliste wird jedoch Zehntausende von Zeilen lang sein.

Wer die Standard-Syslog-Protokollierung verwendet hat, dem wird das Format vertraut vorkommen, aber es ist wichtig zu bedenken, dass diese Datensammlung im Gegensatz zur Syslog-Methode aus vielen Quellen stammt. Die Protokolle enthalten den frühen Boot-Prozess, die initrd und den Kernel sowie Standardfehler von Anwendungen.

Da nun die Ortszeit eingestellt ist, beginnen alle Einträge mit Zeitstempeln in Ortszeit. Dies ist für jedes derzeit auf dem System gespeicherte Protokoll verfügbar, wobei die gesamte Logik unter Verwendung dieser neuen Informationen angezeigt wird. Sie sind jedoch nicht auf die Ortszeit beschränkt. Mit dem Flag –utc können Sie Zeitstempel auch in UTC anzeigen lassen:

Journal-Filterung nach Zeit

So viele Daten zur Verfügung zu haben, ist fantastisch, aber sie zu durchkämmen und aufzunehmen, ganz zu schweigen von der mentalen Verarbeitung, kann eine entmutigende Aufgabe sein. Vor diesem Hintergrund kommen wir zum wichtigsten Teil der journalctl-Funktion: dem Filtern.

Anzeige der Protokolle des aktuellen Systemstarts

Wenn Sie nach den Daten im Journal vom letzten Neustart suchen, können Sie die journalctl-Funktion mit dem Flag -b verwenden. Dadurch werden alle relevanten Protokollinformationen vom letzten Neustart Ihres Systems angezeigt. Dieser Befehl ermöglicht es Ihnen, die für die aktuelle Arbeitsumgebung relevantesten Informationen zu finden und zu verwalten:

Wenn der Betrachter sich dafür entscheidet, nicht jeden einzelnen Eintrag auszuwerten, zeigt journalctl mehr als einen Tag an Systemstarts an, die in journalctl mit praktischen „Reboot“-Trennzeichen dargestellt werden. Dies hilft, Informationen aus verschiedenen Boot-Sitzungen zur Überprüfung logisch zu trennen:

Informationen zu vergangenen Systemstarts

Während die Anzeige von Informationen zum aktuellen Systemstart meist am nützlichsten ist, gibt es Situationen, in denen Informationen zu vergangenen Systemstarts hilfreich sein können. Das Journal speichert Informationen für mehrere vorherige Systemstarts, sodass journalctl die Informationen für jeden beliebigen Zeitraum problemlos anzeigen kann.

Einige Distributionen deaktivieren das Speichern von Informationen früherer Systemstarts, während andere es standardmäßig aktiviert haben. Die Aktivierung der persistenten Boot-Informationen kann durch Erstellen eines Verzeichnisses zur Speicherung des Journals durch Eingabe des Folgenden erreicht werden:

Alternativ können Sie die Journal-Konfigurationsdatei wie folgt bearbeiten:

Das Setzen der Option Storage= auf „persistent“ im Abschnitt [Journal] aktiviert die persistente Protokollierung:

Sobald dies aktiviert ist, journalctl stellt bestimmte Befehle zur Verfügung, mit denen Sie diese Systemstarts als Einteilungseinheiten festlegen können. Um die in journald aufgezeichneten Systemstarts anzuzeigen, können Sie die Option –list-boots über journalctl verwenden:

Wie dargestellt, wird jeder Systemstart in einer eigenen Zeile aufgeführt, wobei die erste Spalte die vorherigen Systemstarts in der Reihenfolge vom ältesten zum neuesten wiedergibt. Wenn eine absolutere Referenz benötigt wird, enthält die zweite Spalte die Boot-Identifikation. Danach sind zwei Zeitangaben aufgeführt. Informationen aus der ersten oder zweiten Spalte können verwendet werden, um die Journal-Informationen des spezifischen Systemstarts anzuzeigen. Beispielsweise können Sie das Flag -b mit dem relativen Boot-Zeiger -1 verwenden, um Informationen zum vorletzten Neustart anzuzeigen:

Ebenso kann die Boot-ID aus der zweiten Spalte auf diese Weise verwendet werden:

Zeitfenster

Das Anzeigen von Systemstarts nach ID ist eine Option, aber oft ist es nützlicher, sich auf frühere Systemstarts über ein Zeitfenster in der Vergangenheit beziehen zu können, das nicht unbedingt mit bestimmten Systemstarts übereinstimmen muss. Dies ist beispielsweise in einer Situation relevant, in der man mit lang laufenden Servern arbeitet, die nicht häufig neu gestartet werden. Die Filterung von Zeitgrenzen kann mit beliebigen Zeitgrenzen erfolgen. Dadurch werden nur Informationen über die Neustarts angezeigt, die in ein bestimmtes Zeitfenster fallen. Die Parameter dieses Fensters werden mit den Optionen –since und –until festgelegt. Für Zeitoptionen stehen verschiedene Formate zur Verfügung. Das Format für den absoluten Zeitwert lautet wie folgt:

Wenn Sie also alle Systemstarts seit dem 10. Januar 2015 um 17:15 Uhr sehen möchten, geben Sie folgenden Befehl ein:

Wenn eine der Komponenten weggelassen wird, gibt es integrierte Standardwerte. Wenn ein Datum weggelassen wird, wird standardmäßig das aktuelle Datum verwendet. Wenn die Zeitkomponente fehlt, ist Mitternacht der Standardwert (00:00:00). Wenn Sie die Sekunden bei der Zeitkomponente weglassen, werden sie standardmäßig auf den Anfang dieser Minute (00) gesetzt:

Das Journal kann zeitbezogene Kürzel wie „today“, „tomorrow“, „yesterday“ und „now“ verstehen. Wörter wie „ago“ in Verbindung mit vorangestellten Qualifikatoren „-“ und „+“ können verwendet werden, um einen satzartigen Befehl zu konstruieren:

Wenn Sie über eine Dienstunterbrechung informiert wurden, die um 9:00 Uhr begann, und die Journal-Protokolle bis vor einer Stunde überprüfen möchten, können Sie dies wie folgt tun:

Wie man sieht, ist das Definieren eines flexiblen Zeitfensters zur Anzeige der gewünschten Einträge sehr einfach.

Nach Nachrichteninteresse filtern

Abgesehen von der Filterung des Journals nach zeitlichen Einschränkungen können die Daten auch basierend auf der interessierenden Dienstkomponente gefiltert werden. Systemd bietet hierfür verschiedene Methoden an.

Nach Unit

Der wohl nützlichste Filterparameter ist der nach der gewünschten Unit. Um nach einer Unit zu filtern, kann die Option -u genutzt werden. Wenn Sie beispielsweise alle Protokolle sehen möchten, die die Nginx-Unit betreffen, geben Sie folgenden Befehl ein:

Realistischerweise würden Sie dies mit einem Zeitfilter kombinieren wollen, um die relevanten Zeilen anzuzeigen. Wenn Sie den obigen Dienst überprüfen möchten und sehen wollen, wie er heute gelaufen ist, können Sie Folgendes tun:

Dies ist besonders nützlich, wenn Sie die Fähigkeit des Journals nutzen, Datensätze aus mehreren Units zusammenzuführen, insbesondere aus solchen, die zusammenarbeiten. Wenn der Nginx-Prozess mit einer PHP-FPN-Unit für die dynamische Inhaltsverarbeitung verbunden ist, können die Einträge in chronologischer Reihenfolge zusammengeführt werden, indem beide Units angegeben werden:

Dies kann die Erfassung von Programminteraktionen erheblich erleichtern und das Debuggen von Systemen anstelle von einzelnen Prozessen vereinfachen.

Nach Gruppen-ID, Prozess oder Benutzer

Viele Dienste starten eine Vielzahl von Unterprozessen (Child-Prozessen), um bestimmte Aufgaben auszuführen. Wenn die ID eines bestimmten Prozesses bekannt ist, kann auch durch Angabe des Feldes _PID gefiltert werden. Wenn die gesuchte PID 8088 lautet, kann Folgendes getan werden:

Möglicherweise möchten Sie auch Einträge sehen, die von einer bestimmten Gruppe oder einem bestimmten Benutzer protokolliert wurden. Dies kann mithilfe der Filter _GID und _UID erreicht werden. Wenn ein Webserver unter dem Benutzer www-data läuft, kann Folgendes die erforderliche ID ermitteln:

Mit dieser ID können Sie dann die qualifizierten Journal-Ergebnisse anzeigen:

Systemd stellt viele Felder für Filterzwecke zur Verfügung. Einige Felder werden von journald basierend auf Informationen angewendet, die zum Zeitpunkt der Protokollierung vom System erfasst wurden, während andere von dem aktuell protokollierten Prozess übergeben werden.

Ein Präfix von _PID zeigt an, dass die Informationen zum Zeitpunkt der Protokollierung vom System erfasst wurden. Das Journal zeichnet die PID während des Protokollierungsprozesses automatisch auf und indiziert sie, um die Filterfunktion später verfügbar zu machen. Um mehr über die verfügbaren Journal-Felder zu erfahren, können Sie Folgendes eingeben:

Wir werden einige davon später in dieser Anleitung besprechen, aber für den Moment werden wir auf einige andere nützliche Optionen eingehen, die sich auf diese Felder beziehen. Wenn Sie alle verfügbaren Werte für ein bestimmtes Journal-Feld sehen möchten, können Sie die Option -F verwenden. Wenn Sie sehen möchten, was das systemd-Journal für Gruppen-IDs enthält, können Sie Folgendes tun:

Dies kann bei der Erstellung von Filtern helfen, indem eine vollständige Liste der Werte bereitgestellt wird, die das Journal-Gruppen-ID-Feld gespeichert hat.

Nach Pfad der Komponente

Das Filtern kann auch durch Angabe eines Pfads erfolgen. Wenn der Pfad zu einer ausführbaren Datei führt, werden Einträge in journalctl angezeigt, wenn sie diese ausführbare Datei betreffen. Wenn die betreffende ausführbare Datei „bash“ ist, können Sie Folgendes eingeben:

Auch wenn dies manchmal nicht möglich ist, kann es, wenn die Unit der ausführbaren Datei verfügbar ist, eine klarere und informativere Methode zum Filtern bieten.

Kernel-Meldungen anzeigen

Die Kernel-Meldungen, die normalerweise in der dmesg-Ausgabe zu finden sind, können auch aus dem Journal abgerufen werden. Um nur diese Meldungen anzuzeigen, verwenden wir entweder die Flags -k oder -dmesg als Teil unseres Befehls:

Meldungen des aktuellen Systemstarts werden standardmäßig angezeigt, aber frühere Systemstarts können wie zuvor beschrieben über die Auswahl-Flags angegeben werden. Wenn Sie nach Meldungen von vor fünf Systemstarts suchen, liefert Ihnen die Eingabe von Folgendem die gewünschten Ergebnisse:

Nach Priorität

Systemadministratoren bevorzugen oft das Filtern nach Priorität. Protokolle mit niedriger Priorität sind zwar oft nützlich anzusehen, können aber verwirrend sein und viele Ablenkungen enthalten, was sie bei der Analyse schwerer verdaulich macht. Die Verwendung der Option -p in journalctl zeigt nur Meldungen einer bestimmten Priorität an und filtert alle anderen Prioritäten heraus. Wenn Sie Einträge ab der Fehlerstufe (error) oder höher anzeigen möchten, geben Sie Folgendes ein:

Dieser Befehl gibt alle Meldungen zurück, die als Fehler (error), Alarm (alert), Notfall (emergency) oder kritisch (critical) eingestuft sind, wobei das Journal die Standard-Syslog-Meldungsstufen verwendet. Die Prioritätsstufen sind nach einem numerischen Wert definiert, der von der höchsten zur niedrigsten Stufe geordnet ist:

• 0: emerg
• 1: alert
• 2: crit
• 3: err
• 4: warning
• 5: notice
• 6: info
• 7: debug

Jede der oben genannten Optionen kann austauschbar mit der Option -p verwendet werden. Die Auswahl einer der oben beschriebenen Prioritäten filtert alle Prioritäten auf dieser Stufe und darüber.

Modifizieren der Anzeige im Journal

Neben der Verwendung von Filtern zur Auswahl von Einträgen haben wir andere Methoden zur Modifizierung der Ausgabe, um die Anzeige von journalctl an unsere Bedürfnisse anzupassen.

Ausgabe kürzen/erweitern

Wir können die Ansicht unserer Ausgabe anpassen, indem wir einstellen, ob journalctl die Daten verkleinert oder erweitert. Standardmäßig zeigt journalctl den vollständigen Eintrag an, wobei längere Einträge nach rechts aus dem Bildschirm herausragen. Sie können die Einträge in ihrer Gesamtheit anzeigen, indem Sie mit der rechten Pfeiltaste scrollen. Ein Benutzer möchte die Ausgabe stattdessen möglicherweise kürzen, wobei Auslassungspunkte auf den Zeilen angezeigt werden, die andernfalls über den Bildschirmrand hinausgehen würden. Hierfür kann die Option –no-full verwendet werden:

Alternativ können Sie mit dem Flag -a auch festlegen, dass alles angezeigt wird, unabhängig von der Länge oder dem Vorhandensein nicht druckbarer Zeichen:

Ausgabe in die Standardausgabe

Journalctl zeigt die Ausgabe standardmäßig in einem Pager an. Wenn Sie die Daten jedoch mit Textbearbeitungswerkzeugen manipulieren möchten, benötigen Sie wahrscheinlich die Ausgabe auf der Standardausgabe. Dies können Sie mit der Option –no-pager erreichen:

Je nach den Anforderungen des Benutzers kann dies in eine Datei auf der Festplatte oder an ein Verarbeitungsprogramm umgeleitet werden.

Ausgabeformate

Daten lassen sich immer einfacher parsen, wenn sie in einem besser konsumierbaren Format dargestellt werden. Das Journal bietet mehrere Optionen für die Anzeige unter Verwendung des Qualifizierers -o, gefolgt von einem speziell angegebenen Format.

Wenn Sie die Journaleinträge in einem JSON-Format ausgeben möchten, können Sie dies auf folgende Weise tun:

Diese Strategie ist besonders nützlich für Parsing-Dienstprogramme. Das Format json-pretty kann die Datenstrukturen besser darstellen, bevor Sie sie an den JSON-Consumer übergeben:

Es gibt mehrere Formate, die Sie für die Anzeige nutzen können:

• cat: Zeigt nur das Nachrichtenfeld selbst an.
• export: Ein Binärformat, das sich zum Übertragen oder Sichern eignet.
• json: Standard-JSON mit einem Eintrag pro Zeile.
• json-pretty: JSON-formatiert für bessere menschliche Lesbarkeit
• json-sse: JSON-formatierte Ausgabe, verpackt, um sie mit Server-Sent Events kompatibel zu machen
• short: Die Standardausgabe im syslog-Stil
• short-iso: Das Standardformat, erweitert um die Anzeige von ISO-8601-Echtzeit-Zeitstempeln.
• short-monotonic: Das Standardformat mit monotonen Zeitstempeln.
• short-precise: Das Standardformat mit Mikrosekundenpräzision
• verbose: Zeigt jedes für den Eintrag verfügbare Journalfeld an, einschließlich derer, die normalerweise intern ausgeblendet sind.

Die oben genannten Optionen ermöglichen es, das Journal in Ihrem bevorzugten Format anzuzeigen.

Aktive Prozessüberwachung

Das Journal ermöglicht den Zugriff auf Funktionen zur Überwachung aktiver oder kürzlicher Aktivitäten, ohne dass ein anderes Tool beteiligt sein muss. Sie können dies mit dem Befehl journalctl mit einer „tail“-Funktion tun.

• Anzeigen der neuesten Protokolle

Die Anzeige der Option -n (die genau wie der Befehl tail -n funktioniert) ermöglicht die Anzeige einer bestimmten Anzahl von Datensätzen:

Die Anzahl der Einträge, die Sie anzeigen lassen möchten, kann mit einer bestimmten Zahl nach dem Qualifizierer -n angegeben werden:

• Verfolgen der Protokolle

Sie können die Protokolle auch aktiv verfolgen, während sie mit dem Flag -f in das System geschrieben werden. Dies funktioniert ebenfalls auf dieselbe Weise wie der Befehl tail -f:

Journal-Wartung

Protokolle belegen Speicherplatz. Es lohnt sich, dies zu untersuchen, um möglicherweise einige der älteren Protokolle zu löschen und Speicherplatz freizugeben.

Aktuelle Festplattenbelegung ermitteln

Das Flag –disk-usage kann helfen zu ermitteln, wie viel Speicherplatz die Protokollierung derzeit auf der Festplatte belegt:

Alte Protokolle löschen

Mit systemd Version 218 (und nachfolgenden Versionen) können Sie das Journal auf zwei verschiedene Arten verkleinern. Eine davon ist die Option –vacuum-size. Diese kann das Journal verkleinern, indem sie dessen Größe angibt. Mit anderen Worten: Ältere Einträge werden so lange aus dem Protokoll gelöscht, bis der belegte Speicherplatz dem angeforderten Parameter entspricht:

Die Option –vacuum-time kann den belegten Speicherplatz des Journals verringern, indem sie einen Grenzzeitpunkt angibt. Alle Einträge, die darüber hinausgehen, werden gelöscht, während die nach dem angegebenen Zeitpunkt erstellten Einträge beibehalten werden. Wenn Sie nur die Einträge des letzten Kalenderjahres behalten möchten, können Sie Folgendes verwenden:

Journal-Wachstum begrenzen

Sie können auch den Speicherplatz begrenzen, den das Journal belegt. Dies wird durch Bearbeiten der Datei /etc/systemd.journald.conf erreicht. Das Journal-Wachstum kann mit einer der folgenden Methoden begrenzt werden:

• SystemMaxUse=: Bezeichnet den maximalen Festplattenspeicher, den das Journal im persistenten Speicher belegen darf.
• SystemKeepFree=: Bezeichnet, wie viel Speicherplatz frei bleiben soll, wenn die Journal-Entitäten im persistenten Speicher hinzugefügt werden.
• SystemMaxFileSize=: Bestimmt, wie groß die Journal-Dateien anwachsen dürfen, bis eine Rotation im persistenten Speicher stattfindet.
• RuntimeMaxUse=: Bestimmt, wie viel Speicherplatz im flüchtigen Speicher (innerhalb des /run-Dateisystems) belegt werden darf.
• RuntimeKeepFree=: Beim Schreiben von Daten in den flüchtigen Speicher gibt diese Funktion an, wie viel Speicherplatz für andere Zwecke reserviert bleiben muss (innerhalb des /run-Dateisystems).
• RuntimeMaxFileSize=: Gibt an, wie viel Speicherplatz ein einzelnes Protokolljournal im flüchtigen Speicher (innerhalb des /run-Dateisystems) belegen darf, bevor es rotiert werden muss.

Diese Optionen können alle dazu beitragen, den Speicherverbrauch des Journals zu kontrollieren. Ein wichtiger Aspekt ist, dass sich die Optionen SystemMaxFileSize und RuntimeMaxFileSize auf archivierte Dateien beziehen, um die angegebenen Grenzwerte zu erreichen. Dies sollte man bei der Interpretation der Anzahl der Dateien nach Vacuuming-Operationen im Hinterkopf behalten.

Fazit

Es ist offensichtlich, dass das systemd-Journal ein unglaublich nützliches Werkzeug ist, dessen Vorteile größtenteils auf der zentralisierten Natur der Protokolle und der großen Menge an aufgezeichneten Metadaten beruhen. Die umfangreichen Funktionen des Journals können durch die Nutzung des Befehls journalctl ausgeschöpft werden, was eine einfachere Methode zur Durchführung von relationalem Debugging von Anwendungskomponenten sowie eine umfassende Systemanalyse ermöglicht.

Viel Spaß beim Computing!