journalctlの使い方 - Linuxログ調査の基本と障害対応
この記事でできるようになること
- サービス単位でログを絞り込んで障害原因を追える
- 時間・行数・キーワードでログを絞り込める
- OOM やカーネル異常をカーネルログから確認できる
前提知識（先に読むと理解しやすい記事）
この記事で解決できること
- Ubuntuで「どこにログがあるのか分からない」状態を卒業できます。
journalctlでサービス障害の原因を最短で追えます。- 「直近だけ見る」「時間で絞る」「再現しながら追う」といった実務の型が身につきます。
- OOM やカーネル異常をカーネルログから確認できます。
結論（最短ルート）
障害調査でまずやることはだいたいこれです。
- サービスが死んでるか：
systemctl status <service> - 直近ログ：
journalctl -u <service> -n 200 - 再現しながら追う：
journalctl -u <service> -f - OS側の異常（OOM等）：
journalctl -k | grep -i oom
前提（対象環境）
- OS：Ubuntu
- 対象：サーバ触り始めた新人
- systemd が使われている（多くのUbuntuでそう）
sudoできる前提（ログが読めない場合があるため）
この記事のコマンドはすべて「読むだけ」です
journalctl はログを表示するコマンドです。
サービスを止めたり設定を書き換えたりはしないので、本番サーバでも安全に実行できます。
唯一の注意点は、行数や期間を絞らずに実行すると出力が大量になることです。絞り方は本文で説明します。
0. journalctl って何？（最小限）
結論: systemdのログはjournald に集約され、それを読むのが
journalctl。起動失敗やOOMはjournalに出やすい。
Ubuntuでは、サービスのログがファイル（/var/log/〜）ではなく、journald（ジャーナル） に集約されていることがあります。
その "まとめログ" を読むのが journalctl です。
先に用語を整理します。
| 用語 | 一行の意味 | 補足 |
|---|---|---|
| systemd | Linux の起動処理とサービスを管理する仕組み | 「init システム」とも呼ばれます |
| journald | systemd がログを集めて保管するデーモン | 正式なユニット名は systemd-journald です |
| journal（ジャーナル） | journald が保管しているログの入れ物 | 「ジャーナルログ」と呼ばれることもあります |
| ユニット（unit） | systemd が管理する対象の総称 | -u オプションの u はこの unit の頭文字です |
Nginx/Apacheなどはファイルログもありますが、「サービスの起動失敗」「設定エラー」「OOMで落ちた」などは journal に出ることが多いです。
1. まず service 名を確定する（ここで迷う人が多い）
結論: ログ調査はまず正確なサービス名の特定から。
systemctl statusの出力で名前を確認できる。
例：
- nginx →
nginx - apache →
apache2 - ssh →
ssh - php-fpm →
php8.1-fpmなど（環境で変わる）
まず状態を見て名前を確認します。
$ sudo systemctl status nginx
この画面に、だいたいサービス名が出ます。
2. "直近だけ"を見る（新人が一番使う）
結論:
journalctl -u <service> -n 200で直近ログを確認。まず200行程度が過不足なく見やすい。
-u は「このサービス（ユニット）のログだけ」という指定です。
-n 200 は「末尾から 200 行だけ」という指定です。
2-1. 直近200行（サービス指定）
$ sudo journalctl -u nginx -n 200
Dec 15 13:02:11 web01 systemd[1]: Starting A high performance web server and a reverse proxy server... Dec 15 13:02:11 web01 systemd[1]: Started A high performance web server and a reverse proxy server. Dec 15 13:41:55 web01 nginx[1234]: 2025/12/15 13:41:55 [error] 1234#1234: *12 open() "/var/www/html/missing.html" failed (2: No such file or directory)
1 行は「日時 / ホスト名 / プロセス名[PID] / メッセージ」の順に並びます。
Apacheの場合：
$ sudo journalctl -u apache2 -n 200
2-2. もっと短く（直近50行）
$ sudo journalctl -u nginx -n 50
最初は200行くらいがちょうど良いです。少なすぎると「肝心のエラーが出てない」がよく起きます。
3. "再現しながら追う" のが最強（-f）
結論:
journalctl -u <service> -fでログを追いながら別タブで再現すると、原因に最短で当たれる。
これが最短で原因に当たります。
$ sudo journalctl -u nginx -f
-f（follow）は新しいログが出るたびに画面へ追記し続けるモードです。
終了するときは Ctrl+C を押します。ログを見ているだけなので、途中で止めてもサービスには影響しません。
別タブで curl やブラウザで再現 → 直後のログを見る。
これで、原因がほぼ見えます。
4. 時間で絞る（調査が一気に速くなる）
結論: 壊れた時刻が分かるなら
--since/--untilで時間を絞る。調査速度が一気に上がる。
「いつ壊れたか分かる」場合は絶対に時間で絞るべきです。
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"
--since の時刻はサーバのタイムゾーンで解釈されます。
サーバが UTC 設定だと、手元の時計と数時間ずれることがあります。
迷ったら timedatectl で現在のタイムゾーンを確認してください（これも表示するだけのコマンドです）。
5. エラーだけ見たい（-p で優先度を絞る）
結論:
-p errで優先度から機械的に絞り、足りなければ grep で文字列を重ねる。
5-1. 優先度で絞る（journalctl 標準の方法）
journalctl はログ 1 行ごとに「優先度（priority）」を記録しています。
これは本文とは別のデータなので、-p で機械的に絞り込めます。
$ sudo journalctl -u nginx -p err --since "today"
優先度は重大な順に emerg / alert / crit / err / warning / notice / info / debug の 8 段階です。
-p err は「err 以上（より重大）」の行だけを表示します。本文に "error" という語がないエラー行も拾えます。
5-2. 文字列で絞る（grep との併用）
-p で絞ってもまだ多いときは、文字列でさらに拾います。
$ sudo journalctl -u nginx --since "today" | grep -iE "error|fail|fatal|panic|denied|refused|timeout"
grep -i は大文字小文字を区別しない指定、-E は |（または）を使える指定です。
grepは万能ではないですが、初動の当たり付けには強いです。
6. OS側の異常：OOM / kernel ログを見る（決定打になりがち）
結論: アプリ突然死の裏でOOMやカーネル異常が起きていることがある。
journalctl -kで確認する。
アプリが突然落ちる、プロセスが死ぬ、502が増える、などの裏で OOM Killer（メモリ不足）やカーネル異常が起きていることがあります。
OOM Killer とは、メモリが足りなくなったときに Linux が自分でプロセスを強制終了する仕組みです。 「OOM」は Out Of Memory（メモリ不足）の略で、アプリ側のログには何も残らないことがあります。
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. "起動失敗" を調べる（よくある）
結論: 起動失敗時は
systemctl statusとjournalをセットで見る。-bで今回起動分だけに絞れる。
サービスが起動しないときは、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. 失敗例（あるある）と対策
結論: ログが出ない・多すぎる・grepで出ない等は典型。
sudo付与、時間/行数絞り、生ログ確認で解決する。
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は必ず使う。
9. ログが消える・保存されない場合
結論: journal は既定で再起動をまたがない構成があり、
journalctl -b -1の可否で保存有無を判断する。
「再起動したらログが消えた」ときは、journald の保存先が原因のことがあります。
journald は保存先を /run/log/journal（メモリ上・再起動で消える）か /var/log/journal（ディスク上・再起動後も残る）のどちらかにします。
まず、前回起動時のログが読めるかを確認します。
$ sudo journalctl -b -1 -n 20
前回分が表示されれば保存されています。 前回起動が見つからない旨のメッセージが返る場合、そのサーバでは再起動をまたいで保存されていません。
保存を有効にするには /etc/systemd/journald.conf の変更と journald の再起動が必要です。
設定変更はサーバの挙動を変える操作なので、本番では変更前のファイルを控え、ディスク使用量の上限（SystemMaxUse）とあわせて検討してください。
調査目的なら、まず journalctl の出力をファイルへ書き出して保全する方が安全です。
$ sudo journalctl -u nginx -n 2000 > ~/nginx-journal-$(date +%Y%m%d).log
10. 調査完了チェックリスト
結論: 状態・絞り込み・時刻・OS 側・保全の 5 点を押さえれば、ログ調査は次の工程へ進んでよい。
- [ ]
systemctl status <service>で現在の状態を確認した - [ ]
-uでサービスを絞り、-nまたは--sinceで範囲を絞って読んだ - [ ]
timedatectlでタイムゾーンを確認し、事象の時刻とログの時刻を突き合わせた - [ ]
journalctl -kで OOM やカーネル異常の有無を確認した - [ ] 必要なログをファイルへ書き出して保全した
コピペ用：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