journalctlの実務的な使い方まとめ

URLをコピーしました！

systemd環境のLinuxでは、ログ確認といえば journalctl が基本です。

しかし実際の現場では、

ログが多すぎて追えない
何を見れば原因が分かるのか分からない
結局grepで /var/log を見に行ってしまう

というケースも少なくありません。

本記事では、

障害調査・トラブル対応でそのまま使える journalctl の使い方
「どうなれば解決と判断できるか」

を、実務目線でまとめます。

journalctlとは何か（前提を最短で）

journalctl は、

systemd が収集した
OS・サービス・カーネルログ

を一元的に扱うログビューアです。

重要なのは、

「journalctlを見る＝system全体の時系列を見る」

という点です。

syslog単体より、 原因と結果の前後関係を追いやすいのが最大の強みです。

まず覚えるべき基本操作（現場使用率が高いもの）

直近ログを確認する

journalctl -e

トラブル発生直後は、まずこれで一番新しいログを確認します。

時刻を絞って確認する

journalctl --since "2026-01-30 10:00" --until "2026-01-30 10:10"

障害発生時刻が分かっている場合、 最も重要な使い方です。

「何が起きたか」より先に、

「その直前に何が起きていたか」

を見る意識が重要です。

サービス障害で必ず使う絞り込み

特定サービスのログを見る

journalctl -u nginx

systemctlで管理されているサービスは、ユニット単位で追えます。

起動・停止・異常終了の流れが 一目で分かるのが利点です。

直近の再起動以降のログ

journalctl -b

再起動後に問題が出た場合は、まずここから確認します。

古いログに惑わされないための基本操作です。

トラブルシューティングでの実践的な使い方

カーネル・デバイス系の異常を探す

journalctl -k

以下のようなトラブルで必須です。

ディスクI/O遅延
NIC link flap
ハードウェアエラー

I/O wait やネットワーク遅延系の記事と非常に相性が良い確認ポイントです。

エラーレベルだけを確認する

journalctl -p err

時間がない時の初動確認として有効です。

ただし、

エラーが出ていない＝問題がない

ではない点に注意してください。

journalctlを使う上での注意点

ログが揮発する可能性

設定によっては、

再起動で消える
一定量でローテートされる

ため、 「後で見よう」は危険です。

障害時は、必要なログを即時に退避する判断も重要です。

どうなれば「ログ確認は完了」と判断できるか

以下が揃えば、 journalctl 観点での確認は完了です。

問題発生時刻前後のログを確認した
サービス・カーネル両方を見た
エラーだけでなく流れを追った

これ以上 journalctl を掘っても新情報が出ない場合、

次は vmstat / iostat / ss などへ進む

という判断ができます。

まとめ

journalctlは「時系列」を見るツール
時刻・ユニット・ブートで絞るのが基本
初動は -e、原因追跡は –since
深追いしすぎず次の切り分けへ進む

journalctlを正しく使えると、

「原因不明だった障害」が、原因のある障害になります。