ログの調査（journalctl・dmesg）
障害の原因はログに残っていることが多く、現象を把握したら真っ先に確認します。systemd環境では journalctl で各サービスのログを横断的に読めます。-u でサービスを絞り、-b で今回の起動分だけ、-f で新しい行を追尾できます。dmesg はカーネルからのメッセージを表示し、ハードウェアの異常やOOM Killerによるプロセス強制終了、ディスクエラーなどの低レベルな手がかりが見つかります。
障害対応で最も頼りになる情報源がログです。システムやサービスは、起動・停止・エラー・警告といった出来事を逐一ログに書き残しており、障害の原因はたいていそこに痕跡を残しています。現象を把握したら、リソースを調べるより前に、まずログを確認するのが定石です。推測であれこれ触る前に、「機械自身が何を訴えているか」を読みに行く——この習慣があるだけで、原因究明のスピードが段違いになります。ここでは、systemd環境の中心となる journalctl と、カーネルからの低レベルなメッセージを見る dmesg を押さえます。
journalctl でサービスのログを横断する
近年の多くのLinuxはsystemdがOS全体の起動やサービスを管理しており、各サービスのログは journald という仕組みに一元的に集約されます。これを読み出すのが journalctl です。引数なしで journalctl を実行すると、すべてのログが時系列で表示されますが、量が膨大なので、実務では必ず条件で絞り込みます。表示は less と同じ操作（スペースで進む、/ で検索、q で終了）で読め、新しいログは末尾にあります。journald に集約されているおかげで、どのサービスのログも同じコマンド・同じ操作で串刺しに読めるのが大きな利点です。
もっともよく使う絞り込みが、-u によるサービス単位の指定です。journalctl -u nginx とすれば nginx サービスのログだけが表示され、そのサービスの起動失敗やエラーを追えます。さらに -b を付けると、現在の起動（ブート）以降のログだけに絞れます（journalctl -b）。-b -1 とすれば1つ前の起動時のログを見られるので、「再起動の直前に何が起きたか」を調べたいときに有効です。リアルタイムに追尾したいときは -f を使い、journalctl -u nginx -f とすると、新しいログ行が書き込まれるたびに画面へ流れ続けます。サービスを操作しながらログの動きを目で追う、いわゆるログ監視の定番です。
そのほか、時刻で絞る --since と --until（journalctl --since "2026-06-27 14:00" のように指定）、深刻度で絞る -p err（エラー以上だけ表示）、新しい順に並べる -r、表示行数を絞る -n 50 などを組み合わせると、膨大なログから目的の数行へ素早くたどり着けます。たとえば journalctl -u nginx -p err --since today とすれば、「今日の nginx のエラーだけ」を一発で抜き出せます。これらの絞り込みは複数を同時に指定でき、条件を重ねるほど対象が狭まるので、まず広く出してから -u・-p・--since を足して絞っていくと迷いません。
ひとつ注意したいのが、journald のログが再起動をまたいで残るかどうかは設定によるという点です。既定では揮発（メモリ上のみ）で再起動すると消える環境もあり、その場合は journalctl -b -1 で前回起動分を見ようとしても残っていません。過去の障害を後から追えるよう永続化したいときは、/var/log/journal/ ディレクトリを作成しておくと、ログがディスクに保存されるようになります。本番サーバでは、原因調査を後追いできるよう、この永続化を最初に済ませておくと安心です。ログがいつまで残るかは、ディスク容量に応じて journald が古いものから自動で間引く点も覚えておきます。
dmesg でカーネルの声を聞く
journalctl がサービス層のログを扱うのに対し、より低い階層であるカーネルからのメッセージを表示するのが dmesg（diagnostic message）です。ハードウェアの認識・エラー、ドライバの読み込み、ディスクの異常といった、OSの土台で起きていることがここに出ます。dmesg は出力が多いので、dmesg | less でページ送りしたり、dmesg -T で各行に人間が読める時刻を付けたり（既定は起動からの経過秒数で読みにくい）、dmesg -w で新着を追尾したりすると扱いやすくなります。systemd環境では journalctl -k でも同じカーネルメッセージを読めます。
OOM Killer の痕跡を読む
dmesg がとくに威力を発揮するのが、メモリ枯渇による障害の調査です。Linuxは物理メモリとスワップを使い果たすと、システム全体が固まるのを防ぐため、カーネルが自動的に「メモリを大量に使っているプロセスを1つ選んで強制終了する」という最終手段に出ます。これが OOM Killer（Out Of Memory Killer）です。アプリが理由もなく突然落ちていたら、まずこれを疑います。OOM Killer が動くと、dmesg や journalctl に Out of memory: Killed process 12345 (java) のような行が残るので、これを見つければ「そのプロセスがメモリ不足で殺された」と断定できます。dmesg | grep -i oom や journalctl -k | grep -i oom で素早く痕跡を探せます。原因が分かれば、対処はメモリ増設、該当プロセスのメモリ使用量の見直し、スワップの調整などへと進められます。
実務での使いどころ
実際の調査では、症状に応じて使い分けます。特定のサービスが起動しない・エラーを返すなら journalctl -u サービス名 -p err でそのサービスのエラーを確認し、サーバ全体が不安定・突然プロセスが落ちる・ハードウェアが怪しいなら dmesg -T でカーネルの異常やOOM Killerの痕跡を探します。リアルタイムに事象を捕まえたいときは journalctl -f や dmesg -w を回しながら問題の操作を再現します。ログは新しい行が末尾に追記されるので、調査では tail で末尾だけ見るのと同じ感覚で、最新の出来事から遡るのが効率的です。「困ったらまずログ」を徹底し、journalctl と dmesg を使い分けられるようになると、原因不明に見えた障害の多くが、実は明確な手がかりを残していたと気づけるはずです。