【Ubuntu】journalctl の使い方：ログ調査の基本（原因特定を速くする型）
この記事で解決できること
- Ubuntuで "どこにログがあるのか分からない" を卒業できます
journalctlを使って、サービス障害の原因を最短で追えます- 「直近だけ見る」「時間で絞る」「再現しながら追う」など、実務の型が身につきます
結論（最短ルート）
障害調査でまずやることはだいたいこれです。
- サービスが死んでるか：
systemctl status <service> - 直近ログ：
journalctl -u <service> -n 200 - 再現しながら追う：
journalctl -u <service> -f - OS側の異常（OOM等）：
journalctl -k | grep -i oom
目次
前提（対象環境）
- OS：Ubuntu
- 対象：サーバ触り始めた新人
- systemd が使われている（多くのUbuntuでそう）
sudoできる前提（ログが読めない場合があるため）
0. journalctl って何？（最小限）
Ubuntuでは、サービスのログがファイル（/var/log/〜）ではなく、journald（ジャーナル） に集約されていることがあります。
その "まとめログ" を読むのが journalctl です。
Nginx/Apacheなどはファイルログもありますが、「サービスの起動失敗」「設定エラー」「OOMで落ちた」などは journal に出ることが多いです。
1. まず service 名を確定する（ここで迷う人が多い）
例：
- nginx →
nginx - apache →
apache2 - ssh →
ssh - php-fpm →
php8.1-fpmなど（環境で変わる）
まず状態を見て名前を確認します。
$ sudo systemctl status nginx
この画面に、だいたいサービス名が出ます。
2. "直近だけ"を見る（新人が一番使う）
2-1. 直近200行（サービス指定）
$ sudo journalctl -u nginx -n 200
Apacheの場合：
$ sudo journalctl -u apache2 -n 200
2-2. もっと短く（直近50行）
$ sudo journalctl -u nginx -n 50
最初は200行くらいがちょうど良いです。少なすぎると「肝心のエラーが出てない」がよく起きます。
3. "再現しながら追う" のが最強（-f）
これが最短で原因に当たります。
$ sudo journalctl -u nginx -f
別タブで curl やブラウザで再現 → 直後のログを見る。
これで、原因がほぼ見えます。
4. 時間で絞る（調査が一気に速くなる）
「いつ壊れたか分かる」場合は絶対に時間で絞るべきです。
4-1. 直近1時間
$ sudo journalctl -u nginx --since "1 hour ago"
4-2. 今日だけ
$ sudo journalctl -u nginx --since "today"
4-3. 明確な時間帯（例）
$ sudo journalctl -u nginx --since "2025-12-15 13:00" --until "2025-12-15 14:00"
5. エラーっぽい行だけ見たい（優先度高い）
ログが多いときは "まずエラーっぽい文字列" を拾います。
$ sudo journalctl -u nginx --since "today" | grep -iE "error|fail|fatal|panic|denied|refused|timeout"
grepは万能ではないですが、初動の当たり付けには強いです。
6. OS側の異常：OOM / kernel ログを見る（決定打になりがち）
アプリが突然落ちる、プロセスが死ぬ、502が増える、などの裏で
OOM Killer（メモリ不足）やカーネル異常が起きていることがあります。
6-1. カーネルログ（-k）
$ sudo journalctl -k -n 200
6-2. OOMだけ拾う
$ sudo journalctl -k | grep -i oom | tail -n 50 $ sudo journalctl -k | grep -i "killed process" | tail -n 50
7. "起動失敗" を調べる（よくある）
サービスが起動しないときは、statusとjournalをセットで見ます。
7-1. status（要点がまとまってる）
$ sudo systemctl status nginx
7-2. 直近の起動ログ（サービス指定）
$ sudo journalctl -u nginx -n 200
7-3. 直近の起動試行だけ見たい（-b と組み合わせ）
「今回の起動（ブート）だけ」のログが欲しい時：
$ sudo journalctl -u nginx -b -n 200
-b は "今回起動してからのログ" という意味です。
8. 失敗例（あるある）と対策
8-1. "ログが出ない"
- そもそもそのサービスがjournaldに出していない（ファイルログのみ）
- 権限が足りず読めない
対策：
sudoを付ける- Nginx/Apacheは
/var/log/nginx/や/var/log/apache2/も見る
8-2. "ログ多すぎて読めない"
対策：
--sinceで時間絞り-nで行数絞り-uでユニット絞り- 再現して
-fで追う（最短）
8-3. "grepで何も出ない"のに壊れてる
対策：
- grepの条件が狭いだけのことが多いので、まず生ログを
-n 200で見る - statusのエラー行を見る
事故防止：「やってはいけない」
- 再起動を連打してログを流す - ログが流れて原因が見えなくなります。まず
journalctl -u <service> -n 200を取ってから。 - 時間を絞らずに全部読む - 時間が溶けます。
--sinceを使うだけで生産性が跳ねます。 - アプリのログだけ見てOS側を見ない - OOMやカーネル異常はアプリログに出ないことが多いです。
journalctl -kは必ず使う。
コピペ用：journalctl 調査テンプレ
# 1) まず状態 sudo systemctl status <service> # 2) 直近ログ sudo journalctl -u <service> -n 200 # 3) 再現しながら追う（最強） sudo journalctl -u <service> -f # 4) 今日だけ sudo journalctl -u <service> --since "today" # 5) OS側（OOMなど） sudo journalctl -k | grep -i oom | tail -n 50 sudo journalctl -k | tail -n 200
検証環境
本記事のコマンドは Ubuntu 24.04 LTS / bash 5.2 で動作確認済みです。