journalctlでsystemdログを調査する障害対応入門
障害発生時はまずjournalctl -u <対象ユニット> --since "10 minutes ago"を実行し、直近のログから原因の手がかりを絞り込んでください。systemd環境ではサービスのエラーがsyslogだけでなくjournalに集約されるため、journalctlの操作を押さえておくと切り分けの速度が大きく変わります。本記事では、journalctlの基本操作から障害調査での実践的な使い方、混同しやすいオプションの違い、原因特定を早めるための着眼点までをまとめます。CentOS・Ubuntu・Debianなど主要ディストリビューションで共通する内容を中心に扱いますが、オプションの挙動はsystemdのバージョンによって差異があるため、詳細は各ディストリビューションの公式ドキュメントやmanページで確認しながら作業を進めてください。
ログ確認の基本操作
journalctlはsystemdが管理するジャーナルログを検索・表示するコマンドで、単体で実行すると起動時からの全ログが古い順に表示されます。障害調査ではログ量が膨大になりやすいため、表示範囲を絞る操作を最初に覚えておくと作業がスムーズになります。
表示範囲を絞る
時間で絞り込む場合は--sinceと--untilを組み合わせます。たとえば直近1時間分だけを見たい場合はjournalctl --since "1 hour ago"、特定の日時範囲であればjournalctl --since "2026-08-27 09:00:00" --until "2026-08-27 09:30:00"のように指定します。直近のログだけをリアルタイムで追いたい場合はjournalctl -fを使うと、tail -fと同じ感覚で新規行を追跡できます。障害の再現待ちで監視する場面では、この-fオプションが役立つ場面が多くあります。
優先度でフィルタする
ログ量を絞るもう一つの方法が優先度フィルタです。-pオプションに0〜7の数値、またはemerg・alert・crit・err・warning・notice・info・debugのいずれかを指定できます。エラー以上だけを見たい場合はjournalctl -p errとすれば、正常系の情報ログをスキップして問題箇所に近いログだけを抽出できます。数値指定では-p 3がerr以上に相当し、優先度の数字が小さいほど深刻度が高い点に注意が必要です。
障害調査の実践手順
サービス障害の一次切り分けでは、対象ユニットの状態確認とログ確認をセットで行う流れが基本になります。ここでは実際の障害対応でよく使う手順を紹介します。
起動失敗ユニットを追う
サービスが起動しない、あるいは起動直後に落ちる場合は、まずsystemctl status <unit名>で概要を確認し、続けてjournalctl -u <unit名> --no-pager -n 100で直近100行を取得します。エラーコードや例外メッセージがここに出力されるため、スタックトレースやexit codeの数値をメモしておくと、後で公式ドキュメントやアプリケーション側のエラーコード一覧と突き合わせる際に役立ちます。起動直後に再起動を繰り返しているサービスでは、直近の起動分だけを見たい場面が多く、journalctl -u <unit名> -bで今回起動分に絞ると余計な過去ログが混ざりません。
複数ユニットを横断する
アプリケーションサーバー、リバースプロキシ、DBなど複数のサービスが連携している構成では、単一ユニットのログだけでは原因が見えないことがあります。その場合はjournalctl -u nginx.service -u app.service --since "09:00" --until "09:10"のように、複数の-uを並べて指定すると、時系列で混在表示され、どのサービスがどのタイミングでエラーを出したかを一目で比較できます。タイムスタンプのずれがある場合はサーバー間の時刻同期状況も併せて確認してください。
主要オプション比較表
journalctlにはオプションが数多く用意されていますが、障害調査で使う頻度が高いものは限られます。目的別に整理すると選択に迷いにくくなります。
| 目的 | オプション例 | 用途 |
|---|---|---|
| 時間で絞る | –since / –until | 特定期間のログだけを抽出する |
| 優先度で絞る | -p err / -p 3 | エラー以上の重大度のみ表示する |
| ユニット指定 | -u <unit名> | 特定サービスのログのみ表示する |
| 今回起動分 | -b / -b -1 | 直近起動または1つ前の起動分に限定する |
| リアルタイム監視 | -f | 新規ログを継続的に表示する |
| 出力形式変更 | -o json-pretty | 構造化データとして解析ツールに渡す |
| ディスク使用量確認 | –disk-usage | journalのディスク占有量を確認する |
出力形式を使い分ける
デフォルトのテキスト出力は人間が読みやすい一方、grepやjqと組み合わせて機械的に処理したい場合は-o jsonや-o json-prettyが便利です。たとえばjournalctl -u app.service -o json | jq '.MESSAGE'とすれば、メッセージ部分だけを抜き出して外部の集計スクリプトに渡せます。逆に人間がその場で目視確認する場合は、デフォルト表示か-o short-isoでタイムスタンプをISO形式に揃えると、他システムのログと突き合わせやすくなります。
原因特定を早めるコツ
ログの読み方だけでなく、障害の種類ごとにチェックすべき箇所を先に決めておくと調査時間を短縮できます。ここではjournalctl特有の着眼点を2つ紹介します。
OOM Killerを疑う
サービスが理由なく突然終了する場合、メモリ不足によりカーネルのOOM Killerがプロセスを強制終了させているケースがあります。この場合、アプリケーション側のログには何も残らず、カーネルログにだけ痕跡が出ます。journalctl -k --since "1 hour ago" | grep -i "out of memory"のようにカーネルログを対象に検索すると、killされたプロセス名やメモリ使用量の記録が見つかることがあります。アプリケーションログが不自然に途切れている場合は、この確認を先に行うと切り分けが早まります。
再起動履歴で切り分け
複数回再起動を繰り返している環境では、journalctl --list-bootsで過去の起動一覧を確認し、問題が起きた起動番号を特定してからjournalctl -b -2のように番号指定で該当分のログだけを取得すると効率的です。サーバー再起動そのものが意図的なものか異常終了によるものかは、直前のログにshutdownやreboot関連のメッセージがあるかどうかで判断できます。予期しない再起動が続く場合は、ハードウェア側のログ(dmesgやIPMIログなど)も併せて確認する必要があります。
よくある質問
ログが表示されない原因は
journalctl実行時にログが何も表示されない場合、journalの永続化設定が無効になっている可能性があります。/etc/systemd/journal.confのStorage設定を確認し、揮発性(volatile)になっている場合は永続化(persistent)への変更を検討してください。設定変更は各ディストリビューションの公式ドキュメントに沿って実施してください。
過去のログはいつまで残るか
保存期間はディスク容量の上限やSystemMaxUseなどの設定値に依存し、環境によって大きく異なります。目安として、デフォルトではディスク容量の一定割合を上限に自動でローテーションされる設定になっていることが多いため、長期保存が必要な場合は外部ログ収集基盤への転送を検討してください。
特定ユーザーの操作ログは追えるか
sudoやSSHログインに関する記録は、対象サービス(sshd.serviceなど)のユニットログとして残ります。journalctl -u sshd.service --since "today"のように指定すると、ログイン試行や認証失敗の記録を確認できます。
ディスク容量を圧迫している場合の対処は
journalctl --disk-usageで現在の使用量を確認し、不要な古いログを削除する場合はjournalctl --vacuum-size=500Mやjournalctl --vacuum-time=2weeksのようにサイズまたは期間を指定して削除します。本番環境での実行前には、削除対象期間に調査中の障害ログが含まれていないか必ず確認してください。
grepと組み合わせて検索できるか
できます。journalctl -u app.service | grep -i "error"のようにパイプで渡す方法のほか、journalctl自体に-gオプション(正規表現によるメッセージ内検索)が用意されているバージョンもあります。オプションの有無はsystemdのバージョンに依存するため、man journalctlで対応状況を確認してから使用してください。
関連記事
まとめ
journalctlによる障害調査は、時間・優先度・ユニットの3つの軸で表示範囲を絞る操作を組み合わせるところから始まります。単一ユニットで原因が見えない場合は複数ユニットを横断表示し、時系列で突き合わせる方法が有効です。突然のプロセス終了ではOOM Killerの痕跡確認、繰り返す再起動では起動履歴の番号指定という、それぞれの障害パターンに応じた着眼点を持っておくと調査時間を短縮できます。オプションの挙動や設定ファイルの項目名はsystemdのバージョンによって差異があるため、実際の運用では対象環境のmanページや公式ドキュメントで最新の仕様を確認しながら適用してください。ログの削除やジャーナル設定の変更はシステム全体に影響するため、実施前のバックアップ確認や影響範囲の把握を各自の責任で行った上で作業を進めてください。
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら
