journalctlのベストプラクティス：効率的なログ管理術 🪵

まず、journald と journalctl の関係性を理解しましょう。

• systemd-journald (journald): これはsystemdの一部であり、バックグラウンドで動作するデーモンです。カーネル、各種systemdサービス、標準出力/エラー出力など、様々なソースからのログメッセージを一元的に収集し、通常は /var/log/journal/ または /run/log/journal/ ディレクトリ内にバイナリ形式で保存します。構造化され、インデックス化されているため、高速な検索が可能です。
• journalctl: これは、journald が収集・保存したログ（ジャーナル）を閲覧・操作するためのコマンドラインユーティリティです。多彩なフィルタリングオプションや出力形式を提供し、管理者が求める情報を効率的に抽出する手助けをします。

デフォルトでは、一般ユーザーは自身が実行したプロセスのログしか閲覧できません。システム全体のログ（他のユーザーやシステムサービスのログを含む）を閲覧するには、通常 adm または systemd-journal グループに所属している必要があります。アクセス権がない場合、以下のようなメッセージが表示されることがあります。

Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.

必要に応じて、usermod コマンドなどでユーザーを適切なグループに追加してください（変更後は再ログインが必要です）。

sudo usermod -aG systemd-journal your_username

まずは基本的な使い方から見ていきましょう。

• すべてのログを表示:

  journalctl

  最も基本的なコマンドです。ジャーナルに保存されているすべてのログエントリを古い順に表示します。ログが多い場合は、less のようなページャーで表示されます（スペースキーでページ送り、qキーで終了）。

• 逆順（最新ログから）表示:

  journalctl -r

  -r (--reverse) オプションを使うと、最新のログから順に表示されます。トラブルシューティング時にはこちらの方が便利なことが多いです。

• 最新のログ N 行を表示:

  journalctl -n 20

  -n (--lines) オプションで、表示する行数を指定できます。上記は最新の20行を表示します。デフォルトは10行です。

• リアルタイムでログを追跡:

  journalctl -f

  -f (--follow) オプションは tail -f と同様の機能を提供します。新しいログが追加されるたびにリアルタイムで表示します。特定のサービスの動作確認などに非常に便利です。Ctrl+Cで停止します。

• ページャーを使わずに出力:

  journalctl --no-pager

  出力を grep や他のコマンドにパイプする場合や、スクリプトで処理する場合に便利です。

• カーネルメッセージのみ表示 (dmesg相当):

  journalctl -k

  -k (--dmesg) オプションで、カーネルリングバッファのメッセージのみを表示します。

journalctl の真価は、強力なフィルタリング機能にあります。ログの中から必要な情報だけを効率的に絞り込むためのベストプラクティスを紹介します。異なるオプションを組み合わせるとAND条件、同一オプションを複数指定するとOR条件になります。

3.1. ユニット（サービス）によるフィルタリング

特定のサービスやユニットに関連するログだけを表示するのは、最もよく使われるフィルタリング方法です。

# 特定のサービス (例: nginx.service) のログを表示
journalctl -u nginx.service

# 複数のサービス (例: nginx と php-fpm) のログをOR条件で表示
journalctl -u nginx.service -u php-fpm.service

# サービス名でワイルドカードを使用 (例: ssh で始まるサービス)
journalctl -u 'ssh*'

# 特定の実行ファイル名でフィルタ (例: /usr/sbin/sshd)
journalctl /usr/sbin/sshd

# systemdのユニット識別子フィールド (_SYSTEMD_UNIT) でフィルタ (より正確)
journalctl _SYSTEMD_UNIT=nginx.service

3.2. 時間によるフィルタリング

特定の時間範囲のログを抽出することも非常に重要です。

# 特定の日付以降のログを表示 (例: 2025年3月30日以降)
journalctl --since "2025-03-30"

# 特定の日時以降のログを表示 (例: 2025年3月30日 10:00:00 以降)
journalctl --since "2025-03-30 10:00:00"

# 特定の日時までのログを表示 (例: 2025年3月30日 11:00:00 まで)
journalctl --until "2025-03-30 11:00:00"

# 特定の時間範囲のログを表示
journalctl --since "2025-03-30 10:00:00" --until "2025-03-30 11:00:00"

# 相対的な時間指定も可能 (例: 1時間前から現在まで)
journalctl --since "1 hour ago"

# 相対的な時間指定 (例: 昨日から今日まで)
journalctl --since yesterday --until today

# 特定の期間 (例: 9時から1時間前まで)
journalctl --since 09:00 --until "1 hour ago"

3.3. 優先度（プライオリティ）によるフィルタリング

ログメッセージには重要度を示す優先度レベルが付与されています。エラーや警告など、特定のレベル以上のログに絞り込むことができます。

# エラー (err) レベル以上のログを表示 (emerg, alert, crit, err)
journalctl -p err

# 警告 (warning) レベル以上のログを表示 (emerg, alert, crit, err, warning)
journalctl -p warning

# 特定の優先度レベルのみ表示 (例: notice のみ)
journalctl -p notice

# 優先度レベルの範囲を指定 (例: err から warning まで)
journalctl -p err..warning
journalctl -p 3..4 # 数字でも指定可能

優先度レベルは以下の通りです（数字が小さいほど重要度が高い）。

3.4. ブートセッションによるフィルタリング

システム起動ごとのログを確認できます。

# 現在のブートセッションのログを表示
journalctl -b

# 1つ前のブートセッションのログを表示
journalctl -b -1

# 5つ前のブートセッションのログを表示
journalctl -b -5

# 利用可能なブートセッションの一覧を表示
journalctl --list-boots

--list-boots の出力例:

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -2 336d9d0421ce44d59aadcaf2de634e92 Fri 2018-06-01 12:50:57 JST—Tue 2018-06-05 10:15:33 JST
 -1 676a0fbbf09948bcbb18e5f61d27f51b Tue 2018-06-05 11:28:20 JST—Tue 2018-06-05 13:55:23 JST
  0 92feec044ea94d88a6f95548df223f80 Wed 2018-06-06 00:51:40 JST—Wed 2018-06-06 00:57:37 JST

IDX列の数値 (相対オフセット) または BOOT ID (一意なID) を -b オプションに指定できます。

3.5. その他のフィールドによるフィルタリング

journaldはログメッセージに多くのメタデータフィールドを付与しています。これらを使ってさらに細かくフィルタリングできます。

# 特定のプロセスID (PID) でフィルタ
journalctl _PID=1234

# 特定のユーザーID (UID) でフィルタ (例: UID 1000 のユーザー)
journalctl _UID=1000

# 特定のグループID (GID) でフィルタ
journalctl _GID=100

# 特定の実行ファイルパスでフィルタ
journalctl _EXE=/usr/sbin/sshd

# 特定のホスト名でフィルタ (リモートジャーナル受信時などに有効)
journalctl _HOSTNAME=webserver01

# 特定の Syslog タグでフィルタ
journalctl -t myapptag

3.6. フィルタの組み合わせ

これらのフィルタリングオプションは自由に組み合わせることができます。

# nginx サービスの、昨日以降のエラーレベル以上のログを表示
journalctl -u nginx.service --since yesterday -p err

# 現在のブートで、PID 1234 のプロセスが出力したログをリアルタイム表示
journalctl -b -f _PID=1234

journalctl は、ログの出力形式を様々に変更できます。分析や他のツールとの連携に役立ちます。-o (--output) オプションで指定します。

• short (デフォルト):

  伝統的なsyslog形式に近い、人間が読みやすい形式。

  journalctl -n 5 -o short

• short-iso:

  short形式にISO 8601形式のタイムスタンプを追加。

  journalctl -n 5 -o short-iso

• short-precise:

  short形式にマイクロ秒単位の精度を持つタイムスタンプを追加。

  journalctl -n 5 -o short-precise

• short-monotonic:

  short形式にモノトニックタイムスタンプ（起動時からの経過時間）を追加。dmesg の出力に似ています。

  journalctl -k -b -n 5 -o short-monotonic

• verbose:

  ジャーナルエントリに含まれるすべてのフィールドを表示。非常に詳細な情報が必要な場合に。

  journalctl -n 1 -o verbose

• json:

  各ログエントリを1行のJSONオブジェクトとして出力。プログラムでの処理やログ収集ツールへの転送に適しています。

  journalctl -n 5 -o json

• json-pretty:

  人間が読みやすいように整形された（インデント、改行付き）JSON形式で出力。

  journalctl -n 5 -o json-pretty

• export:

  ジャーナルデータを他のシステムに転送したり、バックアップしたりするのに適したバイナリ形式。

  journalctl -o export > journal_export.log

• cat:

  メッセージ本文のみを出力。メタデータは表示されません。

  journalctl -n 5 -o cat

特定のフィールドだけを選択してカスタムフォーマットで出力することも可能です (systemd v247以降)。

journalctl --output-fields=__REALTIME_TIMESTAMP,_SYSTEMD_UNIT,_PID,MESSAGE -n 5

journalctl の挙動やログの保存方法は、journald の設定ファイル (通常は /etc/systemd/journald.conf または /etc/systemd/journald.conf.d/*.conf) で制御できます。設定を変更した後は、systemctl restart systemd-journald でサービスを再起動する必要があります。

5.1. ログの永続化 (Storage)

デフォルトの挙動はディストリビューションによって異なりますが、ログを再起動後も保持するかどうかは重要な設定です。

• Storage=volatile: ログはメモリ上 (/run/log/journal/) にのみ保存され、再起動時に失われます。
• Storage=persistent: ログはディスク上 (/var/log/journal/) に永続的に保存されます。このディレクトリが存在しない場合は自動的に作成されます (古いsystemdバージョンでは手動作成が必要な場合あり)。
• Storage=auto (多くのディストリビューションでのデフォルト): /var/log/journal/ ディレクトリが存在すれば persistent として動作し、存在しなければ volatile として動作します。
• Storage=none: ログは保存されません（ドロップされます）。転送設定が有効な場合のみ意味があります。

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

[Journal]
Storage=persistent

5.2. ディスク使用量の制限

ログがディスクを圧迫しないように、最大使用量を設定することが重要です。

• SystemMaxUse=: 永続ストレージ (/var/log/journal) の最大合計サイズ。例: 4G (4 GiB), 500M (500 MiB)。デフォルトは通常、ファイルシステムの10%か4GiBの小さい方。
• SystemKeepFree=: 永続ストレージが存在するファイルシステムで、最低限確保しておく空き容量。例: 1G, 15%。デフォルトは通常、ファイルシステムの15%か4GiBの小さい方。
• SystemMaxFileSize=: 個々のジャーナルファイル（ローテーションされる単位）の最大サイズ。例: 100M。デフォルトは SystemMaxUse の 1/8 程度。
• SystemMaxFiles=: 保持するジャーナルファイルの最大数。例: 100。デフォルトは 100。
• RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles=: 揮発性ストレージ (/run/log/journal) に対する同様の設定。

[Journal]
Storage=persistent
SystemMaxUse=4G
SystemKeepFree=1G
SystemMaxFileSize=128M

現在のディスク使用量は以下のコマンドで確認できます。

journalctl --disk-usage

手動で古いログを削除（掃除）することも可能です。

# 指定したサイズになるまで古いログを削除 (例: 500MBまで削減)
sudo journalctl --vacuum-size=500M

# 指定した期間より古いログを削除 (例: 2週間より古いログ)
sudo journalctl --vacuum-time=2weeks

# 保持するジャーナルファイルの数を指定 (例: 10ファイルにする)
sudo journalctl --vacuum-files=10

5.3. レート制限

特定のサービスが大量のログを短時間に出力し、システムに負荷をかけたり、重要なログを押し流したりするのを防ぎます。

• RateLimitIntervalSec=: レート制限を評価する時間間隔（秒）。デフォルトは 30s。
• RateLimitBurst=: 上記の時間間隔内に許容されるログメッセージの最大数。デフォルトは 10000。

[Journal]
RateLimitIntervalSec=30s
RateLimitBurst=20000

5.4. 圧縮 (Compress)

ディスク容量を節約するために、ジャーナルファイルを圧縮するかどうかを設定します。

• Compress=yes (デフォルト): 一定サイズ（デフォルトでは512バイト）より大きいログエントリを圧縮します (XZアルゴリズム)。
• Compress=no: 圧縮しません。

5.5. 転送 (Forwarding)

journaldが受け取ったログを他のロギングシステムに転送するかどうかを設定します。

• ForwardToSyslog=yes/no: ローカルのsyslogデーモン (rsyslogdなど) の /run/systemd/journal/syslog ソケットに転送します。
• ForwardToKMsg=yes/no: カーネルログバッファ (/dev/kmsg) に転送します。
• ForwardToConsole=yes/no: システムコンソール (/dev/console) に転送します。コンソールに表示するログレベルは ConsoleLevel= で指定できます。
• ForwardToWall=yes/no: wall コマンドのように、ログイン中の全ユーザーの端末にメッセージを送信します。WallLevel= でレベルを指定できます。

5.6. シーリング (Seal)

ログの改ざんを検知するために、Forward Secure Sealing (FSS) を使用してジャーナルファイルに暗号署名を追加します。

• Seal=yes/no: シーリングを有効/無効にします。有効にするには、systemd-journald-server.pem と systemd-journald-server.key が /etc/systemd/journal-upload.conf などで適切に設定されている必要があります（主にログ転送機能 systemd-journal-upload と連携する場合）。ローカルでの改ざん検知にはキーペアは不要で、起動ごとに生成されるキーが使われます。

[Journal]
Seal=yes

• 効率的なクエリ: ジャーナルが大きくなると、フィルタなしの journalctl や広範囲の時間指定は遅くなる可能性があります。可能な限り具体的なフィルタ（-u, -p, --since/--until, _PID など）を使用してください。
• ディスクI/O: 大量のログ書き込みはディスクI/Oのボトルネックになる可能性があります。特に低速なストレージを使用している場合は注意が必要です。journald.conf の設定（特にサイズ制限）を適切に行い、過剰なログ出力をするアプリケーションがないか監視しましょう。
• 定期的なメンテナンス: journalctl --disk-usage で定期的にディスク使用量を確認し、必要に応じて journalctl --vacuum-size や --vacuum-time で古いログを削除する運用を検討しましょう。cronジョブなどで自動化することも可能です。
• インデックス: journaldはログにインデックスを付与するため、grep でテキストファイルを検索するよりも一般的に高速です。journalctl --verify はインデックスを含むファイルの整合性もチェックします。
• ログローテーション: journaldは設定に基づいて自動的にログローテーションを行います（古いファイルを削除またはアーカイブ）。従来の logrotate のような外部ツールは通常不要です。手動でローテーションをトリガーしたい場合は journalctl --rotate コマンドが使えます。
• メモリ使用量: journaldプロセス自体のメモリ使用量も監視対象です。SystemMaxFileSize を小さく設定することで、メモリ使用量を抑えられる場合があります。

• ブートパフォーマンス分析: systemd-analyze blame は、各ユニットの起動にかかった時間を表示します。これはジャーナルデータを利用しています。
• ジャーナルの整合性チェック:

  journalctl --verify

  ジャーナルファイルが破損していないか、改ざんされていないか（Seal=yesの場合）をチェックします。

• 特定のマシンIDのジャーナルを表示 (コンテナなど): 特定のコンテナや仮想マシンのジャーナルファイルを直接指定して表示できます。

  journalctl --file /path/to/some/system.journal
  journalctl --directory /var/log/journal/MACHINE_ID/

• ログエクスポートとインポート: -o export でエクスポートしたログは、他のマシンで systemd-journal-remote などを使ってインポートしたり、journalctl --file= で直接読み込んだりできます。
• ログの中央集約: 複数のサーバーのログを一箇所で管理したい場合は、systemd-journal-upload や systemd-journal-remote といったツール、またはFluentd, Logstash, Promtailなどのログ収集エージェントと連携することを検討します。これらはjournaldからログを読み取り、中央のログサーバー（Elasticsearch, Loki, Splunkなど）に転送できます。
• シェルからのログ出力: systemd-cat コマンドを使うと、スクリプトやコマンドの標準出力・標準エラー出力を直接ジャーナルに送ることができます。タグ付けなども可能です。

  echo "Hello Journal" | systemd-cat -t my-script -p info

• アクセス制御: ジャーナルファイル (/var/log/journal/*) へのアクセス権は適切に管理されるべきです。通常、root ユーザーと systemd-journal グループのみが読み取りアクセス権を持ちます。機密情報を含む可能性があるため、アクセスは必要最小限のユーザーに限定してください。
• ログの完全性: 前述の Seal=yes 設定と journalctl --verify により、ログの改ざんを検知できます。
• 機密情報のマスキング: アプリケーションがパスワードや個人情報などの機密データをログに出力しないように注意が必要です。やむを得ず出力される場合は、ログ転送前や保存時にマスキング処理を行うなどの対策を検討してください。
• ログの監視: セキュリティ侵害の兆候（不正ログイン試行、異常なプロセス起動など）がないか、ログを定期的に監視することが重要です。これには、ログ分析ツールやSIEM (Security Information and Event Management) システムの活用が有効です。

journalctl は、systemd環境におけるログ管理の中核をなす強力なツールです。この記事で紹介したベストプラクティスを活用することで、システムの状態把握、迅速なトラブルシューティング、効率的なリソース管理が可能になります。

これらのベストプラクティスは、単一のサーバー管理から大規模なシステム運用まで、あらゆる場面で役立ちます。ぜひ、ご自身の環境に合わせて設定を見直し、journalctl コマンドを日常の運用に積極的に取り入れてみてください。ログはシステムの”声”です。その声を正しく、効率的に聞く技術を磨くことは、安定したシステム運用に不可欠です。 Happy logging! 😊