One place for hosting & domains

      zum

      So verwenden Sie ps, kill und schön zum Verwalten von Prozessen unter Linux


      Einführung

      Auf einem Linux-Server werden wie auf jedem anderen Computer, mit dem Sie möglicherweise vertraut sind, Anwendungen ausgeführt. Auf dem Computer werden diese als „Prozesse“ bezeichnet.

      Während Linux die Verwaltung auf niedriger Ebene hinter den Kulissen im Lebenszyklus eines Prozesses übernimmt, benötigen Sie eine Möglichkeit zur Interaktion mit dem Betriebssystem, um es von einer höheren Ebene aus zu verwalten.

      In diesem Leitfaden werden wir einige einfache Aspekte der Prozessverwaltung erörtern. Linux bietet eine reichliche Sammlung von Tools für diesen Zweck.

      Wir werden diese Ideen auf einem Ubuntu 12.04 VPS untersuchen, aber jede moderne Linux-Distribution funktioniert auf ähnliche Weise.

      So zeigen Sie laufende Prozesse unter Linux an

      top

      Der einfachste Weg, um herauszufinden, welche Prozesse auf Ihrem Server ausgeführt werden, besteht darin, den Befehl top auszuführen:

      top***

top - 15:14:40 bis 46 min, 1 Benutzer, Lastdurchschnitt: 0,00, 0,01, 0,05 Aufgaben: 56 insgesamt, 1 laufend, 55 inaktiv, 0 gestoppt, 0 Zombie Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem: 1019600k gesamt, 316576k gebraucht, 703024k frei, 7652k Puffer Swap: 0k insgesamt, 0k verwendet, 0k frei, 258976k zwischengespeichert   PID USER PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND               1 root      20   0 24188 2120 1300 S  0.0  0.2   0:00.56 init                   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd               3 root      20   0     0    0    0 S  0.0  0.0   0:00.07 ksoftirqd/0            6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0            7 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 watchdog/0             8 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset                 9 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper               10 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kdevtmpfs

      Der oberste Informationsblock enthält Systemstatistiken wie die Systemlast und die Gesamtzahl der Aufgaben.

      Sie können leicht erkennen, dass 1 Prozess ausgeführt wird und 55 Prozesse inaktiv sind (auch bekannt als inaktiv/ohne CPU-Ressourcen).

      Der untere Teil enthält die laufenden Prozesse und ihre Nutzungsstatistiken.

      htop

      Eine verbesserte Version von top namens htop ist in den Repositorys verfügbar. Installieren Sie sie mit diesem Befehl:

      sudo apt-get install htop

      Wenn wir den Befehl htop ausführen, sehen wir, dass es eine benutzerfreundlichere Anzeige gibt:

      htop***

  Mem[|||||||||||           49/995MB]     Durchschnittslast: 0.00 0.03 0.05   CPU[                          0.0%]     Aufgaben: 21, 3 thr; 1 laufend   Swp[                         0/0MB]     Betriebszeit: 00:58:11   PID USER PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command  1259 root       20   0 25660  1880  1368 R  0.0  0.2  0:00.06 htop     1 root       20   0 24188  2120  1300 S  0.0  0.2  0:00.56 /sbin/init   311 root       20   0 17224   636   440 S  0.0  0.1  0:00.07 upstart-udev-brid   314 root       20   0 21592  1280   760 S  0.0  0.1  0:00.06 /sbin/udevd --dae   389 messagebu  20   0 23808   688   444 S  0.0  0.1  0:00.01 dbus-daemon --sys   407 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.02 rsyslogd -c5   408 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.00 rsyslogd -c5   409 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.00 rsyslogd -c5   406 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.04 rsyslogd -c5   553 root       20   0 15180   400   204 S  0.0  0.0  0:00.01 upstart-socket-br

      Sie können hier mehr über die Verwendung von top und htop erfahren.

      Verwendung von ps zum Auflisten von Prozessen

      Sowohl top als auch htop bieten eine schöne Benutzeroberfläche, um laufende Prozesse zu sehen, die einem grafischen Aufgabenmanager ähneln.

      Diese Tools sind jedoch nicht immer flexibel genug, um alle Szenarien angemessen zu behandeln. Ein leistungsfähiger Befehl namens ps ist oft die Antwort auf diese Probleme.

      Wenn er ohne Argumente aufgerufen wird, kann die Ausgabe etwas fehlerhafter sein:

      ps***

  PID TTY          TIME CMD  1017 pts/0    00:00:00 bash  1262 pts/0    00:00:00 ps

      Diese Ausgabe zeigt alle mit dem aktuellen Benutzer und der Terminalsitzung verknüpften Prozesse an. Dies ist sinnvoll, da wir derzeit nur bash und ps mit diesem Terminal ausführen.

      Um ein vollständigeres Bild der Prozesse auf diesem System zu erhalten, können wir Folgendes ausführen:

      ps aux***

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND root         1  0.0  0.2  24188  2120 ?        Ss   14:28   0:00 /sbin/initroot         2  0.0  0.0      0     0 ?        S    14:28   0:00 [kthreadd] root         3  0.0  0.0      0     0 ?        S    14:28   0:00 [ksoftirqd/0] root         6  0.0  0.0      0     0 ?        S    14:28   0:00 [migration/0] root         7  0.0  0.0      0     0 ?        S    14:28   0:00 [watchdog/0] root         8  0.0  0.0      0     0 ?        S<   14:28   0:00 [cpuset] root         9  0.0  0.0      0     0 ?        S<   14:28   0:00 [khelper] . . .

      Diese Optionen weisen ps an, Prozesse, die allen Benutzern gehören (unabhängig von ihrer Terminalzuordnung), in einem benutzerfreundlichen Format anzuzeigen.

      Um eine Baumansicht zu sehen, in der hierarchische Beziehungen illustriert werden, können wir den Befehl mit diesen Optionen ausführen:

      ps axjf***

 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND     0     2     0     0 ?           -1 S        0   0:00 [kthreadd]     2     3     0     0 ?           -1 S        0   0:00  _ [ksoftirqd/0]     2     6     0     0 ?           -1 S        0   0:00  _ [migration/0]     2     7     0     0 ?           -1 S        0   0:00  _ [watchdog/0]     2     8     0     0 ?           -1 S<       0   0:00  _ [cpuset]     2     9     0     0 ?           -1 S<       0   0:00  _ [khelper]     2    10     0     0 ?           -1 S        0   0:00  _ [kdevtmpfs]     2    11     0     0 ?           -1 S<       0   0:00  _ [netns] . . .

      Wie Sie sehen können, wird der Prozess kthreadd als übergeordnetes Element des Prozesses ksoftirqd/0 und der anderen Prozesse angezeigt.

      Eine Anmerkung zu Prozess-IDs

      In Linux- und Unix-ähnlichen Systemen wird jedem Prozess einer Prozess-ID oder PID zugewiesen. So identifiziert und verfolgt das Betriebssystem Prozesse.

      Eine schnelle Möglichkeit zum Abrufen der PID eines Prozesses ist mit dem Befehl pgrep:

      pgrep bash***

1017

      Dadurch wird die Prozess-ID einfach abfragt und zurückgegeben.

      Der erste beim Booten erzeugte Prozess namens init erhält die PID „1“.

      pgrep init***

1

      Dieser Prozess ist dann dafür verantwortlich, jeden anderen Prozess auf dem System zu erzeugen. Die späteren Prozesse erhalten größere PID-Nummern.

      Das übergeordnete Element eines Prozesses ist der Prozess, der für das Ablegen verantwortlich war. Übergeordnete Prozesse verfügen über eine PPID, die Sie in den Spaltenüberschriften vieler Prozessverwaltungsanwendungen sehen können, einschließlich top, htop und ps.

      Jede Kommunikation zwischen dem Benutzer und dem Betriebssystem über Prozesse umfasst die Übersetzung zwischen Prozessnamen und PIDs zu einem bestimmten Zeitpunkt während des Vorgangs. Aus diesem Grund teilen Dienstprogramme Ihnen die PID mit.

      Übergeordnete-untergeordnete Beziehungen

      Das Erstellen eines untergeordneten Prozesses erfolgt in zwei Schritten: fork(), das einen neuen Adressraum erstellt und die Ressourcen des übergeordneten Elements per Copy-on-Write kopiert, um dem untergeordneten Prozess zur Verfügung zu stehen; und exec(), das eine ausführbare Datei in den Adressraum lädt und ausführt.

      Für den Fall, dass ein untergeordneter Prozess vor seinem übergeordneten Prozess beendet wird, wird der untergeordnete Prozess zu einem Zombie, bis der übergeordnete Prozess Informationen darüber gesammelt oder dem Kernel angezeigt hat, dass er diese Informationen nicht benötigt. Die Ressourcen aus dem untergeordneten Prozess werden dann freigegeben. Wenn der übergeordnete Prozess jedoch vor dem untergeordneten Prozess beendet wird, wird der untergeordnete Prozess von init übernommen, obwohl er auch einem anderen Prozess neu zugewiesen werden kann.

      So senden Sie Prozesssignale in Linux

      Alle Prozesse in Linux reagieren auf Signale. Signale sind eine Methode auf Betriebssystemebene, mit der Programme angewiesen werden, ihr Verhalten zu beenden oder zu ändern.

      So senden Sie Prozesssignale nach PID

      Die häufigste Art, Signale an ein Programm weiterzuleiten, ist mit dem Befehl kill.

      Wie Sie möglicherweise erwarten, besteht die Standardfunktion dieses Dienstprogramms darin, zu versuchen, einen Prozess zu beenden:

      kill PID_of_target_process

      Dadurch wird das TERM-Signal an den Prozess gesendet. Das TERM-Signal weist den Prozess an, zu beenden. Dadurch kann das Programm Reinigungsvorgänge durchführen und reibungslos beenden.

      Wenn sich das Programm schlecht verhält und bei Erhalt des TERM-Signals nicht beendet wird, können wir das Signal durch Weiterleiten des KILL-Signals eskalieren:

      kill -KILL PID_of_target_process

      Dies ist ein spezielles Signal, das nicht an das Programm gesendet wird.

      Stattdessen wird es dem Betriebssystem-Kernel übergeben, der den Prozess herunterschaltet. Dies wird verwendet, um Programme zu umgehen, die die an sie gesendeten Signale ignorieren.

      Jedem Signal ist eine Nummer zugeordnet, die anstelle des Namens übergeben werden kann. Beispielsweise können Sie „-15“ anstelle von „-TERM“ und „-9“ anstelle von „-KILL“ übergeben.

      So verwenden Sie Signale für andere Zwecke

      Signale werden nicht nur zum Herunterfahren von Programmen verwendet. Sie können auch verwendet werden, um andere Aktionen auszuführen.

      Beispielsweise werden viele Daemons neu gestartet, wenn sie das HUP– oder Auflegesignal erhalten. Apache ist ein Programm, das so funktioniert.

      sudo kill -HUP pid_of_apache

      Der obige Befehl führt dazu, dass Apache seine Konfigurationsdatei neu lädt und Inhalte wiederbelebt.

      Sie können alle Signale auflisten, die mit kill gesendet werden können, indem Sie Folgendes eingeben:

      kill -l***

1) SIGHUP    2) SIGINT   3) SIGQUIT  4) SIGILL   5) SIGTRAP  6) SIGABRT  7) SIGBUS   8) SIGFPE   9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM . . .

      So senden Sie Prozesssignale nach Name

      Obwohl die konventionelle Art des Sendens von Signalen durch die Verwendung von PIDs ist, gibt es auch Methoden, dies mit regulären Prozessnamen zu tun.

      Der Befehl pkill funktioniert fast genau so wie kill, operiert jedoch stattdessen auf einem Prozessnamen:

      pkill -9 ping

      Der obige Befehl ist das Äquivalent von:

      kill -9 `pgrep ping`

      Wenn Sie ein Signal an jede Instanz eines bestimmten Prozesses senden möchten, können Sie den Befehl killall verwenden:

      killall firefox

      Der obige Befehl sendet das TERM-Signal an jede Instanz von Firefox, das auf dem Computer ausgeführt wird.

      So passen Sie Prozessprioritäten an

      Oft möchten Sie anpassen, welchen Prozessen in einer Serverumgebung Priorität eingeräumt wird.

      Einige Prozesse können als geschäftskritisch für Ihre Situation angesehen werden, während andere ausgeführt werden können, wenn Ressourcen übrig bleiben.

      Linux kontrolliert die Priorität durch einen Wert namens niceness.

      Hohe Prioritätsaufgaben werden als weniger nett angesehen, da sie auch keine Ressourcen teilen. Prozesse mit niedriger Priorität sind dagegen nett, weil sie darauf bestehen, nur minimale Ressourcen zu verbrauchen.

      Als wir am Anfang des Artikels top ausgeführt haben, gab es eine Spalte mit der Bezeichnung „NI“. Dies ist der nette Wert des Prozesses:

      top***

Aufgaben: 56 insgesamt, 1 laufend, 55 inaktiv, 0 gestoppt, 0 Zombie Cpu(s):  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem:   1019600k insgesamt,   324496k verwendet,   695104k frei,     8512k Puffer Swap:   0k insgesamt,   0k verwendet,   0k frei,    264812k zwischengespeichert   PID-BENUTZER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            1635 root      20   0 17300 1200  920 R  0.3  0.1   0:00.01 top                    1 root      20   0 24188 2120 1300 S  0,0  0,2   0:00,56 init                   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd               3 root      20   0     0    0    0 S  0.0  0.0   0:00.11 ksoftirqd/0

      Nette Werte können je nach System zwischen „-19/-20“ (höchste Priorität) und „19/20“ (niedrigste Priorität) liegen.

      Um ein Programm mit einem bestimmten netten Wert auszuführen, können wir den Befehl nice verwenden:

      nice -n 15 command_to_execute

      Dies funktioniert nur, wenn ein neues Programm gestartet wird.

      Um den netten Wert eines Programms zu ändern, das bereits ausgeführt wird, verwenden wir ein Tool namens renice:

      renice 0 PID_to_prioritize

      Hinweis: Während nice zwangsläufig mit einem Befehlsnamen funktioniert, ruft renice die Prozess-PID auf

      Zusammenfassung

      Die Prozessverwaltung ist ein Thema, das für neue Benutzer manchmal schwer zu verstehen ist, da sich die verwendeten Tools von ihren grafischen Gegenstücken unterscheiden.

      Die Ideen sind jedoch vertraut und intuitiv und werden mit ein wenig Übung zur Gewohnheit. Da Prozesse an allem beteiligt sind, was Sie mit einem Computersystem tun, ist es eine wesentliche Fähigkeit, zu lernen, wie man sie effektiv steuert.

      Von Justin Ellingwood



      Source link

      Verwenden von Journalctl zum Anzeigen und Manipulieren von Systemd-Protokollen


      Einführung

      Einige der überzeugendsten Vorteile von systemd sind diejenigen, die mit der Prozess- und Systemprotokollierung verbunden sind. Bei der Verwendung anderer Tools werden Protokolle normalerweise im gesamten System verteilt, von verschiedenen Daemons und Prozessen bearbeitet und können ziemlich schwer zu interpretieren, wenn sie sich über mehrere Anwendungen erstrecken. Systemd versucht, diese Probleme zu lösen, indem es eine zentralisierte Verwaltungslösung zur Protokollierung aller Kernel- und Userland-Prozesse bereitstellt. Das System, das diese Protokolle sammelt und verwaltet, wird als Journal bezeichnet.

      Das Journal wird mit dem Daemon journald implementiert, der alle vom Kernel, initrd, services etc. erzeugten Nachrichten verarbeitet. In diesem Leitfaden besprechen wir die Verwendung des Dienstprogramms journalctl, mit dem Sie auf die in dem Journal gespeicherten Daten zugreifen und diese manipulieren können.

      Allgemeiner Gedanke

      Eine der Triebfedern hinter dem Journal systemd ist die Zentralisierung der Verwaltung von Protokollen, unabhängig davon, woher die Nachrichten stammen. Da ein Großteil des Boot-Prozesses und der Verwaltung von Diensten durch den Prozess systemd abgewickelt wird, ist es sinnvoll, die Art und Weise, wie Protokolle gesammelt und darauf zugegriffen wird, zu standardisieren. Der Daemon journald sammelt Daten aus allen verfügbaren Quellen und speichert sie in einem Binärformat für einfache und dynamische Manipulation.

      Dies bringt eine Reihe von bedeutenden Vorteilen mit sich. Durch die Interaktion mit den Daten über ein einziges Dienstprogramm sind Administratoren in der Lage, Protokolldaten dynamisch nach ihren Bedürfnissen anzuzeigen. Dies kann so einfach sein, wie das Anzeigen der Boot-Daten von vor drei Boot-Vorgängen oder das Kombinieren der Protokolleinträge von zwei verwandten Diensten nacheinander, um ein Kommunikationsproblem zu beheben.

      Das Speichern der Protokolldaten in einem Binärformat bedeutet auch, dass die Daten in beliebigen Ausgabeformaten angezeigt werden können, je nachdem, was Sie gerade benötigen. Für die tägliche Protokollverwaltung sind Sie eventuell daran gewöhnt, die Protokolle im Standard-Format syslog anzuzeigen, aber wenn Sie sich später entscheiden, Dienstunterbrechungen grafisch darzustellen, können Sie jeden Eintrag als JSON-Objekt ausgeben, um ihn für Ihren grafischen Dienst konsumierbar zu machen. Da die Daten nicht im Klartext auf die Festplatte geschrieben werden, ist keine Konvertierung erforderlich, wenn Sie ein anderes On-Demand-Format benötigen.

      Das Journal systemd kann entweder mit einer vorhandenen syslog-Implementierung verwendet werden oder es kann die Funktionalität syslog ersetzen, je nach Ihren Bedürfnissen. Während das Journal systemd die meisten Protokollierungsanforderungen von Administratoren abdeckt, kann es auch bestehende Protokollierungsmechanismen ergänzen. Sie haben vielleicht einen zentralisierten syslog-Server, den Sie verwenden, um Daten von mehreren Servern zu kompilieren, aber Sie möchten die Protokolle auch von mehreren Diensten auf einem einzigen System mit dem Journal systemd zusammenführen. Sie können beides tun, indem Sie diese Technologien kombinieren.

      Einstellen der Systemzeit

      Einer der Vorteile der Verwendung eines binären Journals für die Protokollierung ist die Fähigkeit, Protokolldatensätze in UTC oder lokaler Zeit anzuzeigen. Standardmäßig zeigt systemd Ergebnisse in der lokalen Zeit an.

      Aus diesem Grund stellen wir, bevor wir mit dem Journal beginnen, sicher, dass die Zeitzone korrekt eingestellt ist. Die Suite systemd verfügt über ein Tool namens timedatectl, das dabei helfen kann.

      Sehen Sie zuerst nach, welche Zeitzonen mit der Option list-timezones verfügbar sind:

      timedatectl list-timezones

      Dadurch werden die auf Ihrem System verfügbaren Zeitzonen aufgelistet. 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 Ihr Rechner jetzt die richtige Zeit verwendet, verwenden Sie den Befehl timedatectl allein oder mit der Option status. Die Anzeige wird die gleiche sein:

      timedatectl status

            Local time: Thu 2015-02-05 14:08:06 EST
  Universal time: Thu 2015-02-05 19:08:06 UTC
        RTC time: Thu 2015-02-05 19:08:06
       Time zone: America/New_York (EST, -0500)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

      In der ersten Zeile sollte die korrekte Zeit angezeigt werden.

      Grundlegendes Anzeigen von Protokollen

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

      Bei alleiniger Verwendung wird jeder im System vorhandene Journaleintrag innerhalb eines Pager (normalerweise less) angezeigt, damit Sie durchsuchen können. Die ältesten Einträge werden oben angezeigt:

      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 seitenweise Daten durchblättern müssen, die zehn- oder hunderttausende Zeilen lang sein können, wenn sich systemd schon lange auf Ihrem System befindet. Dies demonstriert, wie viele Daten in der Journal-Datenbank vorhanden sind.

      Das Format wird denjenigen vertraut sein, die an die Standard-Protokollierung syslog gewöhnt sind. Allerdings werden hier tatsächlich Daten aus mehr Quellen gesammelt als traditionelle syslog-Implementierungen in der Lage sind. Es beinhaltet Protokolle des frühen Boot-Prozesses, des Kernel, der initrd und der Anwendungsstandardfehler und -ausgänge. Diese sind alle im Journal verfügbar.

      Vielleicht fällt Ihnen auf, dass alle angezeigten Zeitstempel in lokaler Zeit sind. Dies ist für jeden Protokolleintrag verfügbar, da die lokale Zeit auf unserem System korrekt eingestellt ist. Alle Protokolle werden mit dieser neuen Information angezeigt.

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

      journalctl --utc

      Journal-Filterung nach Zeit

      Obwohl der Zugriff auf eine so große Datensammlung durchaus nützlich ist, kann es schwierig oder unmöglich sein, eine so große Menge mental zu untersuchen und zu verarbeiten. Aus diesem Grund ist eine der wichtigsten Funktionen von journalctl seine Filteroptionen.

      Anzeigen von Protokollen aus dem aktuellen Boot

      Die grundlegendste dieser Optionen, die Sie möglicherweise täglich verwenden, ist das Flag -b. Damit werden Ihnen alle Journaleinträge angezeigt, die seit dem neuesten Neustart gesammelt wurden.

      journalctl -b

      Dies hilft Ihnen, 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 Bootvorgängen 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 dabei zu helfen, die Informationen logisch in Boot-Sitzungen aufzuteilen.

      Vergangene Bootvorgänge

      Während Sie in der Regel die Informationen aus dem aktuellen Bootvorgang anzeigen möchten, gibt es sicherlich Zeiten, in denen auch vergangene Bootvorgänge hilfreich sind. Das Journal kann Informationen von vielen vorherigen Bootvorgängen speichern, sodass journalctl eingestellt werden kann, um Informationen einfacher anzuzeigen.

      Bei einigen Distributionen ist das Speichern von Informationen zu früheren Bootvorgängen standardmäßig aktiviert, bei anderen ist diese Funktion deaktiviert. Um persistente Boot-Informationen 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 Journal-Konfigurationsdatei bearbeiten:

      • sudo nano /etc/systemd/journald.conf

      Setzen Sie unter dem Abschnitt [Journal] die Option Storage= auf „persistent“, um die persistente Protokollierung zu aktivieren:

      /etc/systemd/journald.conf

      . . .
[Journal]
Storage=persistent

      Wenn das Speichern von vorherigen Bootvorgängen auf Ihrem Server aktiviert ist, stellt journalctl einige Befehle bereit, um Ihnen die Arbeit mit Bootvorgängen als Einheit der Division zu erleichtern. Um die Bootvorgänge zu sehen, von denen journald weiß, 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 mit journalctl einfach zu referenzieren. Wenn Sie eine absolute Referenz benötigen, steht die Boot-ID in der zweiten Spalte. Die Zeit, auf die sich die Boot-Sitzung bezieht, erkennen Sie an den beiden Zeitangaben, die am Ende aufgeführt sind.

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

      Um beispielsweise das Journal von dem vorherigen Boot zu sehen, verwenden Sie den relativen Zeiger -1 mit dem Flag -b:

      journalctl -b -1

      Zum Abrufen von Daten aus einem Boot können Sie auch die Boot-ID verwenden:

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe

      Zeitfenster

      Während es unglaublich nützlich ist, Protokolleinträge nach Bootvorgang zu sehen, möchten Sie vielleicht oft Zeitfenster abfragen, die nicht gut mit Systemstarts übereinstimmen. Dies kann besonders bei lang laufenden Servern mit erheblicher Betriebszeit der Fall sein.

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

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

      YYYY-MM-DD HH:MM:SS

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

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

      Wenn Komponenten des obigen Formats weggelassen werden, werden einige Standardwerte angewendet. Wenn beispielsweise das Datum weggelassen wird, wird das aktuelle Datum angenommen. Wenn die Zeitkomponente fehlt, wird „00:00:00“ (Mitternacht) ersetzt. Das Sekundenfeld kann auch weggelassen werden, sodass standardmäßig „00“ verwendet wir:

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

      Das Journal versteht auch einige relative Werte und benannte Abkürzungen. Beispielsweise können Sie die Wörter „gestern“, „heute“, „morgen“ oder „jetzt“ verwenden. Relative Zeiten geben Sie an, indem Sie einem nummerierten Wert ein „-“ oder „+“ voranstellen oder Wörter wie „vor“ in einem Satzbau 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 eingeben:

      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

      Wir haben vorstehend einige Möglichkeiten kennengelernt, wie Sie die Journaldaten anhand von Zeiteinschränkungen filtern können. In diesem Abschnitt werden wir besprechen, wie Sie basierend auf dem Dienst oder der Komponente filtern können, an der Sie interessiert sind. Das Journal systemd bietet eine Vielzahl von Möglichkeiten, dies zu tun.

      Nach Einheit

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

      Um beispielsweise alle Protokolle einer Nginx-Einheit auf unserem System zu sehen, können wir eingeben:

      journalctl -u nginx.service

      Normalerweise würden Sie wahrscheinlich auch nach der Zeit filtern wollen, um die Zeilen anzuzeigen, an denen Sie interessiert sind. Um beispielsweise zu überprüfen, wie der Dienst heute ausgeführt wird, können Sie eingeben:

      journalctl -u nginx.service --since today

      Diese Art der Fokussierung wird extrem hilfreich, wenn Sie die Fähigkeit des Journals nutzen, Datensätze aus verschiedenen Einheiten zusammenzuführen. Wenn Ihr Nginx-Prozess beispielsweise mit einer PHP-FPM-Einheit verbunden ist, um dynamischen Inhalt 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 wesentlich einfacher machen, die Interaktionen zwischen verschiedenen zu erkennen und System zu debuggen, anstatt einzelne Prozesse.

      Nach Prozess, Benutzer oder Gruppen-ID

      Einige Dienste spawnen eine Vielzahl von untergeordneten Prozesse, um die Arbeit zu erledigen. Wenn Sie die genaue PID des Prozesses, an dem Sie interessiert sind, ausgekundschaftet haben, können Sie auch nach dieser filtern.

      Dazu können wir durch Angabe des Feldes _PID filtern. Wenn die PID, an der wir interessiert sind, beispielsweise 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 Gruppe protokolliert wurden. Dies kann mit den Filtern _UID oder _GID geschehen. Wenn Ihr Webserver beispielsweise unter dem Benutzer www-data läuft, können Sie die Benutzer-ID finden, indem Sie eingeben:

      id -u www-data

      33

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

      journalctl _UID=33 --since today

      Das Journal systemd hat viele Felder, die für die Filterung verwendet werden können. Einige davon werden von dem zu protokollierenden Prozess übergeben und einige werden von journald anhand von Informationen angewendet, die es zum Zeitpunkt der Protokollierung aus dem System sammelt.

      Der führende Unterstrich gibt an, dass das Feld _PID von dem letzteren Typ ist. Das Journal zeichnet automatisch die PID des protokollierenden Prozesses auf und indexiert sie für spätere Filterungen. Sie können sich über alle verfügbaren Journalfelder informieren, indem Sie eingeben:

      man systemd.journal-fields

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

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

      journalctl -F _GID

      32
99
102
133
81
84
100
0
124
87

      Dies zeigt Ihnen alle Werte, die das Journal für das Feld Gruppen-ID gespeichert hat. Dies kann Ihnen beim Erstellen Ihrer Filter helfen.

      Nach Komponentenpfad

      Wir können auch filtern, indem wir eine Pfadposition bereitstellen.

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

      journalctl /usr/bin/bash

      Wenn eine Einheit für die ausführbare Datei verfügbar ist, ist diese Methode sauberer und bietet bessere Informationen (Einträge aus zugehörigen untergeordneten Prozessen usw.). Manchmal ist dies jedoch nicht möglich.

      Anzeigen von Kernel-Meldungen

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

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

      journalctl -k

      Standardmäßig werden damit die Kernel-Meldungen des aktuellen Bootvorgangs angezeigt. Sie können einen alternativen Bootvorgang angeben, indem Sie die zuvor besprochenen Boot-Auswahl-Flags verwenden. Um beispielsweise die Meldungen von vor fünf Bootvorgängen zu erhalten, könnten Sie eingeben:

      journalctl -k -b -5

      Nach Priorität

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

      Sie können journalctl verwenden, um nur Meldungen einer bestimmten Priorität oder höher anzuzeigen, indem Sie die Option -p verwenden. Dadurch können Sie Meldungen mit niedrigerer Priorität herausfiltern.

      Um beispielsweise nur Einträge anzuzeigen, die auf der Fehlerebene oder höher protokolliert wurden, können Sie eingeben:

      journalctl -p err -b

      Dies zeigt Ihnen alle Meldungen an, die als Fehler, kritisch, Alarm oder Notfall gekennzeichnet sind. Das Journal implementiert die Standard-syslog-Meldungsebenen. Sie können entweder den Namen der Priorität oder den entsprechenden numerischen Wert verwenden. In der Reihenfolge von höchster bis niedrigster Priorität sind dies:

      • 0: emerg (Notfall)
      • 1: alert (Alarm)
      • 2: crit (kritisch)
      • 3: err (Fehler)
      • 4: warning (Warnung)
      • 5: notice (Hinweis)
      • 6: info (Information)
      • 7: debug (Fehlersuche)

      Die vorstehenden Zahlen oder Namen können austauschbar mit der Option -p verwendet werden. Wenn Sie die Priorität auswählen, werden Meldungen angezeigt, die auf der angegebenen Ebene markiert sind, und solche, die darüber liegen.

      Ändern der Journalanzeige

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

      Kürzen oder Erweitern der Ausgabe

      Wir können anpassen, wie journalctl Daten anzeigt, indem wir ihn anweisen, die Ausgabe zu verkürzen oder zu erweitern.

      Standardmäßig zeigt journalctl den gesamten Eintrag in dem Pager an und lässt die Einträge rechts am Bildschirm auslaufen. Auf diese Informationen können Sie durch Drücken der rechten Pfeiltaste zugreifen.

      Wenn Sie die Ausgabe lieber gekürzt haben möchten, wobei an den Stellen, an denen Informationen entfernt wurden, eine Ellipse eingefügt wird, 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 damit auch in die entgegengesetzte Richtung gehen und journalctl anweisen, alle Informationen anzuzeigen, unabhängig davon, ob sie nicht druckbare Zeichen enthält. Wir können dies mit dem Flag -a tun:

      journalctl -a

      Ausgabe auf Standardausgabe

      Standardmäßig zeigt journalctl die Ausgabe in einem Pager an, um den Konsum zu erleichtern. Wenn Sie jedoch vorhaben, die Daten mit Textmanipulationswerkzeugen zu verarbeiten, möchten Sie wahrscheinlich in der Lage sein, auf die Standardausgabe auszugeben.

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

      journalctl --no-pager

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

      Ausgabeformate

      Wenn Sie, wie oben erwähnt, Journaleinträge verarbeiten, wird es Ihnen die Analyse der Daten wahrscheinlich leichter fallen, wenn sie in einem besser konsumierbaren Format vorliegen. Glücklicherweise kann das Journal in einer Vielzahl von Formaten angezeigt werden, wenn es erforderlich ist. Dazu können Sie die Option -o mit einem Formatbezeichner verwenden.

      Sie können die Journaleinträge beispielsweise in JSON ausgeben, indem Sie 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 Dienstprogrammen. Sie könnten das Format json-pretty verwenden, um die Datenstruktur besser in den Griff zu bekommen, bevor Sie sie an den JSON-Verbraucher übergeben:

      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 Meldungsfeld selbst an.
      • export: Ein Binärformat, das sich zum Übertragen oder Sichern eignet.
      • json: Standard-JSON mit einem Eintrag pro Zeile.
      • json-pretty: JSON, das für eine bessere menschliche Lesbarkeit formatiert ist.
      • json-sse: JSON-formatierte Ausgabe, die eingehüllt ist, um das Hinzufügen von vom Server gesendeten Ereignissen zu ermöglichen.
      • short: Die Standardausgabe im syslog-Stil.
      • short-iso: Das Standardformat, das zum Anzeigen von ISO-8601 Wallclock-Zeitstempeln erweitert wurde.
      • short-monotonic: Das Standardformat mit monotonen Zeitstempeln.
      • short-precise: Das Standardformat mit Mikrosekundengenauigkeit.
      • verbose: Zeigt jedes für den Eintrag verfügbare Journalfeld an, einschließlich derjenigen, die normalerweise intern verborgen sind.

      Mit diesen Optionen können Sie die Journaleinträge in dem Format anzeigen, das Ihren aktuellen Bedürfnissen am besten entspricht.

      Aktive Prozessüberwachung

      Der Befehl journalctl imitiert, wie viele Administratoren tail zur Überwachung der aktiven oder jüngsten Aktivität verwenden. Diese Funktionalität ist in journalctl eingebaut, sodass Sie auf diese Funktionen zugreifen können, ohne eine Pipe zu einem anderen Tool verwenden zu müssen.

      Anzeigen aktueller Protokolle

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

      Sie zeigt standardmäßig die letzten 10 Einträge an:

      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

      Verfolgen von Protokollen

      Um die Protokolle aktiv zu verfolgen, während sie geschrieben werden, können Sie das Flag -f verwenden. Auch dies funktioniert so, wie Sie es vielleicht erwarten, wenn Sie Erfahrung mit der Verwendung von tail -f haben:

      journalctl -f

      Journalwartung

      Vielleicht fragen Sie sich, was es kostet, all die Daten zu speichern, die wir bisher gesehen haben. Außerdem sind Sie vielleicht daran interessiert, einige ältere Protokolle aufzuräumen und Speicherplatz freizugeben.

      Ermitteln der aktuellen Festplattenbelegung

      Sie können herausfiden, wie viel Platz das Journal derzeit auf der Festplatte belegt, indem Sie das Flag --disk-usage verwenden:

      journalctl --disk-usage

      Journals take up 8.0M on disk.

      Löschen alter Protokolle

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

      Wenn Sie die Option --vacuum-size verwenden, können Sie Ihr Journal durch Angabe einer Größe verkleinern. Dadurch werden alte Einträge entfernt, bis der gesamte auf der Festplatte belegte Journal-Speicherplatz die angeforderte Größe erreicht hat:

      sudo journalctl --vacuum-size=1G

      Eine weitere Möglichkeit, das Journal zu verkleinern, ist die Angabe einer Sperrzeit mit der Option --vacuum-time. Alle Einträge, die über diese Zeit hinausgehen, werden gelöscht. Dadurch können Sie die Einträge behalten, die nach einer bestimmten Zeit erstellt wurden.

      Um beispielsweise Einträge aus dem letzten Jahr zu behalten, können Sie eingeben:

      sudo journalctl --vacuum-time=1years

      Begrenzen der Journal-Erweiterung

      Sie können Ihren Server so konfigurieren, dass er den Speicherplatz, den das Journal einnehmen kann, begrenzt. Dies kann durch die Bearbeitung der Datei /etc/systemd/journald.conf erfolgen.

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

      • SystemMaxUse=: Gibt den maximalen Festplattenplatz an, den das Journal im permanenten Speicher belegen kann.
      • SystemKeepFree=: Gibt den Speicherplatz an, den das Journal beim Hinzufügen von Journaleinträgen im permanenten Speicher frei lassen soll.
      • SystemMaxFileSize=: Kontrolliert, wie große einzelne Journaldateien im persistenten Speicher werden können, bevor sie rotiert werden.
      • RuntimeMaxUse=: Gibt den maximalen Festplattenspeicher an, der im flüchtigen Speicher (innerhalb des Dateisystems /run) verwendet werden kann.
      • RuntimeKeepFree=: Gibt an, wie viel Speicherplatz beim Schreiben von Daten in den flüchtigen Speicher (innerhalb des Dateisystems /run) für andere Verwendungen freigehalten werden soll.
      • RuntimeMaxFileSize=: Gibt an, wie viel Speicherplatz eine einzelne Journaldatei im flüchtigen Speicher (innerhalb des Dateisystems /run) einnehmen kann, bevor sie rotiert wird.

      Durch die Einstellung dieser Werte können Sie kontrollieren, wie journald den Speicherplatz auf Ihrem Server verbraucht und bewahrt. Denken Sie daran, dass SystemMaxFileSize und RuntimeMaxFileSize darauf abzielen, dass archivierte Dateien die angegebenen Grenzen erreichen. Dies ist wichtig zu bedenken, wenn Sie Dateizählungen nach einer Vakuum-Operation interpretieren.

      Zusammenfassung

      Wie Sie sehen können, ist das Journal systemd unglaublich nützlich für das Erfassen und Verwalten Ihrer System- und Anwendungsdaten. Die meiste Flexibilität ergibt sich aus den umfangreichen Metadaten, die automatisch aufgezeichnet werden, und der zentralisierten Natur des Protokolls. Der Befehl journalctl macht es einfach, die erweiterten Funktionen des Journals zu nutzen und umfangreiche Analysen und relationales Debugging verschiedener Anwendungskomponenten durchzuführen.



      Source link

      Verwenden der JavaScript-Fetch-API zum Abrufen von Daten


      Einführung

      Es gab eine Zeit, als XMLHttpRequest verwendet wurde, um API-Anfragen zu erstellen. Es enthielt keine Promises und sorgte nicht für einen sauberen JavaScript-Code. Mit jQuery verwendeten Sie die saubere Syntax mit jQuery.ajax().

      Jetzt verfügt JavaScript über eine eigene integrierte Möglichkeit, API-Anfragen zu erstellen. Dies ist die Fetch-API, ein neuer Standard, um Serveranfragen mit Promises zu erstellen, der aber noch viele andere Funktionen enthält.

      In diesem Tutorial erstellen Sie mit der Fetch-API sowohl GET- als auch POST-Anfragen.

      Voraussetzungen

      Um dieses Tutorial zu absolvieren, benötigen Sie Folgendes:

      Schritt 1 — Erste Schritte mit der Fetch-API-Syntax

      Um die Fetch-API zu verwenden, rufen Sie die Methode fetch auf, die die URL der API als Parameter akzeptiert:

      fetch(url)

      Fügen Sie nach der Methode fetch() die Promise-Methode then() ein:

      .then(function() {

})

      Die Methode fetch() gibt ein Promise zurück. Wenn das zurückgegebene Promise resolve ist, wird die Funktion innerhalb der Methode then() ausgeführt. Diese Funktion enthält den Code für die Handhabung der von der API empfangenen Daten.

      Fügen Sie unter der Methode then() die Methode catch() ein:

      .catch(function() {

});

      Die API, die Sie mit fetch() aufrufen, kann außer Betrieb sein oder es können andere Fehler auftreten. Wenn dies geschieht, wird das Promise reject zurückgegeben. Die Methode catch wird verwendet, um reject zu handhaben. Der Code innerhalb von catch() wird ausgeführt, wenn ein Fehler beim Aufruf der API Ihrer Wahl auftritt.

      Zusammengefasst sieht die Verwendung der Fetch-API wie folgt aus:

      fetch(url)
.then(function() {

})
.catch(function() {

});

      Mit einem Verständnis der Syntax zur Verwendung der Fetch-API können Sie nun mit der Verwendung von fetch() für eine echte API fortfahren.

      Schritt 2 — Verwenden von Fetch zum Abrufen von Daten aus einer API

      Die folgenden Codebeispiele basieren auf der Random User API. Mithilfe der API erhalten Sie zehn Benutzer und zeigen sie auf der Seite mit Vanilla JavaScript an.

      Die Idee ist, alle Daten von der Random User API zu erhalten und in Listenelementen innerhalb der Liste des Autors anzuzeigen. Beginnen Sie mit der Erstellung einer HTML-Datei und dem Hinzufügen einer Überschrift und einer ungeordneten Liste mit der id der authors:

      <h1>Authors</h1>
<ul id="authors"></ul>

      Fügen Sie nun script-Tags am Ende Ihrer HTML-Datei und verwenden Sie einen DOM-Selektor zum Ergreifen von ul. Verwenden Sie getElementById mit authors als Argument. Denken Sie daran: authors ist die id für die zuvor erstellte ul:

      <script>

    const ul = document.getElementById('authors');

</script>

      Erstellen Sie eine konstante Variable namens url, die die API enthält, die zehn zufällige Benutzer zurückgibt:

      const url="https://randomuser.me/api/?results=10";

      Mit erstellten ul und url ist es an der Zeit, die Funktionen zu erstellen, die zur Erstellung der Listenelemente verwendet werden. Erstellen Sie eine Funktion namens createNode, die einen Parameter namens element aufnimmt:

      function createNode(element) {

}

      Wenn createNode später aufgerufen wird, müssen Sie den Namen eines tatsächlichen HTML-Elements übergeben, das erstellt werden soll.

      Fügen Sie innerhalb der Funktion eine Anweisung return hinzu, die element unter Verwendung von document.createElement() zurückgibt:

      function createNode(element) {
    return document.createElement(element);
}

      Sie müssen auch eine Funktion namens append erstellen, die zwei Parameter aufnimmt: parent und el:

      function append(parent, el) {

}

      Diese Funktion fügt el an parent mit document.createElement an:

      function append(parent, el) {
    return parent.appendChild(el);
}

      Sowohl createNode als auch append sind einsatzbereit. Rufen Sie nun mit der Fetch-API die Random User API unter Verwendung von fetch() mit url als Argument auf:

      fetch(url)

      fetch(url)
  .then(function(data) {

    })
  })
  .catch(function(error) {

  });

      Im obigen Code rufen Sie die Fetch-API auf, und übergeben die URL an die Random User API. Dann wird eine Antwort empfangen. Die Antwort, die Sie erhalten, ist jedoch nicht JSON, sondern ein Objekt mit einer Reihe von Methoden, die je nachdem, was Sie mit den Informationen tun möchten, verwendet werden können. Um das zurückgegebene Objekt in JSON zu konvertieren, verwenden Sie die Methode json().

      Fügen Sie die Methode then() hinzu, die eine Funktion mit einem Parameter namens resp enthält:

      fetch(url)
.then((resp) => )

      Der Parameter resp nimmt den Wert des von fetch(url) zurückgegebenen Objekts an. Verwenden Sie die Methode json(), um resp in JSON-Daten zu konvertieren:

      fetch(url)
.then((resp) => resp.json())

      Die JSON-Daten müssen noch verarbeitet werden. Fügen Sie eine weitere Anweisung then() mit einer Funktion hinzu, die ein Argument namens data aufweist:

      .then(function(data) {

    })
})

      Erstellen Sie innerhalb dieser Funktion eine Variable namens authors, die gleich data.results gesetzt wird:

      .then(function(data) {
    let authors = data.results;

      Sie sollten für jeden Autor in authors ein Listenelement erstellen, das ein Bild und den Namen des Autors anzeigt. Dafür eignet sich die Methode map() hervorragend:

      let authors = data.results;
return authors.map(function(author) {

})

      Erstellen Sie innerhalb Ihrer Funktion map eine Variable namens li, die gleich createNode mit li (dem HTML-Element) als Argument gesetzt wird:

      return authors.map(function(author) {
    let li = createNode('li');
})

      Wiederholen Sie dies, um ein Element span und ein Element img zu erstellen:

      let li = createNode('li');
let img = createNode('img');
let span = createNode('span');

      Die API bietet einen Namen für den Autor und ein Bild, das zu diesem Namen gehört. Setzen Sie img.src auf das Bild des Autors:

      let img = createNode('img');
let span = createNode('span');

img.src = author.picture.medium;

      Das Element span sollte den Vor- und Nachnamen des author enthalten. Mit der Eigenschaft innerHTML und der String-Interpolation können Sie dies tun:

      img.src = author.picture.medium;
span.innerHTML = `${author.name.first} ${author.name.last}`;

      Mit dem Bild und dem Listenelement, die zusammen mit dem Element span erstellt wurden, können Sie die zuvor erstellte Funktion append verwenden, um diese Elemente auf der Seite anzuzeigen:

      append(li, img);
append(li, span);
append(ul, li);

      Da beide Funktionen then() abgeschlossen sind, können Sie nun die Funktion catch() hinzufügen. Diese Funktion protokolliert den potenziellen Fehler auf der Konsole:

      .catch(function(error) {
  console.log(error);
});

      Dies ist der vollständige Code der von Ihnen erstellten Anfrage:

      function createNode(element) {
    return document.createElement(element);
}

function append(parent, el) {
  return parent.appendChild(el);
}

const ul = document.getElementById('authors');
const url="https://randomuser.me/api/?results=10";

fetch(url)
.then((resp) => resp.json())
.then(function(data) {
  let authors = data.results;
  return authors.map(function(author) {
    let li = createNode('li');
    let img = createNode('img');
    let span = createNode('span');
    img.src = author.picture.medium;
    span.innerHTML = `${author.name.first} ${author.name.last}`;
    append(li, img);
    append(li, span);
    append(ul, li);
  })
})
.catch(function(error) {
  console.log(error);
});

      Sie haben gerade erfolgreich eine GET-Anfrage mit der Random User API und der Fetch-API durchgeführt. Im nächsten Schritt lernen Sie, wie Sie POST-Anfragen ausführen.

      Schritt 3 — Handhaben von POST-Anfragen

      Fetch ist standardmäßig auf GET-Anfragen eingestellt, doch Sie können auch alle anderen Arten von Anfragen verwenden, die Kopfzeilen ändern und Daten senden. Dazu müssen Sie Ihr Objekt festlegen und als zweites Argument der Funktion fetch übergeben.

      Erstellen Sie vor der Erstellung einer POST-Anfrage die Daten, die Sie an die API senden möchten. Dies wird ein Objekt namens data mit dem Schlüssel name und dem Wert Sammy (oder Ihrem Namen) sein:

      const url="https://randomuser.me/api";

let data = {
  name: 'Sammy'
}

      Stellen Sie sicher, dass Sie eine konstante Variable einfügen, die den Link der Random User API enthält.

      Da es sich um eine POST-Anfrage handelt, müssen Sie dies explizit angeben. Erstellen Sie ein Objekt namens fetchData:

      let fetchData = {

}

      Dieses Objekt muss drei Schlüssel enthalten: method, body und headers. Der Schlüssel method sollte den Wert 'POST' haben. body sollte gleich dem gerade erstellten Objekt data gesetzt werden. headers sollte den Wert von new Headers() haben:

      let fetchData = {
  method: 'POST',
  body: data,
  headers: new Headers()
}

      Die Schnittstelle Headers ist eine Eigenschaft der Fetch-API, mit der Sie verschiedene Aktionen für HTTP-Anfragen und Antwort-Header durchführen können. Wenn Sie mehr darüber erfahren möchten, finden Sie in diesem Artikel namens Definieren von Routen und HTTP-Anfragemethoden in Express weitere Informationen.

      Mit diesem Code kann die POST-Anfrage unter Verwendung der Fetch-API erstellt werden. Sie schließen url und fetchData als Argumente für Ihre POST-Anfrage fetch ein:

      fetch(url, fetchData)

      Die Funktion then() enthält Code, der die vom Random User API-Server empfangene Antwort verarbeitet:

      fetch(url, fetchData)
.then(function() {
    // Handle response you get from the server
});

      Es gibt auch eine andere Möglichkeit zur Erstellung eines Objekts und der Verwendung der Funktion fetch(). Anstatt ein Objekt wie fetchData zu erstellen, können Sie den Anfragekonstruktor verwenden, um Ihr Anfrageobjekt zu erstellen. Erstellen Sie dazu eine Variable namens request:

      const url="https://randomuser.me/api";

let data = {
  name: 'Sara'
}

var request =

      Die Variable request sollte gleich new Request gesetzt werden. Das Konstrukt new Request nimmt zwei Argumente an: die API-URL (url) und ein Objekt. Das Objekt sollte auch die Schlüssel method, body und headers enthalten, genau wie fetchData:

      var request = new Request(url, {
    method: 'POST',
    body: data,
    headers: new Headers()
});

      Jetzt kann request als einziges Argument für fetch() verwendet werden, da es auch die API-URL enthält:

      fetch(request)
.then(function() {
    // Handle response we get from the API
})

      Insgesamt sieht Ihr Code wie folgt aus:

      const url="https://randomuser.me/api";

let data = {
  name: 'Sara'
}

var request = new Request(url, {
    method: 'POST',
    body: data,
    headers: new Headers()
});

fetch(request)
.then(function() {
    // Handle response we get from the API
})

      Jetzt kennen Sie zwei Methoden zur Erstellung und Ausführung von POST-Anfragen mit der Fetch-API.

      Zusammenfassung

      Obwohl die Fetch-API noch nicht von allen Browsern unterstützt wird, ist sie eine gute Alternative zu XMLHttpRequest. Wenn Sie lernen möchten, wie Sie Web-APIs mit React aufrufen, lesen Sie diesen Artikel zu diesem Thema.



      Source link

      Forgot Your Password ?