So verwenden Sie Journalctl, um Systemd-Protokolle anzuzeigen und zu bearbeiten

Einführung

Einige der überzeugendsten Vorteile von systemd betreffen das Prozess- und System-Logging. Bei der Verwendung anderer Werkzeuge sind die Logs in der Regel über das System verteilt, werden von verschiedenen Daemons und Prozessen verwaltet und können ziemlich schwer zu interpretieren sein, wenn sie mehrere Anwendungen umfassen. systemd versucht, diese Probleme zu lösen, indem es eine zentrale Verwaltungslösung für das Logging aller Kernel- und Userland-Prozesse bereitstellt. Das System, das diese Logs sammelt und verwaltet, ist als Journal bekannt.

Das Journal wird mit dem journald-Daemon implementiert, der alle vom Kernel, initrd, Diensten usw. erzeugten Nachrichten verarbeitet. In diesem Leitfaden werden wir besprechen, wie man das journalctl-Dienstprogramm verwendet, das zum Zugreifen auf und Manipulieren der im Journal enthaltenen Daten genutzt werden kann.

Allgemeine Idee

Einer der Antriebe hinter dem systemd-Journal ist es, die Verwaltung von Protokollen zu zentralisieren, unabhängig davon, wo die Nachrichten herkommen. Da ein großer Teil des Bootvorgangs und der Dienstverwaltung vom systemd-Prozess übernommen wird, ist es sinnvoll, die Art und Weise, wie Protokolle gesammelt und abgerufen werden, zu standardisieren. Der journald-Daemon sammelt Daten aus allen verfügbaren Quellen und speichert sie in einem binären Format, um eine einfache und dynamische Manipulation zu ermöglichen.

Dies verschafft uns eine Reihe von bedeutenden Vorteilen. Durch die Interaktion mit den Daten über ein einzelnes Werkzeug können Administratoren die Protokolldaten dynamisch entsprechend ihren Bedürfnissen anzeigen. Dies kann so einfach sein wie das Ansehen der Boot-Daten von vor drei Starts oder das sequenzielle Zusammenfügen der Protokolleinträge von zwei verwandten Diensten, um ein Kommunikationsproblem zu debuggen.

Das Speichern der Protokolldaten in einem binären Format bedeutet auch, dass die Daten je nach aktuellem Bedarf in beliebigen Ausgabeformaten angezeigt werden können. Zum Beispiel sind Sie für das tägliche Protokollmanagement möglicherweise daran gewöhnt, die Logs im Standard-syslog-Format anzusehen, aber wenn Sie später entscheiden, Dienstunterbrechungen zu grafisch darzustellen, können Sie jeden Eintrag als JSON-Objekt ausgeben, um ihn für Ihren Grafikdienst nutzbar zu machen. Da die Daten nicht im Klartext auf die Festplatte geschrieben werden, ist keine Konvertierung erforderlich, wenn Sie ein anderes Format nach Bedarf benötigen.

Das systemd-Journal kann entweder mit einer bestehenden syslog-Implementierung verwendet werden, oder es kann die syslog-Funktionalität ersetzen, je nach Ihren Bedürfnissen. Während das systemd-Journal die meisten Protokollierungsbedürfnisse eines Administrators abdeckt, kann es auch bestehende Protokollierungsmechanismen ergänzen. Zum Beispiel können Sie einen zentralisierten syslog-Server haben, den Sie verwenden, um Daten von mehreren Servern zu sammeln, aber Sie möchten möglicherweise auch die Protokolle mehrerer Dienste auf einem einzelnen System mit dem systemd-Journal verknüpfen. Sie können beides tun, indem Sie diese Technologien kombinieren.

Einstellen der Systemzeit

Einer der Vorteile der Verwendung eines Binärjournals zum Protokollieren ist die Möglichkeit, Protokolleinträge nach Belieben in UTC oder lokaler Zeit anzuzeigen. Standardmäßig zeigt systemd die Ergebnisse in lokaler Zeit an.

Aus diesem Grund werden wir, bevor wir mit dem Journal beginnen, sicherstellen, dass die Zeitzone korrekt eingestellt ist. Die systemd-Suite enthält tatsächlich ein Werkzeug namens timedatectl, das dabei helfen kann.

Zuerst sehen Sie, welche Zeitzonen mit der Option list-timezones verfügbar sind:

timedatectl list-timezones

Dies listet die auf Ihrem System verfügbaren Zeitzonen auf. Wenn Sie diejenige gefunden haben, die dem Standort Ihres Servers entspricht, können Sie sie mit der Option set-timezone einstellen:

sudo timedatectl set-timezone zone

Um sicherzustellen, dass Ihre Maschine jetzt die richtige Zeit verwendet, verwenden Sie den Befehl timedatectl allein oder mit der Option status. Die Anzeige wird dieselbe sein:

timedatectl status

               Local time: Fri 2021-07-09 14:44:30 EDT
           Universal time: Fri 2021-07-09 18:44:30 UTC
                 RTC time: Fri 2021-07-09 18:44:31
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Die erste Zeile sollte die richtige Uhrzeit anzeigen.

Grundlegende Protokollanzeige

Um die Protokolle zu sehen, die der journald-Daemon gesammelt hat, verwenden Sie den Befehl journalctl.

Wenn es allein verwendet wird, wird jeder Tagebucheintrag, der sich im System befindet, innerhalb eines Pagers (normalerweise less) angezeigt, damit Sie ihn durchsuchen können. Die ältesten Einträge stehen oben:

journalctl

-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules

. . .

Sie werden wahrscheinlich Seiten und Seiten von Daten durchscrollen müssen, die Zehntausende oder Hunderttausende von Zeilen lang sein können, wenn systemd schon lange auf Ihrem System läuft. Dies zeigt, wie viele Daten in der Journaldatenbank verfügbar sind.

Das Format wird denen vertraut sein, die an die Standard-syslog-Protokollierung gewöhnt sind. Tatsächlich werden jedoch Daten aus mehr Quellen gesammelt, als traditionelle syslog-Implementierungen verarbeiten können. Es werden Protokolle aus dem frühen Bootprozess, dem Kernel, dem initrd sowie den Standardfehler- und -ausgaben von Anwendungen erfasst. All diese sind im Journal verfügbar.

Sie werden möglicherweise feststellen, dass alle angezeigten Zeitstempel die Ortszeit sind. Dies ist für jeden Logeintrag verfügbar, da wir unsere Ortszeit auf unserem System jetzt korrekt eingestellt haben. Alle Logs werden unter Verwendung dieser neuen Informationen angezeigt.

Wenn Sie die Zeitstempel in UTC anzeigen möchten, können Sie das --utc-Flag verwenden:

journalctl --utc

Journalfilterung nach Zeit

Obwohl der Zugriff auf eine so große Datensammlung definitiv nützlich ist, kann eine so große Menge an Informationen schwierig oder unmöglich manuell zu überprüfen und zu verarbeiten sein. Aus diesem Grund ist eine der wichtigsten Funktionen von journalctl seine Filteroptionen.

Anzeige der Protokolle vom aktuellen Start

Das grundlegendste davon, das Sie möglicherweise täglich verwenden, ist das -b Flag. Dies zeigt Ihnen alle Journaleinträge, die seit dem letzten Neustart gesammelt wurden.

journalctl -b

Dies wird Ihnen helfen, Informationen zu identifizieren und zu verwalten, die für Ihre aktuelle Umgebung relevant sind.

In Fällen, in denen Sie diese Funktion nicht verwenden und mehr als einen Tag von Boots anzeigen, werden Sie sehen, dass journalctl eine Zeile eingefügt hat, die so aussieht, wann immer das System heruntergefahren wurde:

. . .

-- Reboot --

. . .

Dies kann verwendet werden, um Ihnen zu helfen, die Informationen logisch in Boot-Sitzungen zu unterteilen.

Vergangene Stiefel

Während Sie häufig die Informationen vom aktuellen Start anzeigen möchten, gibt es sicherlich Zeiten, in denen frühere Starts ebenfalls hilfreich wären. Das Journal kann Informationen von vielen vorherigen Starts speichern, sodass journalctl verwendet werden kann, um Informationen einfach anzuzeigen.

Einige Distributionen ermöglichen standardmäßig das Speichern früherer Startinformationen, während andere diese Funktion deaktivieren. Um persistente Startinformationen zu aktivieren, können Sie entweder das Verzeichnis zum Speichern des Journals erstellen, indem Sie Folgendes eingeben:

sudo mkdir -p /var/log/journal

Oder Sie können die Journaleinstellungsdatei bearbeiten:

sudo nano /etc/systemd/journald.conf

Unter dem [Journal]-Abschnitt setzen Sie die Storage=-Option auf „persistent“, um das persistente Logging zu aktivieren:

. . .
[Journal]
Storage=persistent

Wenn das Speichern früherer Boots auf Ihrem Server aktiviert ist, bietet journalctl einige Befehle, um mit Boots als Einheit der Unterteilung zu arbeiten. Um die Boots zu sehen, die journald kennt, verwenden Sie die Option --list-boots mit journalctl:

journalctl --list-boots

-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC

Dies zeigt eine Zeile für jeden Bootvorgang an. Die erste Spalte ist der Offset für den Bootvorgang, der verwendet werden kann, um den Bootvorgang einfach mit journalctl zu referenzieren. Wenn Sie eine absolute Referenz benötigen, befindet sich die Boot-ID in der zweiten Spalte. Sie können die Zeit, auf die sich die Boot-Sitzung bezieht, mit den zwei am Ende aufgeführten Zeitangaben erkennen.

Um Informationen von diesen Stiefeln anzuzeigen, können Sie Informationen entweder aus der ersten oder der zweiten Spalte verwenden.

Um zum Beispiel das Journal vom vorherigen Start zu sehen, verwenden Sie den relativen Zeiger -1 mit dem -b-Flag:

journalctl -b -1

Sie können auch die Boot-ID verwenden, um die Daten von einem Boot abzurufen:

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

Zeitfenster

Während das Anzeigen von Protokolleinträgen nach Systemstart äußerst nützlich ist, möchten Sie möglicherweise oft Zeiträume abfragen, die nicht gut mit den Systemstarts übereinstimmen. Dies ist besonders der Fall bei der Arbeit mit lang laufenden Servern mit erheblicher Betriebszeit.

Sie können nach beliebigen Zeitgrenzen filtern, indem Sie die Optionen --since und --until verwenden, die die angezeigten Einträge auf diejenigen beschränken, die jeweils nach bzw. vor der angegebenen Zeit liegen.

Die Zeitwerte können in verschiedenen Formaten vorliegen. Für absolute Zeitwerte sollten Sie das folgende Format verwenden:

YYYY-MM-DD HH:MM:SS

Zum Beispiel können wir alle Einträge seit dem 10. Januar 2015 um 17:15 Uhr sehen, indem wir Folgendes eingeben:

journalctl --since "2015-01-10 17:15:00"

Wenn Komponenten des obigen Formats weggelassen werden, werden einige Standardwerte angewendet. Zum Beispiel wird, wenn das Datum weggelassen wird, das aktuelle Datum angenommen. Wenn die Zeitkomponente fehlt, wird „00:00:00“ (Mitternacht) eingesetzt. Auch das Sekundenfeld kann weggelassen werden, sodass „00“ als Standardwert verwendet wird:

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

Das Journal versteht auch einige relative Werte und benannte Abkürzungen. Zum Beispiel können Sie die Wörter „gestern“, „heute“, „morgen“ oder „jetzt“ verwenden. Sie können relative Zeiten angeben, indem Sie einem Zahlenwert ein „-“ oder „+“ voranstellen oder Wörter wie „vor“ in einem Satzkonstrukt verwenden.

Um die Daten von gestern zu erhalten, könnten Sie eingeben:

journalctl --since yesterday

Wenn Sie Berichte über eine Dienstunterbrechung erhalten haben, die um 9:00 Uhr begann und bis vor einer Stunde andauerte, könnten Sie tippen:

journalctl --since 09:00 --until "1 hour ago"

Wie Sie sehen können, ist es relativ einfach, flexible Zeitfenster zu definieren, um die Einträge zu filtern, die Sie sehen möchten.

Filtern nach Nachrichteninteresse

Oben haben wir einige Möglichkeiten gelernt, wie Sie die Journaldaten mit Zeitgrenzen filtern können. In diesem Abschnitt werden wir besprechen, wie man basierend darauf filtert, an welchem Dienst oder welcher Komponente Sie interessiert sind. Das systemd-Journal bietet verschiedene Möglichkeiten, dies zu tun.

Pro Einheit

Vielleicht ist die nützlichste Art des Filterns nach der Einheit, an der Sie interessiert sind. Wir können die Option -u verwenden, um auf diese Weise zu filtern.

Zum Beispiel können wir, um alle Protokolle einer Nginx-Einheit auf unserem System zu sehen, Folgendes eingeben:

journalctl -u nginx.service

Normalerweise würden Sie wahrscheinlich auch nach der Zeit filtern wollen, um die Zeilen anzuzeigen, die Sie interessieren. Zum Beispiel können Sie, um zu überprüfen, wie der Dienst heute läuft, Folgendes eingeben:

journalctl -u nginx.service --since today

Diese Art von Fokus wird besonders hilfreich, wenn Sie die Fähigkeit des Journals nutzen, Datensätze aus verschiedenen Einheiten zu vermischen. Zum Beispiel, wenn Ihr Nginx-Prozess mit einer PHP-FPM-Einheit verbunden ist, um dynamische Inhalte zu verarbeiten, können Sie die Einträge von beiden in chronologischer Reihenfolge zusammenführen, indem Sie beide Einheiten angeben:

journalctl -u nginx.service -u php-fpm.service --since today

Dies kann es viel einfacher machen, die Interaktionen zwischen verschiedenen Programmen zu erkennen und Systeme anstelle einzelner Prozesse zu debuggen.

Nach Prozess-, Benutzer- oder Gruppen-ID

Einige Dienste starten eine Vielzahl von Kindprozessen, um Arbeit zu erledigen. Wenn Sie die genaue PID des Prozesses, an dem Sie interessiert sind, herausgefunden haben, können Sie auch danach filtern.

Um dies zu tun, können wir filtern, indem wir das Feld _PID angeben. Zum Beispiel, wenn die PID, an der wir interessiert sind, 8088 ist, könnten wir eingeben:

journalctl _PID=8088

Zu anderen Zeiten möchten Sie möglicherweise alle Einträge anzeigen, die von einem bestimmten Benutzer oder einer bestimmten Gruppe protokolliert wurden. Dies kann mit den Filtern _UID oder _GID erfolgen. Wenn beispielsweise Ihr Webserver unter dem Benutzer www-data läuft, können Sie die Benutzer-ID herausfinden, indem Sie Folgendes eingeben:

id -u www-data

Danach können Sie die zurückgegebene ID verwenden, um die Journalergebnisse zu filtern:

journalctl _UID=33 --since today

Das systemd-Journal hat viele Felder, die zum Filtern verwendet werden können. Einige davon werden vom zu protokollierenden Prozess übergeben und einige werden von journald unter Verwendung von Informationen angewendet, die es zum Zeitpunkt des Logs vom System sammelt.

Der führende Unterstrich zeigt an, dass das _PID-Feld vom letzteren Typ ist. Das Journal zeichnet automatisch die PID des Prozesses auf, der protokolliert, und indexiert sie für spätere Filterung. Sie können sich über alle verfügbaren Journalfelder informieren, indem Sie Folgendes eingeben:

man systemd.journal-fields

Wir werden einige davon in diesem Handbuch besprechen. Für den Moment werden wir jedoch noch eine nützliche Option durchgehen, die mit der Filterung nach diesen Feldern zu tun hat. Die -F-Option kann verwendet werden, um alle verfügbaren Werte für ein bestimmtes Journalfeld anzuzeigen.

Um beispielsweise zu sehen, für welche Gruppen-IDs das systemd-Journal Einträge enthält, können Sie tippen:

journalctl -F _GID

Dies zeigt Ihnen alle Werte, die das Journal für das Gruppen-ID-Feld gespeichert hat. Dies kann Ihnen helfen, Ihre Filter zu erstellen.

Nach Komponentenpfad

Wir können auch nach einem Pfadstandort filtern.

Wenn der Pfad zu einer ausführbaren Datei führt, zeigt journalctl alle Einträge an, die die betreffende ausführbare Datei betreffen. Zum Beispiel können Sie, um die Einträge zu finden, die die ausführbare Datei bash betreffen, Folgendes eingeben:

journalctl /usr/bin/bash

Normalerweise, wenn eine Einheit für die ausführbare Datei verfügbar ist, ist diese Methode sauberer und liefert bessere Informationen (Einträge von zugehörigen Kindprozessen usw.). Manchmal ist dies jedoch nicht möglich.

Anzeige von Kernel-Nachrichten

Kernel-Nachrichten, die normalerweise in der dmesg-Ausgabe zu finden sind, können auch aus dem Journal abgerufen werden.

Um nur diese Nachrichten anzuzeigen, können wir die Flags -k oder --dmesg zu unserem Befehl hinzufügen:

journalctl -k

Standardmäßig werden dadurch die Kernel-Nachrichten vom aktuellen Start angezeigt. Sie können einen alternativen Start angeben, indem Sie die zuvor besprochenen normalen Startauswahl-Flags verwenden. Zum Beispiel, um die Nachrichten von vor fünf Starts zu erhalten, könnten Sie Folgendes eingeben:

journalctl -k -b -5

Nach Priorität

Ein Filter, an dem Systemadministratoren oft interessiert sind, ist die Nachrichtenpriorität. Während es oft nützlich ist, Informationen auf einem sehr ausführlichen Niveau zu protokollieren, können niedrig priorisierte Protokolle beim tatsächlichen Verarbeiten der verfügbaren Informationen ablenkend und verwirrend sein.

Sie können journalctl verwenden, um nur Nachrichten einer angegebenen Priorität oder höher anzuzeigen, indem Sie die Option -p verwenden. Dies ermöglicht es Ihnen, Nachrichten niedrigerer Priorität herauszufiltern.

Zum Beispiel können Sie, um nur Einträge anzuzeigen, die auf Fehlerstufe oder höher protokolliert wurden, Folgendes eingeben:

journalctl -p err -b

Dies zeigt Ihnen alle Nachrichten, die als Fehler, kritisch, Alarm oder Notfall markiert sind. Das Journal implementiert die standardmäßigen syslog-Meldeebenen. Sie können entweder den Prioritätsnamen oder den entsprechenden numerischen Wert verwenden. In der Reihenfolge von höchster zu niedrigster Priorität sind dies:

0: emerg
1: aufmerksam
2: kritisch
3: Fehler
4: Warnung
5: Hinweis
6: Informationen
7: debuggen

Die oben genannten Zahlen oder Namen können austauschbar mit der -p-Option verwendet werden. Die Auswahl einer Priorität zeigt Nachrichten an, die mit dem angegebenen Level und höher markiert sind.

Anpassen der Journalanzeige

Oben haben wir die Auswahl von Einträgen durch Filtern demonstriert. Es gibt jedoch auch andere Möglichkeiten, die Ausgabe zu ändern. Wir können die Anzeige von journalctl an verschiedene Bedürfnisse anpassen.

Ausgabe kürzen oder erweitern

Wir können anpassen, wie journalctl Daten anzeigt, indem wir ihm sagen, die Ausgabe zu verkleinern oder zu vergrößern.

Standardmäßig zeigt journalctl den gesamten Eintrag im Pager an, wodurch die Einträge nach rechts aus dem Bildschirm herauslaufen können. Auf diese Informationen kann zugegriffen werden, indem die rechte Pfeiltaste gedrückt wird.

Wenn Sie lieber eine gekürzte Ausgabe haben möchten, bei der ein Auslassungszeichen eingefügt wird, wo Informationen entfernt wurden, können Sie die Option --no-full verwenden:

journalctl --no-full

. . .

Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot

Sie können auch in die entgegengesetzte Richtung gehen und journalctl anweisen, alle seine Informationen anzuzeigen, unabhängig davon, ob sie nicht druckbare Zeichen enthalten. Wir können dies mit dem -a-Flag tun:

journalctl -a

Ausgabe an die Standardausgabe

Standardmäßig zeigt journalctl die Ausgabe in einem Pager für eine einfachere Lesbarkeit an. Wenn Sie die Daten jedoch mit Textbearbeitungstools verarbeiten möchten, möchten Sie wahrscheinlich in der Lage sein, auf die Standardausgabe zu schreiben.

Sie können dies mit der Option --no-pager tun:

journalctl --no-pager

Dies kann je nach Ihren Bedürfnissen sofort in ein Verarbeitungsprogramm geleitet oder in eine Datei auf der Festplatte umgeleitet werden.

Ausgabeformate

Wenn Sie Buchungssätze verarbeiten, wie oben erwähnt, werden Sie höchstwahrscheinlich einfacher die Daten analysieren können, wenn sie in einem besser nutzbaren Format vorliegen. Zum Glück kann das Journal je nach Bedarf in verschiedenen Formaten angezeigt werden. Sie können dies mit der -o-Option und einem Formatspezifizierer tun.

Zum Beispiel können Sie die Journaleinträge im JSON-Format ausgeben, indem Sie Folgendes eingeben:

journalctl -b -u nginx -o json

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

. . .

Dies ist nützlich für das Parsen mit Hilfsprogrammen. Sie könnten das json-pretty-Format verwenden, um einen besseren Überblick über die Datenstruktur zu erhalten, bevor Sie sie an den JSON-Verbraucher weitergeben:

journalctl -b -u nginx -o json-pretty

{
	"__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
	"__REALTIME_TIMESTAMP" : "1422990364739502",
	"__MONOTONIC_TIMESTAMP" : "27200938",
	"_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
	"PRIORITY" : "6",
	"_UID" : "0",
	"_GID" : "0",
	"_CAP_EFFECTIVE" : "3fffffffff",
	"_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
	"_HOSTNAME" : "desktop",
	"SYSLOG_FACILITY" : "3",
	"CODE_FILE" : "src/core/unit.c",
	"CODE_LINE" : "1402",
	"CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
	"SYSLOG_IDENTIFIER" : "systemd",
	"MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
	"_TRANSPORT" : "journal",
	"_PID" : "1",
	"_COMM" : "systemd",
	"_EXE" : "/usr/lib/systemd/systemd",
	"_CMDLINE" : "/usr/lib/systemd/systemd",
	"_SYSTEMD_CGROUP" : "/",
	"UNIT" : "nginx.service",
	"MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
	"_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}

. . .

Die folgenden Formate können für die Anzeige verwendet werden:

cat: Zeigt nur das Nachrichtenfeld selbst an.
exportieren: Ein binäres Format, das sich zum Übertragen oder Sichern eignet.
json: Standard-JSON mit einem Eintrag pro Zeile.
json-pretty: JSON zur besseren Lesbarkeit für Menschen formatiert
json-sse: JSON-formatiertes Ausgabeformat, um servergesendete Ereignisse kompatibel zu machen
kurz: Die Standard-syslog-Stil-Ausgabe
short-iso: Das Standardformat, erweitert um ISO-8601-Wanduhren-Zeitstempel anzuzeigen.
short-monoton: Das Standardformat mit monotonen Zeitstempeln.
kurz-präzise: Das Standardformat mit Mikrosekundenpräzision
verbose: Zeigt jedes für den Eintrag verfügbare Journalelement, einschließlich der normalerweise intern verborgenen.

Diese Optionen ermöglichen es Ihnen, die Journaleinträge in dem Format anzuzeigen, das am besten zu Ihren aktuellen Bedürfnissen passt.

Aktive Prozessüberwachung

Der Befehl journalctl ahmt nach, wie viele Administratoren tail zur Überwachung aktiver oder kürzlich durchgeführter Aktivitäten verwenden. Diese Funktionalität ist in journalctl eingebaut, sodass Sie auf diese Funktionen zugreifen können, ohne an ein anderes Werkzeug weiterleiten zu müssen.

Anzeige der letzten Protokolle

Um eine festgelegte Anzahl von Datensätzen anzuzeigen, können Sie die -n-Option verwenden, die genau wie tail -n funktioniert.

Standardmäßig werden die 10 neuesten Einträge angezeigt:

journalctl -n

Sie können die Anzahl der Einträge, die Sie sehen möchten, mit einer Zahl nach dem -n angeben:

journalctl -n 20

Folgende Protokolle

Um die Logs aktiv zu verfolgen, während sie geschrieben werden, können Sie das -f-Flag verwenden. Auch dies funktioniert wie erwartet, wenn Sie Erfahrung im Umgang mit tail -f haben:

journalctl -f

Um diesen Befehl zu beenden, geben Sie CTRL+C ein.

Journalpflege

Sie fragen sich vielleicht, wie hoch die Kosten für die Speicherung all der Daten sind, die wir bisher gesehen haben. Außerdem könnten Sie daran interessiert sein, einige ältere Protokolle zu bereinigen und Speicherplatz freizugeben.

Aktuelle Festplattennutzung finden

Sie können herausfinden, wie viel Speicherplatz das Journal derzeit auf der Festplatte einnimmt, indem Sie das --disk-usage Flag verwenden:

journalctl --disk-usage

Archived and active journals take up 8.0M in the file system.

Alte Protokolle löschen

Wenn Sie Ihr Journal verkleinern möchten, können Sie dies auf zwei verschiedene Arten tun (verfügbar ab systemd Version 218).

Wenn Sie die Option --vacuum-size verwenden, können Sie Ihr Journal verkleinern, indem Sie eine Größe angeben. Dadurch werden alte Einträge entfernt, bis der insgesamt auf der Festplatte belegte Journalspeicher die angeforderte Größe erreicht:

sudo journalctl --vacuum-size=1G

Eine weitere Möglichkeit, das Journal zu verkleinern, besteht darin, eine Stoppzeit mit der Option --vacuum-time anzugeben. Alle Einträge nach dieser Zeit werden gelöscht. Dies ermöglicht es Ihnen, die Einträge zu behalten, die nach einer bestimmten Zeit erstellt wurden.

Zum Beispiel können Sie, um Einträge des letzten Jahres zu behalten, Folgendes eingeben:

sudo journalctl --vacuum-time=1years

Begrenzung der Zeitschriftenerweiterung

Sie können Ihren Server so konfigurieren, dass Limits festgelegt werden, wie viel Platz das Journal beanspruchen kann. Dies kann durch Bearbeiten der Datei /etc/systemd/journald.conf erfolgen.

Die folgenden Elemente können verwendet werden, um das Wachstum des Journals zu begrenzen:

SystemMaxUse=: Gibt den maximalen Speicherplatz an, der vom Journal im persistenten Speicher verwendet werden kann.
SystemKeepFree=: Gibt an, wie viel Speicherplatz das Journal beim Hinzufügen von Journaleinträgen zum persistenten Speicher frei lassen soll.
SystemMaxFileSize=: Steuert, wie groß einzelne Journaldateien im persistenten Speicher werden können, bevor sie rotiert werden.
RuntimeMaxUse=: Gibt den maximalen Speicherplatz an, der im flüchtigen Speicher (innerhalb des /run-Dateisystems) verwendet werden kann.
RuntimeKeepFree=: Gibt die Menge an Speicher an, die beim Schreiben von Daten in den flüchtigen Speicher (innerhalb des /run-Dateisystems) für andere Zwecke freigehalten werden soll.
RuntimeMaxFileSize=: Gibt an, wie viel Speicherplatz eine einzelne Journald-Datei im flüchtigen Speicher (/run-Dateisystem) belegen kann, bevor sie rotiert wird.

Durch das Festlegen dieser Werte können Sie steuern, wie journald auf Ihrem Server Speicherplatz verwendet und erhält. Beachten Sie, dass SystemMaxFileSize und RuntimeMaxFileSize darauf abzielen, dass archivierte Dateien die angegebenen Grenzwerte erreichen. Dies ist wichtig zu beachten, wenn Sie die Dateianzahlen nach einem Aufräumvorgang interpretieren.

Fazit

Wie Sie sehen können, ist das systemd-Journal unglaublich nützlich, um Ihre System- und Anwendungsdaten zu sammeln und zu verwalten. Ein Großteil der Flexibilität ergibt sich aus den umfangreichen Metadaten, die automatisch aufgezeichnet werden, und der zentralisierten Natur des Logs. Der Befehl journalctl macht es einfach, die erweiterten Funktionen des Journals zu nutzen und umfangreiche Analysen sowie relationale Fehlersuche von verschiedenen Anwendungsbestandteilen durchzuführen.