ログの調査（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 が古いものから自動で間引く点も覚えておく。
🔧 サービス層より深い「カーネルの声」
journalctl がサービス層のログを扱うのに対し、より低い階層であるカーネルからのメッセージを表示するのが dmesg（diagnostic message）だ。
ハードウェアの認識・エラー、ドライバの読み込み、ディスクの異常といった、OSの土台で起きていることがここに出る。
dmesg は出力が多いので、扱いやすくする工夫がある。dmesg | less でページ送りしたり、dmesg -T で各行に人間が読める時刻を付けたり（既定は起動からの経過秒数で読みにくい）、dmesg -w で新着を追尾したりできる。
systemd環境では journalctl -k でも同じカーネルメッセージを読める。
💥 アプリが理由もなく落ちた、その痕跡
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 で素早く痕跡を探せる。
原因が分かれば、対処はメモリ増設、該当プロセスのメモリ使用量の見直し、スワップの調整などへと進められる。
🧭 2つの道具を症状に応じて使い分ける
実際の調査では、症状に応じて使い分ける。
特定のサービスが起動しない・エラーを返すなら journalctl -u サービス名 -p err でそのサービスのエラーを確認する。サーバ全体が不安定・突然プロセスが落ちる・ハードウェアが怪しいなら dmesg -T でカーネルの異常やOOM Killerの痕跡を探す。
リアルタイムに事象を捕まえたいときは journalctl -f や dmesg -w を回しながら問題の操作を再現する。
ログは新しい行が末尾に追記されるので、調査では tail で末尾だけ見るのと同じ感覚で、最新の出来事から遡るのが効率的だ。
「困ったらまずログ」を徹底し、journalctl と dmesg を使い分けられるようになると、原因不明に見えた障害の多くが、実は明確な手がかりを残していたと気づけるはずだ。