障害対応時に「journalctl と /var/log をどう使い分けるか」は、実務でも非常に重要なポイントです。ここでは、それぞれの特徴を踏まえた上で、効率的な確認手順を紹介します。
■ journalctl と /var/log の役割と違い
| 項目 | journalctl | /var/log（ログファイル） |
|---|---|---|
| ログの種類 | systemd管理下のシステム全体ログ | サービスごとの個別ログ |
| 管理対象 | サービス起動・停止、カーネル、システムイベント | Apache、MySQLなど各アプリケーション |
| 永続性 | 設定による（揮発性の場合も） | 基本はファイルとして永続 |
| フィルタリング | コマンドで柔軟に可能 | grep 等で対応 |
| 主な用途 | サーバー全体の状態確認 | 各サービスの詳細な動作確認 |
■ 障害対応時の使い分けと確認手順
以下のように、段階的に使い分けるのが効率的です。
【ステップ1】サーバー全体の異常確認 〜 journalctl 活用 〜
サーバーの挙動がおかしい場合、まずはシステム全体ログから異常の兆候を探ります。
直近の重大エラーを確認
sudo journalctl -p 3 -xe
-p 3：優先度「エラー」以上（緊急、致命的、エラー）のログのみ表示-xe：詳細表示＋直近のログ
特定サービス（例：Apache）のログ確認
sudo journalctl -u httpd
- Apacheの起動・停止・失敗履歴を確認可能
サーバー再起動やカーネル関連エラー確認
sudo journalctl -k
- カーネルメッセージのみ抽出。ハードウェア異常やOOM Killer発動時に有効
【ステップ2】サービス単位の詳細確認 〜 /var/log 活用 〜
次に、対象サービス（例：Apache）の動作ログを細かく確認します。
Apacheのエラーログ確認
sudo tail -n 50 /var/log/httpd/error_log
アクセスログのリアルタイム監視
sudo tail -f /var/log/httpd/access_log
cronジョブの失敗確認
sudo tail -n 50 /var/log/cron
システム全般のイベント確認
sudo tail -n 100 /var/log/messages
- ※Amazon Linux 2023では
/var/log/syslogは存在せず、/var/log/messagesがシステムログの中心。
■ 具体的なユースケース例
ケース① Apacheが起動しない
- サービス状態確認
sudo systemctl status httpd - 起動失敗の理由を確認
sudo journalctl -u httpd -n 50 - 詳細なエラー内容を確認
sudo tail -n 50 /var/log/httpd/error_log
ケース② サーバーが不安定・勝手に再起動
- カーネルエラーの確認
sudo journalctl -k | grep -i error - OOM Killer発動チェック
sudo journalctl | grep -i "out of memory" - 過去の再起動履歴確認
last reboot
ケース③ cronが動作しない
- cronデーモンのエラー確認 bashコピーする編集する
sudo journalctl -u crond - ジョブ実行ログの確認 bashコピーする編集する
sudo tail -n 50 /var/log/cron
■ まとめ：確認フローのベストプラクティス
- systemctl でサービス状態確認
- journalctl でシステム全体・サービス単位の異常把握
- /var/log/ でアプリケーションの詳細確認
- 必要に応じて、リソース状況（CPU/メモリ/ディスク）やネットワーク確認に移る
この流れを習慣化することで、障害対応のスピードと精度が向上します。