journalctlでシステム障害を素早く切り分ける｜タイムライン取得からエラー集約まで

障害発生直後に何を見るか――journalctlが起点になる理由

サービスが突然停止したとき、多くの運用担当者がまず /var/log/syslog や /var/log/messages を開こうとします。しかし現行のsystemd環境では、それらのファイルへの書き出し自体が無効化されているディストリビューションが増えています。Ubuntu 24.04 LTS・RHEL 9系・Fedora 38以降では、rsyslogを別途インストールしない限り /var/log/messages は存在せず、すべてのログはsystemd-journaldが一元管理しています。障害発生時の「ログがない」という混乱は、多くの場合この前提のずれから生じています。

journalctlはjournaldのログを参照する公式ツールです。単なるログ閲覧コマンドではなく、時刻・優先度・ユニット・起動セッション・カーネルメッセージといった複数軸での絞り込みを組み合わせることで、障害のタイムラインを短時間で組み立てられます。本記事では「サービスが応答しなくなった」「再起動後に起動しないユニットがある」「夜間バッチが失敗した」という3つの運用シナリオを念頭に、実践的な手順を整理します。

タイムラインを組み立てる――時刻範囲とリアルタイム追跡

障害の「いつ」を特定する最初のステップは、時刻範囲を絞った全体ログの確認です。監視アラートやユーザー報告に記載された時刻を基準に、前後15〜30分のウィンドウを指定します。

# 特定時刻範囲のログを取得（ISO 8601形式）
journalctl --since "2026-08-08 03:00:00" --until "2026-08-08 03:30:00"

# 相対指定も使える（過去1時間）
journalctl --since "1 hour ago"

# リアルタイムで追跡（tail -fに相当）
journalctl -f

--since と --until の組み合わせは、ログ量の多い本番環境では必須です。指定なしで実行するとシステム起動から現在までの全ログが出力されるため、画面スクロールの手間が増えるだけでなく、重要なエラーを見落とすリスクが高まります。

出力は標準でページャー（less）に渡されます。検索は /キーワード、次候補は n、前候補は N で移動できます。ページャーを無効化してgrepにパイプしたい場合は --no-pager を付けます。

# grepに渡してエラー行だけ抽出
journalctl --since "1 hour ago" --no-pager | grep -i "error\|failed\|critical"

優先度フィルターでエラーを集約する

journaldはsyslogの優先度体系（0=emerg〜7=debug）をそのまま使っています。障害調査で最初に確認すべきは優先度3（err）以上です。-p オプションで上限を指定すると、それ以上の重要度のログだけに絞れます。

# err（3）以上のログのみ表示（emerg/alert/crit/errが対象）
journalctl -p err --since "2026-08-08 00:00:00"

# 数値ではなく名前でも指定可能
journalctl -p warning --since "today"

# 範囲指定（warning〜err）
journalctl -p 3..4 --since "1 hour ago"

優先度フィルターは全ユニットをまたいでエラーを集約できるため、「何かがおかしいが原因ユニットが不明」という状況の最初の一手として有効です。ここで複数のユニットにまたがるエラーが確認できた場合は、依存関係の問題を疑います。たとえばデータベースサービスが先に落ちており、それに依存するWebアプリが連鎖停止しているケースは現場でよく見られます。

2026年時点でsystemd 256以降を搭載したディストリビューション（Fedora 41・Ubuntu 25.04など）では、journalctl --priority= という長形式オプションも受け付けます。どちらの形式も機能は同等ですが、スクリプト内では可読性のために長形式が推奨されます。

ユニット・プロセスで絞り込む――原因サービスの特定

優先度フィルターで怪しいユニットの見当がついたら、そのユニットのログだけを抽出します。-u オプションがユニット指定の基本形です。

# 特定ユニットのログ
journalctl -u nginx.service --since "1 hour ago"

# 複数ユニットを同時指定（systemd 230以降）
journalctl -u nginx.service -u php-fpm.service --since "1 hour ago"

# ユニット名にワイルドカードを使う（systemd 244以降）
journalctl -u "mysql*" --since "today"

プロセスIDが判明している場合は _PID= フィールドで絞れます。コンテナ環境やcronジョブのように、systemdユニットとして管理されていないプロセスのログを追いたいときに便利です。

# PIDで絞り込む
journalctl _PID=12345

# コマンド名で絞り込む
journalctl _COMM=python3 --since "2026-08-08 02:00:00"

カーネルメッセージ（dmesg相当）を確認したい場合は -k オプションを使います。OOMキラーの発動・NICのリンクダウン・ファイルシステムエラーなど、ユーザースペースのサービスには記録されないハードウェアやカーネルレベルの問題は、ここで初めて把握できます。

# カーネルログのみ表示
journalctl -k --since "1 hour ago"

# カーネルログからOOM関連を抽出
journalctl -k --since "1 hour ago" --no-pager | grep -i "oom\|killed"

起動セッション単位で追う――再起動後の比較検証

サーバーが再起動を繰り返している状況や、「前回起動時は問題なかったが今回の起動後から異常が出ている」というケースでは、起動セッション（boot）単位の絞り込みが有効です。

# 過去の起動セッション一覧を確認
journalctl --list-boots

# 現在の起動セッションのログ
journalctl -b 0

# 一つ前の起動セッション
journalctl -b -1

# 2回前の起動セッション
journalctl -b -2

--list-boots の出力にはセッションID・開始時刻・終了時刻が並びます。異常終了した起動は終了時刻が途切れているか、次の起動開始時刻との間隔が短すぎることで判別できます。パニックや強制電源断の痕跡をここで確認できます。

前回の正常起動と今回の異常起動を比較するには、対象ユニットを指定した上でセッションを切り替えます。

# 正常だった前回起動のnginxログ
journalctl -b -1 -u nginx.service -p err

# 今回起動のnginxログ
journalctl -b 0 -u nginx.service -p err

エラーの有無・エラー内容の差異が一目で比較でき、設定変更や依存パッケージの更新が原因かどうかの仮説を立てやすくなります。

出力形式の活用と2026年現行環境での注意点

journalctlの出力形式は -o オプションで切り替えられます。ログを他のツールに渡したり、長期保存したりする際に使い分けます。

# JSON形式（jqと組み合わせて構造化解析）
journalctl -u nginx.service --since "1 hour ago" -o json | jq '.MESSAGE'

# タイムスタンプを短縮形式で表示
journalctl -o short-monotonic --since "1 hour ago"

# カタログ形式（エラーの説明文も表示）
journalctl -x -u systemd-networkd.service

-x（--catalog）オプションは、systemdが持つエラーカタログと照合し、エラーコードの説明文を合わせて表示します。「このエラーコードが何を意味するか調べる」という手間が省け、初動の仮説立てがしやすくなります。

2026年時点でのディストリビューション差分として押さえておきたい点が2つあります。第一に、journaldのストレージ設定です。デフォルトで永続ストレージ（/var/log/journal/）が有効になっているディストリビューションと、揮発性ストレージ（/run/log/journal/、再起動で消える）のままのものが混在しています。RHEL 9はデフォルト永続、Ubuntu 22.04以前はデフォルト揮発性、Ubuntu 24.04からはデフォルト永続に変わっています。/etc/systemd/journald.conf の Storage= 設定を確認してください。

# 現在のjournald設定確認
systemd-analyze cat-config systemd/journald.conf | grep Storage

# ログの保存先と使用容量確認
journalctl --disk-usage

第二に、systemd 255以降で追加された journalctl --cursor-file オプションです。ログ監視スクリプトで「前回読んだ位置から続きを取得する」処理を実装する際、ファイルにカーソル位置を保存して再開できるようになりました。cronやシェルスクリプトでのログ差分集計を自動化する際に活用できます。

ログの保持期間や容量上限は journald.conf の SystemMaxUse=・MaxRetentionSec= で制御します。デフォルトではディスクの10%程度が上限となっているため、本番環境では意図的に設定値を確認しておくことが推奨されます。障害調査の直前にローテーションで消えてしまうケースを防ぐためです。

journalctlは単体でも強力ですが、systemctl status ユニット名 との組み合わせが実務での定石です。systemctl status は直近のログ数行とユニットの状態遷移を同時に表示するため、「まず状態確認、詳細はjournalctlで深掘り」という流れが障害初動の基本パターンになります。