journalctl と tail -f ― ログを追いかける

導入

サービスが「動いている／落ちた」の理由は、ログに残ります。systemd 管理下のログを見るのが journalctl、ファイルとして流れるログをリアルタイムで追うのが tail -f。トラブルの原因究明は、結局のところ「ログを読む」ことに尽きます。

説明

journalctl -u ユニット名 で、特定のサービスのログだけを取り出せます。第7章で状態を見た nginx の記録を覗いてみましょう。

journalctl -u nginx

起動の記録や、403・200 といったアクセスの記録が時刻順に並びます。末尾の数件だけ見たいときは -n を付けます。

journalctl -u nginx -n 3

もう1つ、ログの見方で欠かせないのが tail -f（follow）です。第4章で学んだ tail（末尾を見る）に -f を付けると、新しく書き込まれた行をリアルタイムで表示し続けます。/var/log（第2章のディレクトリ地図）に溜まるアプリのログを、横で眺めながら作業できます。

tail -f logs/app.log

本物の環境では、アプリが新しいログを書くたびに画面へ流れてきます（Ctrl+C で終了）。「デプロイしながら tail -f でエラーが出ないか見張る」のは、現場の定番の光景です。

flowchart LR
    A["サービスが動く"] --> B["ログが書かれる<br/>（/var/log や journal）"]
    B --> C["journalctl -u ...<br/>サービス別に読む"]
    B --> D["tail -f ...<br/>リアルタイムで追う"]
    C --> E["原因を特定"]
    D --> E

grep と組み合わせれば、追いながら特定の行だけに絞れます（第4章のパイプが、ここでも効きます）。

tail -n 5 logs/app.log | grep ERROR

「サービスが応答しない」→ systemctl status（動いてる？）→ journalctl -u（何が記録されてる？）→ tail -f（今まさに何が起きてる？）。この流れが、サーバー障害対応の王道です。ログは、サーバーがあなたに残してくれる「証言」です。

やってみよう

journalctl -u nginx で nginx のログを眺め、journalctl -u nginx -n 3 で末尾3件に絞りましょう。tail -f logs/app.log を打つと「追記を待ち受ける」状態になること、tail -n 5 logs/app.log | grep ERROR でエラー行だけを絞れることも試してください。

演習

nginx サービスのログを journalctl で表示してください。