AWSでEC2のログを確認する

EC2でサーバーダウンしたときの調査について。

サーバーダウンのよくある原因は以下。

まずはモニタリング

EC2で対象のサーバーを選択した状態で、下部に表示されているサーバー情報のモニタリングタブを開く。

ここでCPUとネットワークの状態を確認。

ディスクの状態もチェックしたいが、有料の詳細モニタリングが有効になっていない場合は見ることができない。

あまり機会は無いが、インスタンスが正常に起動したかどうかを見る場合はシステムログを確認する。

EC2＞対象のインスタンスを右クリック＞モニタリングとトラブルシューティング＞システムログを取得

インスタンスに対しての通信はCloudWatchで確認できる。

ただし、サーバー内で出力されたTomcatのエラーログなどではなく、インスタンスに通信が届いているのか、どこからどこへの通信なのか、といった表層部分のログ確認となる。

例えばSSH接続がうまくいかない、といった場合などに使用することがある。

EC2のログはネットワークインターフェイスごとに記録されている。

例えば起動ログを見たい場合、このページで、以下の条件で検索するとEC2インスタンスの起動ログが見つかる。

ラムダで自動起動の設定をしている場合、ログを開くとユーザー名という項目がラムダの関数名となっている。

注意点として、このログは、サーバーに通信が届けはAccept OKとなるため、SSH接続が失敗しているか？といった、内部の情報を見ることはできない。

ログを開くと、時刻設定がUTCになっている場合がある。

ページで『タイムゾーン』と検索すると、ヘッダー部分にタイムゾーンを設定しているプルダウンがあるので、そこから設定する。

SSH接続している時と同じ操作を、AWSコンソール上から実行できる。

ただし、後述の理由であまり役に立たない。

EC2＞インスタンスを選択＞接続＞EC2 シリアルコンソール

権限が無い場合は権限設定から必要になる。

EC2＞設定＞EC2シリアルコンソール

ただし、ログインにはバスワードが必要で、Linuxだとパスワードは通常設定も使用もしない。

事前にパスワードを設定しておけば使えるが、それだとSSH鍵認証とかをする急味が無くなる。

なので緊急時にパスワードを設定して接続するのがベストプラクティスらしい。

ただ、緊急時とはSSH接続できないケースとかなので、そもそもその状態でパスワードの設定なんてできない。

えてしてあまり役に立たない機能ではある。