はじめに
EC2インスタンス上で稼働しているシステムに障害が発生した際、AWSの監視ツールだけでは原因の特定が難しい場合がありますよね。そんな時、真価を発揮するのがLinuxの知識と技術力です。特に、インスタンス内部のログを読み解く能力は、障害対応の生命線と言えます。
この記事では、Amazon Linux 2 環境を例に、障害発生時に確認すべき主要なログとその場所、そして効率的な調査に役立つLinuxコマンドについて、具体的なパスやオプションを交えて解説します。Apache httpd のログを例にしたアプリケーションログの分析方法もご紹介します。
1. システム/OS レベルのログを調査する
OS自体の動作や、その上で動く基本的なサービスに関するログです。サーバーが高負荷になった、ディスクがいっぱいになった、認証に問題がある、といったOS基盤の問題はこれらのログに現れます。
-
ログの場所:
多くのシステムログは /var/log/ ディレクトリ、またはそのサブディレクトリに格納されています。 -
主要なログファイル例:
-
/var/log/messages
: システムの一般的なメッセージ、エラー、警告などが記録されます。カーネルや様々なデーモンからの出力が含まれます。 -
/var/log/secure
: ユーザー認証や認可に関するログです。SSH接続の成功/失敗、sudoコマンドの実行などが記録されます。 -
/var/log/dmesg
: カーネルの起動メッセージや、ハードウェア、デバイスドライバに関するログです。ハードウェア障害やドライバの問題を示唆する情報が含まれることがあります。 -
/var/log/cloud-init-output.log
: EC2インスタンスの起動時に実行されるcloud-init(ユーザーデータなど)の出力ログです。インスタンス起動時の設定スクリプトの問題確認に不可欠です。 -
/var/log/cron
: cronデーモンの実行に関するログです。定期実行ジョブの失敗などを確認できます。
-
-
調査に役立つLinuxコマンドと使い方:
-
tail
: ファイルの末尾を表示します。障害発生直前の最新のログを確認するのに使います。-
tail -f /var/log/messages
: システムログの末尾をリアルタイムで追跡します。障害が継続している、または再現操作を行っている際に変化を監視するのに便利です。 -
tail -n 200 /var/log/secure
:secure
ログの最新200行を表示します。
-
-
grep
: 指定したキーワードやパターンを含む行を検索します。特定のエラーメッセージや特定の時間帯のログを抽出するのに強力です。-
grep "error" /var/log/messages
:messages
ログから "error" という文字列を含む行を検索します。 -
grep "authentication failed" /var/log/secure
:secure
ログから "authentication failed" (認証失敗)を含む行を検索します。 -
grep "May 10" /var/log/messages
: 例えば5月10日のログのみを検索します。(ログのタイムスタンプ形式に依存します)
-
-
less
: サイズの大きなファイルをページごとに表示します。上下スクロールや検索が可能です。-
less /var/log/dmesg
:dmesg
ログの内容をページ表示します。
-
-
cat
: ファイルの内容全体を標準出力に表示します。他のコマンドとパイプ|
で組み合わせて使うことが多いです。-
cat /var/log/cloud-init-output.log
:cloud-init
のログ全体を表示します。 -
cat /var/log/messages | grep "kernel"
:messages
ログ全体から "kernel" を含む行を抽出します。
-
-
zgrep
: gzip圧縮されたログファイル(.gz
で終わるファイル)の中から直接検索します。ログローテーションにより古いログは圧縮されていることが多いです。-
zgrep "エラー" /var/log/messages.1.gz
: 圧縮されたmessages.1.gz
ファイルから "エラー" を検索します。 -
zgrep "session opened" /var/log/secure.2.gz
: 圧縮されたsecure.2.gz
から "session opened" (ログイン成功など)を検索します。
-
-
2. アプリケーション レベルのログ (Apache httpd の例)
システム障害の多くは、直接的にはアプリケーションの異常によって引き起こされます。ウェブサーバーであるApache httpdのログは、リクエスト処理の状況やアプリケーション側のエラーを知るうえで最も重要です。
-
ログの場所 (Amazon Linux 2 標準の場合):
/var/log/httpd/ ディレクトリ -
主要なログファイル:
-
/var/log/httpd/access_log
: ウェブサーバーへの全てのリクエストが記録されます。アクセス元のIP、リクエストされたURL、HTTPステータスコード(200 OK, 404 Not Found, 500 Internal Server Errorなど)、応答時間などが含まれます。 -
/var/log/httpd/error_log
: Apache httpd 自体、および連携するアプリケーション処理系(PHP-FPMなど)で発生したエラーや警告が記録されます。アプリケーション内部のエラー原因特定に最も役立ちます。
※ ログファイルの場所やファイル名は、Apacheの設定ファイル(
/etc/httpd/conf/httpd.conf
や/etc/httpd/conf.d/*.conf
)で変更されている場合があります。 -
-
調査に役立つLinuxコマンドと使い方:
-
tail -f /var/log/httpd/error_log
:error_log
をリアルタイム追跡します。障害発生時や、障害を再現させる操作を行った際に、即座にエラー出力を確認するのに必須です。 -
grep "PHP Fatal error"
/grep "uncaught exception"
など:error_log
から具体的なアプリケーション側のエラーメッセージを含む行を検索します。使用している言語やフレームワーク特有のエラーメッセージを探します。 -
tail -n 1000 /var/log/httpd/access_log | grep "POST /api/v1/users"
:access_log
の最新1000行から、特定のパスへの POST リクエストのみを抽出します。特定のAPI呼び出しに関連する問題調査に便利です。 -
grep " 500 " /var/log/httpd/access_log
:access_log
から HTTPステータスコードが 500 (Internal Server Error) のリクエストを検索します。どのリクエストでアプリケーションエラーが発生しているかを確認できます。 -
grep '"-" 404 ' /var/log/httpd/access_log
:access_log
から HTTPステータスコードが 404 (Not Found) のリクエストを検索します。存在しないリソースへのアクセス過多などが無いか確認できます。 -
awk '{print $1}' /var/log/httpd/access_log | sort | uniq -c | sort -nr | head -n 10
:access_log
からアクセス元のIPアドレスを抽出し、集計してアクセス数の多い順にTOP 10を表示します。特定のIPからの大量アクセスや攻撃の兆候がないか確認できます。(応用例) -
less /var/log/httpd/access_log
: サイズの大きなaccess_log
をページ表示して確認します。
-
3. その他のシステム状態確認コマンド
ログの分析と並行して、サーバーの現在のリソース使用状況などを確認することも重要です。
-
top
またはhtop
: CPU、メモリ、実行中のプロセスをリアルタイムで監視します。どのプロセス(Apache, PHP-FPM, データベースなど)が大量のリソースを消費しているかを確認し、ログの出力と照らし合わせます。top # 実行後、'q'キーで終了 # または htop (もしインストールされていれば、より高機能)
-
df -h
: ディスクの使用量を確認します。ログファイルが増えすぎてディスクフルになっている、といった問題は多くの障害原因となります。df -h # 人間が読みやすい形式で表示
-
du -sh /var/log
: 特定のディレクトリ(例: ログディレクトリ全体)がどれだけディスク容量を使っているか確認します。du -sh /var/log # /var/log ディレクトリの合計サイズを表示
-
free -m
: メモリの使用状況を確認します。free -m # メモリ使用量をMB単位で表示
-
netstat -tulnp
またはss -tulnp
: サーバーが開いているポートやネットワーク接続を確認します。Apacheが80/443ポートでリッスンしているか、データベースへの接続が確立できているかなどを確認できます。ss
はnetstat
の後継コマンドで、より高速な場合があります。netstat -tulnp # TCP/UDPのリッスンポートとプロセスIDを表示 # または ss -tulnp # 同様の情報を表示
まとめ
AWS環境でEC2上のシステムに障害が発生した際、Amazon Linux 2の/var/log
配下にある各種ログは、問題の根本原因を特定するための宝庫です。
- システムログ(
/var/log/messages
など)でOSや基盤サービスの状態を確認し、 - アプリケーションログ(
/var/log/httpd/error_log
など)でアプリケーション固有のエラーを詳細に調査する
このプロセスにおいて、tail
, grep
, less
, cat
, zgrep
といった基本的なLinuxコマンドを効果的に使いこなすことが、迅速な原因特定と復旧には不可欠です。また、top
やdf
などのコマンドでシステムのリソース状況も合わせて確認することで、ログだけでは見えない全体像を把握できます。
AWSが提供するクラウドインフラストラクチャの利便性を享受しつつも、その上で動くOSやアプリケーションに関する深いLinuxの知識を持つことが、信頼性の高いシステム運用には欠かせません。ログ分析スキルを磨き、AWSでの障害対応力をさらに高めましょう!