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
オプション:
- timedatectl list-timezones
これにより、システムで使用可能なタイムゾーンが一覧表示されます。 サーバーの場所に一致するものを見つけたら、を使用して設定できます set-timezone
オプション:
- sudo timedatectl set-timezone zone
マシンが現在正しい時刻を使用していることを確認するには、 timedatectl
コマンドのみ、または status
オプション。 表示は同じになります:
- 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
)あなたが閲覧するために。 最も古いエントリが一番上に表示されます。
- 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
国旗:
- journalctl --utc
時間によるジャーナルフィルタリング
このような大量のデータにアクセスできることは確かに便利ですが、このような大量の情報を手動で検査および処理することは困難または不可能な場合があります。 このため、の最も重要な機能の1つ journalctl
そのフィルタリングオプションです。
現在のブートからのログの表示
あなたが毎日使うかもしれないこれらの最も基本的なものは -b
国旗。 これにより、最後の再起動以降に収集されたすべてのジャーナルエントリが表示されます。
- journalctl -b
これは、現在の環境に関連する情報を識別および管理するのに役立ちます。
この機能を使用しておらず、1日以上のブーツを表示している場合は、次のように表示されます。 journalctl
システムがダウンするたびに、次のような行を挿入しました。
Output. . .
-- Reboot --
. . .
これは、情報をブートセッションに論理的に分離するのに役立ちます。
過去のブーツ
通常、現在のブートからの情報を表示したい場合がありますが、過去のブートも役立つ場合があります。 ジャーナルは以前の多くのブーツからの情報を保存できるので、 journalctl
情報を簡単に表示させることができます。
一部のディストリビューションでは、デフォルトで以前のブート情報の保存が有効になっていますが、他のディストリビューションではこの機能が無効になっています。 永続的なブート情報を有効にするには、次のように入力して、ジャーナルを保存するディレクトリを作成します。
- sudo mkdir -p /var/log/journal
または、ジャーナル構成ファイルを編集できます。
- sudo nano /etc/systemd/journald.conf
下 [Journal]
セクション、を設定します Storage=
永続的なロギングを有効にするための「永続的」へのオプション:
. . .
[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
国旗:
- journalctl -b -1
ブートIDを使用して、ブートからデータをコールバックすることもできます。
- journalctl -b caf0524a1d394ce0bdbcff75b94444fe
時間ウィンドウ
ブートごとにログエントリを表示することは非常に便利ですが、多くの場合、システムブートとうまく整合しない時間枠を要求したい場合があります。 これは、稼働時間が長いサーバーを処理する場合に特に当てはまります。
を使用して任意の時間制限でフィルタリングできます --since
と --until
オプション。表示されるエントリを、それぞれ指定された時間より後または前のエントリに制限します。
時間の値はさまざまな形式で提供されます。 絶対時間の値については、次の形式を使用する必要があります。
- YYYY-MM-DD HH:MM:SS
たとえば、2015年1月10日午後5時15分以降、次のように入力すると、すべてのエントリが表示されます。
- journalctl --since "2015-01-10 17:15:00"
上記の形式のコンポーネントを省略した場合、いくつかのデフォルトが適用されます。 たとえば、日付を省略すると、現在の日付が想定されます。 時間コンポーネントが欠落している場合は、「00:00:00」(深夜)に置き換えられます。 秒フィールドをオフのままにして、デフォルトで「00」にすることもできます。
- journalctl --since "2015-01-10" --until "2015-01-11 03:00"
ジャーナルは、いくつかの相対値と名前付きショートカットも理解します。 たとえば、「昨日」、「今日」、「明日」、「今」という言葉を使用できます。 番号付きの値の前に「-」または「+」を付けるか、文の構成に「ago」などの単語を使用することで、相対時間を行うことができます。
昨日のデータを取得するには、次のように入力します。
- journalctl --since yesterday
午前9時から始まり、1時間前まで続くサービス中断の報告を受け取った場合は、次のように入力できます。
- journalctl --since 09:00 --until "1 hour ago"
ご覧のとおり、表示したいエントリをフィルタリングするための柔軟な時間枠を定義するのは比較的簡単です。
メッセージインタレストによるフィルタリング
上記では、時間制約を使用してジャーナルデータをフィルタリングする方法をいくつか学びました。 このセクションでは、関心のあるサービスまたはコンポーネントに基づいてフィルタリングする方法について説明します。 The systemd
ジャーナルは、これを行うためのさまざまな方法を提供します。
ユニット別
おそらく、フィルタリングの最も便利な方法は、関心のあるユニットによるものです。 使用できます -u
この方法でフィルタリングするオプション。
たとえば、システム上のNginxユニットからのすべてのログを表示するには、次のように入力します。
- journalctl -u nginx.service
通常、関心のある行を表示するために、時間でフィルタリングすることもできます。 たとえば、サービスが現在どのように実行されているかを確認するには、次のように入力します。
- journalctl -u nginx.service --since today
このタイプのフォーカスは、さまざまなユニットからのレコードをインターリーブするジャーナルの機能を利用するときに非常に役立ちます。 たとえば、動的コンテンツを処理するためにNginxプロセスがPHP-FPMユニットに接続されている場合、両方のユニットを指定することで、両方のエントリを時系列でマージできます。
- journalctl -u nginx.service -u php-fpm.service --since today
これにより、個々のプロセスではなく、さまざまなプログラムとデバッグシステム間の相互作用を簡単に見つけることができます。
プロセス、ユーザー、またはグループID別
一部のサービスは、作業を行うためにさまざまな子プロセスを生成します。 関心のあるプロセスの正確なPIDをスカウトした場合は、それでフィルタリングすることもできます。
これを行うには、を指定してフィルタリングできます _PID
分野。 たとえば、関心のあるPIDが8088の場合、次のように入力できます。
- journalctl _PID=8088
また、特定のユーザーまたはグループからログに記録されたすべてのエントリを表示したい場合もあります。 これは、 _UID
また _GID
フィルタ。 たとえば、Webサーバーが www-data
ユーザーの場合、次のように入力してユーザーIDを見つけることができます。
- id -u www-data
Output33
その後、返されたIDを使用して、ジャーナルの結果をフィルタリングできます。
- journalctl _UID=33 --since today
The systemd
ジャーナルには、フィルタリングに使用できる多くのフィールドがあります。 それらのいくつかはログに記録されているプロセスから渡され、いくつかはによって適用されます journald
ログの時点でシステムから収集した情報を使用します。
先頭の下線は、 _PID
フィールドは後者のタイプです。 ジャーナルは、後でフィルタリングするためにログに記録されているプロセスのPIDを自動的に記録し、インデックスを付けます。 次のように入力すると、使用可能なすべてのジャーナルフィールドについて確認できます。
- man systemd.journal-fields
このガイドでは、これらのいくつかについて説明します。 ただし、ここでは、これらのフィールドによるフィルタリングに関係するもう1つの便利なオプションについて説明します。 The -F
オプションを使用して、特定のジャーナルフィールドで使用可能なすべての値を表示できます。
たとえば、どのグループIDを確認するには systemd
ジャーナルには次のエントリがあります。次のように入力できます。
- journalctl -F _GID
Output32
99
102
133
81
84
100
0
124
87
これにより、ジャーナルがグループIDフィールドに保存したすべての値が表示されます。 これは、フィルターを作成するのに役立ちます。
コンポーネントパス別
パスの場所を指定してフィルタリングすることもできます。
パスが実行可能ファイルにつながる場合、 journalctl
問題の実行可能ファイルに関連するすべてのエントリが表示されます。 たとえば、 bash
実行可能ファイルの場合、次のように入力できます。
- journalctl /usr/bin/bash
通常、実行可能ファイルでユニットが使用可能な場合、そのメソッドはよりクリーンで、より適切な情報(関連する子プロセスからのエントリなど)を提供します。 ただし、これが不可能な場合もあります。
カーネルメッセージの表示
カーネルメッセージ、通常は dmesg
出力は、ジャーナルからも取得できます。
これらのメッセージのみを表示するには、 -k
また --dmesg
コマンドへのフラグ:
- journalctl -k
デフォルトでは、これは現在のブートからのカーネルメッセージを表示します。 前に説明した通常のブート選択フラグを使用して、代替ブートを指定できます。 たとえば、5回前の起動からメッセージを取得するには、次のように入力します。
- journalctl -k -b -5
優先度別
システム管理者がよく関心を持つフィルターの1つは、メッセージの優先度です。 非常に詳細なレベルで情報をログに記録すると便利なことがよくありますが、実際に利用可能な情報を消化する場合、優先度の低いログは気が散って混乱する可能性があります。
使用できます journalctl
指定した優先度以上のメッセージのみを表示するには、 -p
オプション。 これにより、優先度の低いメッセージを除外できます。
たとえば、エラーレベル以上でログに記録されたエントリのみを表示するには、次のように入力します。
- journalctl -p err -b
これにより、エラー、クリティカル、アラート、または緊急としてマークされたすべてのメッセージが表示されます。 ジャーナルは標準を実装します syslog
メッセージレベル。 優先順位名またはそれに対応する数値のいずれかを使用できます。 優先度の高いものから低いものの順に、次のとおりです。
- 0 :emerg
- 1 :アラート
- 2 :クリティカル
- 3 :エラー
- 4 :警告
- 5 :通知
- 6 :情報
- 7 :デバッグ
上記の番号または名前は、 -p
オプション。 優先度を選択すると、指定したレベルとそれより上のレベルでマークされたメッセージが表示されます。
ジャーナル表示の変更
上記では、フィルタリングによるエントリの選択について説明しました。 ただし、出力を変更する方法は他にもあります。 調整できます journalctl
さまざまなニーズに合わせて表示します。
出力を切り捨てまたは拡張する
方法を調整できます journalctl
出力を縮小または拡大するように指示してデータを表示します。
デフォルトでは、 journalctl
エントリ全体がポケットベルに表示され、エントリが画面の右側に表示されます。 この情報には、右矢印キーを押すことでアクセスできます。
情報が削除された場所に省略記号を挿入して出力を切り捨てたい場合は、 --no-full
オプション:
- 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
国旗:
- journalctl -a
標準出力への出力
デフォルトでは、 journalctl
使いやすいように出力をポケットベルに表示します。 ただし、テキスト操作ツールを使用してデータを処理することを計画している場合は、標準出力に出力できるようにする必要があります。
あなたはこれを行うことができます --no-pager
オプション:
- journalctl --no-pager
これは、必要に応じて、すぐに処理ユーティリティにパイプするか、ディスク上のファイルにリダイレクトすることができます。
出力フォーマット
上記のように、ジャーナルエントリを処理している場合、データがより消費可能な形式であると、データの解析が容易になる可能性があります。 幸い、ジャーナルは必要に応じてさまざまな形式で表示できます。 あなたはこれを使用して行うことができます -o
フォーマット指定子付きのオプション。
たとえば、次のように入力して、ジャーナルエントリをJSONで出力できます。
- 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コンシューマーに渡す前に、データ構造をより適切に処理するための形式:
- 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"
}
. . .
次の形式を表示に使用できます。
- cat :メッセージフィールド自体のみを表示します。
- export :転送またはバックアップに適したバイナリ形式。
- json :1行に1つのエントリを持つ標準のJSON。
- json-pretty :人間が読みやすいようにフォーマットされたJSON
- json-sse :サーバー送信イベントの追加と互換性を持たせるためにラップされたJSON形式の出力
- short :デフォルト
syslog
スタイル出力 - short-iso :ISO8601ウォールクロックタイムスタンプを表示するように拡張されたデフォルトの形式。
- short-monotonic :単調なタイムスタンプを持つデフォルトの形式。
- short-precise :マイクロ秒精度のデフォルト形式
- verbose :通常は内部で非表示になっているものも含め、エントリで使用可能なすべてのジャーナルフィールドを表示します。
これらのオプションを使用すると、現在のニーズに最適な形式でジャーナルエントリを表示できます。
アクティブプロセスモニタリング
The journalctl
コマンドは、使用する管理者の数を模倣します tail
アクティブまたは最近のアクティビティを監視します。 この機能はに組み込まれています journalctl
、別のツールにパイプすることなく、これらの機能にアクセスできます。
最近のログの表示
設定された量のレコードを表示するには、 -n
オプション、これはまったく同じように機能します tail -n
.
デフォルトでは、最新の10個のエントリが表示されます。
- journalctl -n
表示したいエントリの数を、後の数字で指定できます。 -n
:
- journalctl -n 20
次のログ
書き込まれているログを積極的に追跡するには、 -f
国旗。 繰り返しますが、これは、使用経験がある場合に期待できるように機能します tail -f
:
- journalctl -f
このコマンドを終了するには、次のように入力します CTRL+C
.
ジャーナルのメンテナンス
これまでに見たすべてのデータを保存するためのコストについて疑問に思われるかもしれません。 さらに、古いログをクリーンアップしてスペースを解放することに興味があるかもしれません。
現在のディスク使用量の検索
ジャーナルを使用して、ジャーナルが現在ディスク上で占有しているスペースの量を確認できます。 --disk-usage
国旗:
- journalctl --disk-usage
OutputArchived and active journals take up 8.0M in the file system.
古いログの削除
ジャーナルを縮小したい場合は、2つの異なる方法でそれを行うことができます( systemd
バージョン218以降)。
を使用する場合 --vacuum-size
オプションで、サイズを指定してジャーナルを縮小できます。 これにより、ディスク上で占有されているジャーナル領域の合計が要求されたサイズになるまで、古いエントリが削除されます。
- sudo journalctl --vacuum-size=1G
ジャーナルを縮小できるもう1つの方法は、 --vacuum-time
オプション。 それ以降のエントリはすべて削除されます。 これにより、特定の時間後に作成されたエントリを保持できます。
たとえば、昨年のエントリを保持するには、次のように入力します。
- sudo journalctl --vacuum-time=1years
ジャーナル拡張の制限
ジャーナルが占有できるスペースの量を制限するようにサーバーを構成できます。 これは、編集することによって行うことができます /etc/systemd/journald.conf
ファイル。
次の項目を使用して、ジャーナルの成長を制限できます。
SystemMaxUse=
:永続記憶域でジャーナルが使用できる最大ディスク容量を指定します。SystemKeepFree=
:ジャーナル項目を永続ストレージに追加するときにジャーナルが空けるスペースの量を指定します。SystemMaxFileSize=
:ローテーションされる前に、永続ストレージで個々のジャーナルファイルのサイズを制御します。RuntimeMaxUse=
:揮発性ストレージで使用できる最大ディスク容量を指定します(/run
ファイルシステム)。RuntimeKeepFree=
:揮発性ストレージにデータを書き込むときに他の用途のために確保するスペースの量を指定します(/run
ファイルシステム)。RuntimeMaxFileSize=
:個々のジャーナルファイルが揮発性ストレージで占有できるスペースの量を指定します(/run
ファイルシステム)ローテーションする前。
これらの値を設定することにより、方法を制御できます journald
サーバー上のスペースを消費して保存します。 それを念頭に置いて SystemMaxFileSize
と RuntimeMaxFileSize
アーカイブされたファイルをターゲットにして、指定された制限に到達します。 これは、バキューム操作後にファイル数を解釈するときに覚えておくことが重要です。
結論
ご覧のとおり、 systemd
ジャーナルは、システムとアプリケーションのデータを収集および管理するのに非常に役立ちます。 柔軟性のほとんどは、自動的に記録された広範なメタデータとログの集中化された性質に由来します。 The journalctl
コマンドを使用すると、ジャーナルの高度な機能を簡単に利用でき、さまざまなアプリケーションコンポーネントの広範な分析とリレーショナルデバッグを実行できます。