Journalctlを使用してSystemdログを表示および操作する方法
序章
systemdの最も魅力的な利点のいくつかは、プロセスとシステムのロギングに関係するものです。 他のツールを使用する場合、ログは通常、システム全体に分散され、さまざまなデーモンやプロセスによって処理され、複数のアプリケーションにまたがる場合、解釈がかなり困難になる可能性があります。 systemdは、すべてのカーネルおよびユーザーランドプロセスをログに記録するための集中管理ソリューションを提供することにより、これらの問題に対処しようとします。 これらのログを収集および管理するシステムは、journalと呼ばれます。
ジャーナルは、journaldデーモンで実装されます。このデーモンは、カーネル、initrd、サービスなどによって生成されたすべてのメッセージを処理します。 このガイドでは、ジャーナル内に保持されているデータにアクセスして操作するために使用できるjournalctlユーティリティの使用方法について説明します。
一般的なアイデア
systemdジャーナルの背後にある推進力の1つは、メッセージの発信元に関係なく、ログの管理を一元化することです。 起動プロセスとサービス管理の多くはsystemdプロセスによって処理されるため、ログの収集とアクセスの方法を標準化することは理にかなっています。 journaldデーモンは、利用可能なすべてのソースからデータを収集し、それらをバイナリ形式で保存して、簡単かつ動的に操作できるようにします。
これにより、多くの重要な利点が得られます。 管理者は、単一のユーティリティを使用してデータを操作することにより、ニーズに応じてログデータを動的に表示できます。 これは、3回の起動前の起動データを表示したり、2つの関連サービスからのログエントリを順番に組み合わせて通信の問題をデバッグしたりするのと同じくらい簡単です。
ログデータをバイナリ形式で保存するということは、現時点で必要なものに応じて、データを任意の出力形式で表示できることも意味します。 たとえば、毎日のログ管理では、標準のsyslog形式でログを表示することに慣れている場合がありますが、後でサービスの中断をグラフ化する場合は、各エントリをJSONオブジェクトとして出力して消費可能にすることができますグラフ作成サービスに。 データはプレーンテキストでディスクに書き込まれないため、別のオンデマンド形式が必要な場合に変換する必要はありません。
systemdジャーナルは、必要に応じて、既存のsyslog実装で使用することも、syslog機能を置き換えることもできます。 systemdジャーナルは、ほとんどの管理者のロギングニーズをカバーしますが、既存のロギングメカニズムを補完することもできます。 たとえば、複数のサーバーからのデータをコンパイルするために使用する集中型のsyslogサーバーがある場合でも、systemdジャーナルを使用して単一システム上の複数のサービスからのログをインターリーブしたい場合があります。 。 これらのテクノロジーを組み合わせることで、これらの両方を行うことができます。
システム時刻の設定
ロギングにバイナリジャーナルを使用する利点の1つは、ログレコードをUTCまたは現地時間で自由に表示できることです。 デフォルトでは、systemdは現地時間で結果を表示します。
このため、ジャーナルを開始する前に、タイムゾーンが正しく設定されていることを確認します。 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
時間によるジャーナルフィルタリング
このような大量のデータにアクセスできることは確かに便利ですが、このような大量の情報を手動で検査および処理することは困難または不可能な場合があります。 このため、journalctlの最も重要な機能の1つは、フィルタリングオプションです。
現在のブートからのログの表示
毎日使用する可能性のあるこれらの中で最も基本的なものは、-bフラグです。 これにより、最後の再起動以降に収集されたすべてのジャーナルエントリが表示されます。
journalctl -b
これは、現在の環境に関連する情報を識別および管理するのに役立ちます。
この機能を使用しておらず、1日以上の起動を表示している場合は、システムがダウンするたびにjournalctlが次のような行を挿入していることがわかります。
Output. . . -- Reboot -- . . .
これは、情報をブートセッションに論理的に分離するのに役立ちます。
過去のブーツ
通常、現在のブートからの情報を表示したい場合がありますが、過去のブートも役立つ場合があります。 ジャーナルは以前の多くのブーツからの情報を保存できるので、journalctlに情報を簡単に表示させることができます。
一部のディストリビューションでは、デフォルトで以前のブート情報の保存が有効になっていますが、他のディストリビューションではこの機能が無効になっています。 永続的なブート情報を有効にするには、次のように入力して、ジャーナルを保存するディレクトリを作成します。
sudo mkdir -p /var/log/journal
または、ジャーナル構成ファイルを編集できます。
sudo nano /etc/systemd/journald.conf
[Journal]セクションで、Storage=オプションを「永続的」に設定して、永続的なロギングを有効にします。
/etc/systemd/journald.conf
. . . [Journal] Storage=persistent
以前のブーツの保存がサーバーで有効になっている場合、journalctlは、分割の単位としてブーツを操作するのに役立ついくつかのコマンドを提供します。 journaldが認識しているブーツを確認するには、journalctlで--list-bootsオプションを使用します。
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"
ご覧のとおり、表示したいエントリをフィルタリングするための柔軟な時間枠を定義するのは比較的簡単です。
メッセージインタレストによるフィルタリング
上記では、時間制約を使用してジャーナルデータをフィルタリングする方法をいくつか学びました。 このセクションでは、関心のあるサービスまたはコンポーネントに基づいてフィルタリングする方法について説明します。 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
systemdジャーナルには、フィルタリングに使用できる多くのフィールドがあります。 それらのいくつかは、ログに記録されているプロセスから渡され、いくつかは、ログの時点でシステムから収集した情報を使用してjournaldによって適用されます。
先頭の下線は、_PIDフィールドが後者のタイプであることを示しています。 ジャーナルは、後でフィルタリングするためにログに記録されているプロセスのPIDを自動的に記録し、インデックスを付けます。 次のように入力すると、使用可能なすべてのジャーナルフィールドについて確認できます。
man systemd.journal-fields
このガイドでは、これらのいくつかについて説明します。 ただし、ここでは、これらのフィールドによるフィルタリングに関係するもう1つの便利なオプションについて説明します。 -Fオプションを使用して、特定のジャーナルフィールドで使用可能なすべての値を表示できます。
たとえば、systemdジャーナルにエントリがあるグループIDを確認するには、次のように入力します。
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 ：通常は内部で非表示になっているものも含め、エントリで使用可能なすべてのジャーナルフィールドを表示します。
これらのオプションを使用すると、現在のニーズに最適な形式でジャーナルエントリを表示できます。
アクティブプロセスモニタリング
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ジャーナルは、システムとアプリケーションのデータを収集および管理するのに非常に役立ちます。 柔軟性のほとんどは、自動的に記録された広範なメタデータとログの集中化された性質に由来します。 journalctlコマンドを使用すると、ジャーナルの高度な機能を簡単に利用でき、さまざまなアプリケーションコンポーネントの広範な分析とリレーショナルデバッグを実行できます。
