開発者ドキュメント

Journalctlを使用してSystemdログを表示および操作する方法

序章

の最も説得力のある利点のいくつか systemd プロセスとシステムのロギングに関係するものです。 他のツールを使用する場合、ログは通常、システム全体に分散され、さまざまなデーモンやプロセスによって処理され、複数のアプリケーションにまたがる場合、解釈がかなり困難になる可能性があります。 systemd すべてのカーネルおよびユーザーランドプロセスをログに記録するための集中管理ソリューションを提供することにより、これらの問題に対処しようとします。 これらのログを収集および管理するシステムは、journalと呼ばれます。

ジャーナルは、 journald デーモン。カーネル、initrd、サービスなどによって生成されたすべてのメッセージを処理します。 このガイドでは、使用方法について説明します journalctl ユーティリティ。ジャーナル内に保持されているデータにアクセスして操作するために使用できます。

一般的なアイデア

の背後にある推進力の1つ systemd ジャーナルは、メッセージの発信元に関係なく、ログの管理を一元化することです。 ブートプロセスとサービス管理の多くは、 systemd プロセスでは、ログの収集とアクセスの方法を標準化することは理にかなっています。 The journald デーモンは、利用可能なすべてのソースからデータを収集し、それらをバイナリ形式で保存して、簡単かつ動的に操作できるようにします。

これにより、多くの重要な利点が得られます。 管理者は、単一のユーティリティを使用してデータを操作することにより、ニーズに応じてログデータを動的に表示できます。 これは、3回の起動前の起動データを表示したり、2つの関連サービスからのログエントリを順番に組み合わせて通信の問題をデバッグしたりするのと同じくらい簡単です。

ログデータをバイナリ形式で保存するということは、現時点で必要なものに応じて、データを任意の出力形式で表示できることも意味します。 たとえば、毎日のログ管理では、標準でログを表示することに慣れている場合があります syslog 形式ですが、後でサービスの中断をグラフ化することにした場合は、各エントリをJSONオブジェクトとして出力して、グラフ化サービスで使用できるようにすることができます。 データはプレーンテキストでディスクに書き込まれないため、別のオンデマンド形式が必要な場合に変換する必要はありません。

The systemd ジャーナルは、既存のジャーナルと一緒に使用できます syslog 実装、またはそれを置き換えることができます syslog ニーズに応じて、機能。 ながら systemd ジャーナルは、ほとんどの管理者のロギングニーズをカバーし、既存のロギングメカニズムを補完することもできます。 たとえば、一元化されている場合があります syslog 複数のサーバーからのデータをコンパイルするために使用するサーバーですが、単一のシステム上の複数のサービスからのログをインターリーブしたい場合もあります。 systemd ジャーナル。 これらのテクノロジーを組み合わせることで、これらの両方を行うことができます。

システム時刻の設定

ロギングにバイナリジャーナルを使用する利点の1つは、ログレコードをUTCまたは現地時間で自由に表示できることです。 デフォルトでは、 systemd 結果は現地時間で表示されます。

このため、ジャーナルを開始する前に、タイムゾーンが正しく設定されていることを確認します。 The systemd スイートには実際にはと呼ばれるツールが付属しています timedatectl それはこれを助けることができます。

まず、どのタイムゾーンが利用可能かを確認します list-timezones オプション:

  1. timedatectl list-timezones

これにより、システムで使用可能なタイムゾーンが一覧表示されます。 サーバーの場所に一致するものを見つけたら、を使用して設定できます set-timezone オプション:

  1. sudo timedatectl set-timezone zone

マシンが現在正しい時刻を使用していることを確認するには、 timedatectl コマンドのみ、または status オプション。 表示は同じになります:

  1. timedatectl status
Output
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

最初の行には正しい時刻が表示されているはずです。

基本的なログ表示

ログを表示するには journald デーモンが収集しました。 journalctl 指図。

単独で使用すると、システム内のすべてのジャーナルエントリがポケットベル内に表示されます(通常は less)あなたが閲覧するために。 最も古いエントリが一番上に表示されます。

  1. journalctl
Output
-- 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 . . .

スクロールするページとデータのページがある可能性があります。これは、次の場合に数万行または数十万行の長さになる可能性があります。 systemd 長い間あなたのシステムにありました。 これは、ジャーナルデータベースで利用可能なデータの量を示しています。

このフォーマットは、標準に慣れている人にはおなじみです。 syslog ロギング。 ただし、これは実際には従来よりも多くのソースからデータを収集します syslog 実装は可能です。 これには、初期ブートプロセス、カーネル、initrd、およびアプリケーションの標準エラーと出力からのログが含まれます。 これらはすべてジャーナルで入手できます。

表示されているタイムスタンプはすべて現地時間であることに気付くかもしれません。 これは、システムで現地時間が正しく設定されているため、すべてのログエントリで使用できます。 すべてのログは、この新しい情報を使用して表示されます。

タイムスタンプをUTCで表示する場合は、 --utc 国旗:

  1. journalctl --utc

時間によるジャーナルフィルタリング

このような大量のデータにアクセスできることは確かに便利ですが、このような大量の情報を手動で検査および処理することは困難または不可能な場合があります。 このため、の最も重要な機能の1つ journalctl そのフィルタリングオプションです。

現在のブートからのログの表示

あなたが毎日使うかもしれないこれらの最も基本的なものは -b 国旗。 これにより、最後の再起動以降に収集されたすべてのジャーナルエントリが表示されます。

  1. journalctl -b

これは、現在の環境に関連する情報を識別および管理するのに役立ちます。

この機能を使用しておらず、1日以上のブーツを表示している場合は、次のように表示されます。 journalctl システムがダウンするたびに、次のような行を挿入しました。

Output
. . . -- Reboot -- . . .

これは、情報をブートセッションに論理的に分離するのに役立ちます。

過去のブーツ

通常、現在のブートからの情報を表示したい場合がありますが、過去のブートも役立つ場合があります。 ジャーナルは以前の多くのブーツからの情報を保存できるので、 journalctl 情報を簡単に表示させることができます。

一部のディストリビューションでは、デフォルトで以前のブート情報の保存が有効になっていますが、他のディストリビューションではこの機能が無効になっています。 永続的なブート情報を有効にするには、次のように入力して、ジャーナルを保存するディレクトリを作成します。

  1. sudo mkdir -p /var/log/journal

または、ジャーナル構成ファイルを編集できます。

  1. sudo nano /etc/systemd/journald.conf

[Journal] セクション、を設定します Storage= 永続的なロギングを有効にするための「永続的」へのオプション:

/etc/systemd/journald.conf
. . .
[Journal]
Storage=persistent

以前のブートの保存がサーバーで有効になっている場合、 journalctl 除算の単位としてブーツを操作するのに役立ついくつかのコマンドを提供します。 そのブーツを見るために journald 知っている、使用する --list-boots オプション付き journalctl:

journalctl --list-boots
Output
-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

これにより、ブートごとに1行が表示されます。 最初の列は、ブートを簡単に参照するために使用できるブートのオフセットです。 journalctl. 絶対参照が必要な場合、ブートIDは2番目の列にあります。 ブートセッションが参照する時刻は、最後にリストされている2つの時刻仕様でわかります。

これらのブーツからの情報を表示するには、1列目または2列目の情報を使用できます。

たとえば、前回の起動時のジャーナルを表示するには、 -1 との相対ポインタ -b 国旗:

  1. journalctl -b -1

ブートIDを使用して、ブートからデータをコールバックすることもできます。

  1. journalctl -b caf0524a1d394ce0bdbcff75b94444fe

時間ウィンドウ

ブートごとにログエントリを表示することは非常に便利ですが、多くの場合、システムブートとうまく整合しない時間枠を要求したい場合があります。 これは、稼働時間が長いサーバーを処理する場合に特に当てはまります。

を使用して任意の時間制限でフィルタリングできます --since--until オプション。表示されるエントリを、それぞれ指定された時間より後または前のエントリに制限します。

時間の値はさまざまな形式で提供されます。 絶対時間の値については、次の形式を使用する必要があります。

  1. YYYY-MM-DD HH:MM:SS

たとえば、2015年1月10日午後5時15分以降、次のように入力すると、すべてのエントリが表示されます。

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

上記の形式のコンポーネントを省略した場合、いくつかのデフォルトが適用されます。 たとえば、日付を省略すると、現在の日付が想定されます。 時間コンポーネントが欠落している場合は、「00:00:00」(深夜)に置き換えられます。 秒フィールドをオフのままにして、デフォルトで「00」にすることもできます。

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

ジャーナルは、いくつかの相対値と名前付きショートカットも理解します。 たとえば、「昨日」、「今日」、「明日」、「今」という言葉を使用できます。 番号付きの値の前に「-」または「+」を付けるか、文の構成に「ago」などの単語を使用することで、相対時間を行うことができます。

昨日のデータを取得するには、次のように入力します。

  1. journalctl --since yesterday

午前9時から始まり、1時間前まで続くサービス中断の報告を受け取った場合は、次のように入力できます。

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

ご覧のとおり、表示したいエントリをフィルタリングするための柔軟な時間枠を定義するのは比較的簡単です。

メッセージインタレストによるフィルタリング

上記では、時間制約を使用してジャーナルデータをフィルタリングする方法をいくつか学びました。 このセクションでは、関心のあるサービスまたはコンポーネントに基づいてフィルタリングする方法について説明します。 The systemd ジャーナルは、これを行うためのさまざまな方法を提供します。

ユニット別

おそらく、フィルタリングの最も便利な方法は、関心のあるユニットによるものです。 使用できます -u この方法でフィルタリングするオプション。

たとえば、システム上のNginxユニットからのすべてのログを表示するには、次のように入力します。

  1. journalctl -u nginx.service

通常、関心のある行を表示するために、時間でフィルタリングすることもできます。 たとえば、サービスが現在どのように実行されているかを確認するには、次のように入力します。

  1. journalctl -u nginx.service --since today

このタイプのフォーカスは、さまざまなユニットからのレコードをインターリーブするジャーナルの機能を利用するときに非常に役立ちます。 たとえば、動的コンテンツを処理するためにNginxプロセスがPHP-FPMユニットに接続されている場合、両方のユニットを指定することで、両方のエントリを時系列でマージできます。

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

これにより、個々のプロセスではなく、さまざまなプログラムとデバッグシステム間の相互作用を簡単に見つけることができます。

プロセス、ユーザー、またはグループID別

一部のサービスは、作業を行うためにさまざまな子プロセスを生成します。 関心のあるプロセスの正確なPIDをスカウトした場合は、それでフィルタリングすることもできます。

これを行うには、を指定してフィルタリングできます _PID 分野。 たとえば、関心のあるPIDが8088の場合、次のように入力できます。

  1. journalctl _PID=8088

また、特定のユーザーまたはグループからログに記録されたすべてのエントリを表示したい場合もあります。 これは、 _UID また _GID フィルタ。 たとえば、Webサーバーが www-data ユーザーの場合、次のように入力してユーザーIDを見つけることができます。

  1. id -u www-data
Output
33

その後、返されたIDを使用して、ジャーナルの結果をフィルタリングできます。

  1. journalctl _UID=33 --since today

The systemd ジャーナルには、フィルタリングに使用できる多くのフィールドがあります。 それらのいくつかはログに記録されているプロセスから渡され、いくつかはによって適用されます journald ログの時点でシステムから収集した情報を使用します。

先頭の下線は、 _PID フィールドは後者のタイプです。 ジャーナルは、後でフィルタリングするためにログに記録されているプロセスのPIDを自動的に記録し、インデックスを付けます。 次のように入力すると、使用可能なすべてのジャーナルフィールドについて確認できます。

  1. man systemd.journal-fields

このガイドでは、これらのいくつかについて説明します。 ただし、ここでは、これらのフィールドによるフィルタリングに関係するもう1つの便利なオプションについて説明します。 The -F オプションを使用して、特定のジャーナルフィールドで使用可能なすべての値を表示できます。

たとえば、どのグループIDを確認するには systemd ジャーナルには次のエントリがあります。次のように入力できます。

  1. journalctl -F _GID
Output
32 99 102 133 81 84 100 0 124 87

これにより、ジャーナルがグループIDフィールドに保存したすべての値が表示されます。 これは、フィルターを作成するのに役立ちます。

コンポーネントパス別

パスの場所を指定してフィルタリングすることもできます。

パスが実行可能ファイルにつながる場合、 journalctl 問題の実行可能ファイルに関連するすべてのエントリが表示されます。 たとえば、 bash 実行可能ファイルの場合、次のように入力できます。

  1. journalctl /usr/bin/bash

通常、実行可能ファイルでユニットが使用可能な場合、そのメソッドはよりクリーンで、より適切な情報(関連する子プロセスからのエントリなど)を提供します。 ただし、これが不可能な場合もあります。

カーネルメッセージの表示

カーネルメッセージ、通常は dmesg 出力は、ジャーナルからも取得できます。

これらのメッセージのみを表示するには、 -k また --dmesg コマンドへのフラグ:

  1. journalctl -k

デフォルトでは、これは現在のブートからのカーネルメッセージを表示します。 前に説明した通常のブート選択フラグを使用して、代替ブートを指定できます。 たとえば、5回前の起動からメッセージを取得するには、次のように入力します。

  1. journalctl -k -b -5

優先度別

システム管理者がよく関心を持つフィルターの1つは、メッセージの優先度です。 非常に詳細なレベルで情報をログに記録すると便利なことがよくありますが、実際に利用可能な情報を消化する場合、優先度の低いログは気が散って混乱する可能性があります。

使用できます journalctl 指定した優先度以上のメッセージのみを表示するには、 -p オプション。 これにより、優先度の低いメッセージを除外できます。

たとえば、エラーレベル以上でログに記録されたエントリのみを表示するには、次のように入力します。

  1. journalctl -p err -b

これにより、エラー、クリティカル、アラート、または緊急としてマークされたすべてのメッセージが表示されます。 ジャーナルは標準を実装します syslog メッセージレベル。 優先順位名またはそれに対応する数値のいずれかを使用できます。 優先度の高いものから低いものの順に、次のとおりです。

上記の番号または名前は、 -p オプション。 優先度を選択すると、指定したレベルとそれより上のレベルでマークされたメッセージが表示されます。

ジャーナル表示の変更

上記では、フィルタリングによるエントリの選択について説明しました。 ただし、出力を変更する方法は他にもあります。 調整できます journalctl さまざまなニーズに合わせて表示します。

出力を切り捨てまたは拡張する

方法を調整できます journalctl 出力を縮小または拡大するように指示してデータを表示します。

デフォルトでは、 journalctl エントリ全体がポケットベルに表示され、エントリが画面の右側に表示されます。 この情報には、右矢印キーを押すことでアクセスできます。

情報が削除された場所に省略記号を挿入して出力を切り捨てたい場合は、 --no-full オプション:

  1. journalctl --no-full
Output
. . . 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

これで反対方向に進んで伝えることもできます journalctl 印刷できない文字が含まれているかどうかに関係なく、すべての情報を表示します。 私たちはこれを行うことができます -a 国旗:

  1. journalctl -a

標準出力への出力

デフォルトでは、 journalctl 使いやすいように出力をポケットベルに表示します。 ただし、テキスト操作ツールを使用してデータを処理することを計画している場合は、標準出力に出力できるようにする必要があります。

あなたはこれを行うことができます --no-pager オプション:

  1. journalctl --no-pager

これは、必要に応じて、すぐに処理ユーティリティにパイプするか、ディスク上のファイルにリダイレクトすることができます。

出力フォーマット

上記のように、ジャーナルエントリを処理している場合、データがより消費可能な形式であると、データの解析が容易になる可能性があります。 幸い、ジャーナルは必要に応じてさまざまな形式で表示できます。 あなたはこれを使用して行うことができます -o フォーマット指定子付きのオプション。

たとえば、次のように入力して、ジャーナルエントリをJSONで出力できます。

  1. journalctl -b -u nginx -o json
Output
{ "__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" } . . .

これは、ユーティリティを使用した解析に役立ちます。 あなたは使用することができます json-pretty JSONコンシューマーに渡す前に、データ構造をより適切に処理するための形式:

  1. journalctl -b -u nginx -o json-pretty
Output
{ "__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" } . . .

次の形式を表示に使用できます。

これらのオプションを使用すると、現在のニーズに最適な形式でジャーナルエントリを表示できます。

アクティブプロセスモニタリング

The journalctl コマンドは、使用する管理者の数を模倣します tail アクティブまたは最近のアクティビティを監視します。 この機能はに組み込まれています journalctl、別のツールにパイプすることなく、これらの機能にアクセスできます。

最近のログの表示

設定された量のレコードを表示するには、 -n オプション、これはまったく同じように機能します tail -n.

デフォルトでは、最新の10個のエントリが表示されます。

  1. journalctl -n

表示したいエントリの数を、後の数字で指定できます。 -n:

  1. journalctl -n 20

次のログ

書き込まれているログを積極的に追跡するには、 -f 国旗。 繰り返しますが、これは、使用経験がある場合に期待できるように機能します tail -f:

  1. journalctl -f

このコマンドを終了するには、次のように入力します CTRL+C.

ジャーナルのメンテナンス

これまでに見たすべてのデータを保存するためのコストについて疑問に思われるかもしれません。 さらに、古いログをクリーンアップしてスペースを解放することに興味があるかもしれません。

現在のディスク使用量の検索

ジャーナルを使用して、ジャーナルが現在ディスク上で占有しているスペースの量を確認できます。 --disk-usage 国旗:

  1. journalctl --disk-usage
Output
Archived and active journals take up 8.0M in the file system.

古いログの削除

ジャーナルを縮小したい場合は、2つの異なる方法でそれを行うことができます( systemd バージョン218以降)。

を使用する場合 --vacuum-size オプションで、サイズを指定してジャーナルを縮小できます。 これにより、ディスク上で占有されているジャーナル領域の合計が要求されたサイズになるまで、古いエントリが削除されます。

  1. sudo journalctl --vacuum-size=1G

ジャーナルを縮小できるもう1つの方法は、 --vacuum-time オプション。 それ以降のエントリはすべて削除されます。 これにより、特定の時間後に作成されたエントリを保持できます。

たとえば、昨年のエントリを保持するには、次のように入力します。

  1. sudo journalctl --vacuum-time=1years

ジャーナル拡張の制限

ジャーナルが占有できるスペースの量を制限するようにサーバーを構成できます。 これは、編集することによって行うことができます /etc/systemd/journald.conf ファイル。

次の項目を使用して、ジャーナルの成長を制限できます。

これらの値を設定することにより、方法を制御できます journald サーバー上のスペースを消費して保存します。 それを念頭に置いて SystemMaxFileSizeRuntimeMaxFileSize アーカイブされたファイルをターゲットにして、指定された制限に到達します。 これは、バキューム操作後にファイル数を解釈するときに覚えておくことが重要です。

結論

ご覧のとおり、 systemd ジャーナルは、システムとアプリケーションのデータを収集および管理するのに非常に役立ちます。 柔軟性のほとんどは、自動的に記録された広範なメタデータとログの集中化された性質に由来します。 The journalctl コマンドを使用すると、ジャーナルの高度な機能を簡単に利用でき、さまざまなアプリケーションコンポーネントの広範な分析とリレーショナルデバッグを実行できます。

モバイルバージョンを終了