systemdログを表示および操作するためのjournalctlの使い方

紹介

systemdの最も魅力的な利点のいくつかは、プロセスとシステムのログに関わるものです。他のツールを使用すると、ログは通常システム全体に分散され、異なるデーモンやプロセスによって処理され、複数のアプリケーションにまたがる場合は解釈が非常に難しくなります。systemdは、カーネルとユーザーランドプロセスのすべてのログを中央管理するソリューションを提供することで、これらの問題に対処しようとしています。これらのログを収集し管理するシステムは、ジャーナルとして知られています。

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

一般的なアイデア

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

これにより、私たちは多くの重要な利点を得ることができます。管理者は、単一のユーティリティを使用してデータと対話することで、必要に応じてログデータを動的に表示できます。これは、3回前のブートデータを表示することのようにシンプルであったり、2つの関連サービスからログエントリーを順次結合して通信問題をデバッグすることができます。

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

systemd ジャーナルは、既存の syslog 実装と共に使用することも、必要に応じて syslog 機能を置き換えることもできます。systemd ジャーナルはほとんどの管理者のログ記録のニーズを満たすことができますが、既存のログ記録メカニズムを補完することもできます。たとえば、複数のサーバーからデータを集約するために使用する中央集約型の syslog サーバーがあるかもしれませんが、systemd ジャーナルを使用して、単一のシステム上で複数のサービスのログを交互に記録したい場合もあります。これらの技術を組み合わせることで、両方のことを行うことができます。

システム時刻の設定

バイナリジャーナルを使用してログを記録する利点の一つは、任意の時刻にUTCまたはローカル時間でログ記録を表示できることです。デフォルトでは、systemdは結果をローカル時間で表示します。

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

まず、list-timezonesオプションを使ってどのタイムゾーンが利用可能か確認してください:

timedatectl list-timezones

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

sudo timedatectl set-timezone zone

現在マシンが正しい時間を使用していることを確認するには、timedatectl コマンドを単独で使用するか、status オプションとともに使用してください。表示は同じになります:

timedatectl status

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

最初の行には正しい時間を表示する必要があります。

基本ログ閲覧

journald デーモンが収集したログを見るには、journalctl コマンドを使用します。

単独で使用すると、システム内のすべてのジャーナルエントリがページャー（通常はless）内に表示され、ブラウズできます。最も古いエントリは上部に表示されます:

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

. . .

おそらく、何ページにもわたるデータをスクロールすることになるでしょう。もしsystemdがあなたのシステムに長い間存在していた場合、それは何万行、あるいは何十万行にも及ぶ可能性があります。これは、ジャーナルデータベースにどれだけのデータがあるかを示しています。

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

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

UTCでタイムスタンプを表示したい場合は、--utcフラグを使用できます。

journalctl --utc

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

このように大規模なデータコレクションにアクセスできることは確かに便利ですが、このような膨大な情報は手作業で検査したり処理することが難しい場合があります。このため、journalctl の最も重要な機能の1つは、そのフィルタリングオプションです。

現在のブートからのログを表示しています

日常的に使用する最も基本的なものは、-b フラグです。これを使用すると、最も最近の再起動以来収集されたすべてのジャーナルエントリが表示されます。

journalctl -b

これにより、現在の環境に関連する情報を特定し、管理するのに役立ちます。

この機能を使用していない場合で、複数日のブーツを表示していると、journalctlがシステムがダウンしたときにこのような行を挿入しているのがわかります:

. . .

-- Reboot --

. . .

これを使用して、情報を論理的にブートセッションに分けることができます。

過去のブーツ

現在のブートからの情報を表示したい場合が一般的ですが、過去のブートが役立つ場合も確かにあります。ジャーナルは多くの以前のブートから情報を保存できるため、journalctlを使用すると情報を簡単に表示できます。

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

sudo mkdir -p /var/log/journal

また、ジャーナル設定ファイルを編集することもできます:

sudo nano /etc/systemd/journald.conf

[Journal] セクションの下で、Storage= オプションを「persistent」に設定して、永続的なログ記録を有効にします:

. . .
[Journal]
Storage=persistent

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

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

これにより、各ブートに対して1行が表示されます。最初の列はブートのオフセットで、journalctlを使ってブートを簡単に参照できます。絶対的な参照が必要な場合、ブートIDは2列目にあります。ブートセッションが参照する時間は、最後の方にリストされた2つの時間指定でわかります。

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

例えば、前回のブートからのジャーナルを見るには、-bフラグとともに-1相対ポインタを使用します:

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"

このジャーナルは、一部の相対的な値や名前付きショートカットも理解しています。たとえば、「昨日」、「今日」、「明日」、「今」という言葉を使うことができます。また、番号付きの値の前に「-」や「+」を追加するか、「前」という言葉を文の構造に使うことで相対的な時間を表現できます。

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

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フィールドを指定してフィルタリングできます。たとえば、関心のあるPIDが8088の場合、次のように入力できます:

journalctl _PID=8088

他の時には、特定のユーザーまたはグループから記録されたすべてのエントリを表示したい場合があります。これは _UID または _GID フィルタを使用することで可能です。例えば、ウェブサーバーが www-data ユーザーの下で実行されている場合、ユーザーIDを見つけるには次のように入力します:

id -u www-data

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

journalctl _UID=33 --since today

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

先頭のアンダースコアは、_PID フィールドが後者のタイプであることを示しています。ジャーナルは、自動的にログを記録するプロセスの PID を記録し、後でフィルタリングできるようにインデックスを付けます。利用可能なジャーナルフィールドのすべてを知るには、次のように入力します:

man systemd.journal-fields

このガイドでは、これらのいくつかについて議論します。ただし、今のところ、これらのフィールドによるフィルタリングに関するもう1つの便利なオプションについて説明します。-Fオプションを使用すると、指定された雑誌フィールドの利用可能なすべての値を表示できます。

例えば、systemd ジャーナルがどのグループ ID のエントリを持っているかを見るためには、次のように入力します:

journalctl -F _GID

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

コンポーネントパスによって

パスの場所を提供することでフィルタリングすることもできます。

パスが実行可能ファイルに到達する場合、journalctlは対象の実行可能ファイルに関与するすべてのエントリを表示します。たとえば、bash実行可能ファイルに関与するエントリを見つけるには、次のように入力できます:

journalctl /usr/bin/bash

通常、実行可能なユニットが利用可能な場合、その方法はクリーンで、関連する子プロセスからのエントリなど、より良い情報を提供します。しかし、時には、これは不可能なこともあります。

カーネルメッセージを表示中

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

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

journalctl -k

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

journalctl -k -b -5

優先順位によって

システム管理者がしばしば関心を持つフィルターの一つは、メッセージの優先度です。非常に詳細なレベルで情報をログすることはしばしば有用ですが、実際に利用可能な情報を消化する際に、低優先度のログは気を散らす要因となり、混乱を招くことがあります。

journalctlを使用して、-pオプションを使うことで、指定された優先度以上のメッセージのみを表示できます。これにより、低い優先度のメッセージをフィルタリングできます。

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

journalctl -p err -b

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

0: 緊急
1: 警告
2: 批評
3: エラー
4: 警告
5: 通知
6: 情報
7: デバッグ

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

ジャーナル表示の修正

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

出力を切り捨てるか、拡張する

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

デフォルトでは、journalctlはページャーに全エントリを表示し、エントリが画面の右側に流れ込むことを許可します。この情報には右矢印キーを押すことでアクセスできます。

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

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

これにより、journalctlに対して、印刷できない文字が含まれているかどうかに関係なく、すべての情報を表示するよう指示することもできます。これは-aフラグを使って行います:

journalctl -a

標準出力に出力する

デフォルトでは、journalctlは出力をページャで表示して、より簡単に消費できるようにします。しかし、データをテキスト操作ツールで処理する予定がある場合は、標準出力に出力できるようにしたいと思うでしょう。

これは --no-pager オプションを使用して行うことができます:

journalctl --no-pager

これは、あなたのニーズに応じて、すぐに処理ユーティリティにパイプすることも、ディスク上のファイルにリダイレクトすることもできます。

出力フォーマット

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

例えば、次のように入力することで日記のエントリーをJSON形式で出力できます。

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" }

. . .

これはユーティリティを使って解析するのに役立ちます。JSONの消費者に渡す前にデータ構造を把握するために、json-prettyフォーマットを使用できます:

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"
}

. . .

表示には以下の形式を使用できます:

cat: メッセージフィールド自体のみを表示します。
エクスポート: 転送またはバックアップに適したバイナリ形式です。
json: 標準のJSONで、1行に1エントリです。
json-pretty: 人間が読みやすくするためにフォーマットされたJSON
json-sse: サーバー送信イベントに対応できるようにラップされたJSON形式の出力
ショート: デフォルトのsyslogスタイル出力
short-iso: ISO 8601の壁時計タイムスタンプを表示するために強化されたデフォルト形式。
短一様: 一様なタイムスタンプを持つデフォルト形式です。
短く正確: マイクロ秒精度のデフォルト形式
詳細: エントリーに利用可能なすべてのジャーナルフィールドを表示します。通常は内部で隠されているフィールドも含まれます。

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

アクティブプロセス監視

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

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

古いログを削除する

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

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

sudo journalctl --vacuum-size=1G

ジャーナルを縮小するもう一つの方法は、--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 コマンドを使用すると、ジャーナルの高度な機能を簡単に活用でき、異なるアプリケーションコンポーネントの徹底的な分析と関係のあるデバッグを行うことができます。