Amazon EC2が停止した原因が掴めません

Question

AWSで運用している1台のウェブサーバのインスタンス突然停止してしまいました。
以下、停止直前の /var/log/messages の内容となりますが、ここから何か原因等わかりますでしょうか。
もし何かアドバイス等ございましたらいただければ幸いです。
（ほかにログが必要であれば提供いたします）

---

May 16 17:28:10 ip-xxx.xxx.xxx.xxx dhclient[2098]: bound to xxx.xxx.xxx.xxx -- renewal in 1510 seconds.
May 16 17:53:20 ip-xxx.xxx.xxx.xxx dhclient[2098]: DHCPREQUEST on eth0 to xxx.xxx.xxx.xxx port 67 (xid=0x151a63e9)
May 16 17:53:20 ip-xxx.xxx.xxx.xxx dhclient[2098]: DHCPACK from xxx.xxx.xxx.xxx (xid=0x151a63e9)
May 16 17:53:22 ip-xxx.xxx.xxx.xxx dhclient[2098]: bound to xxx.xxx.xxx.xxx -- renewal in 1517 seconds.
May 16 18:18:39 ip-xxx.xxx.xxx.xxx dhclient[2098]: DHCPREQUEST on eth0 to xxx.xxx.xxx.xxx port 67 (xid=0x151a63e9)
May 16 18:18:39 ip-xxx.xxx.xxx.xxx dhclient[2098]: DHCPACK from xxx.xxx.xxx.xxx (xid=0x151a63e9)
May 16 18:18:41 ip-xxx.xxx.xxx.xxx dhclient[2098]: bound to xxx.xxx.xxx.xxx -- renewal in 1474 seconds.
May 16 18:43:15 ip-xxx.xxx.xxx.xxx dhclient[2098]: DHCPREQUEST on eth0 to xxx.xxx.xxx.xxx port 67 (xid=0x151a63e9)
May 16 18:43:15 ip-xxx.xxx.xxx.xxx dhclient[2098]: DHCPACK from xxx.xxx.xxx.xxx (xid=0x151a63e9)
May 16 18:43:17 ip-xxx.xxx.xxx.xxx dhclient[2098]: bound to xxx.xxx.xxx.xxx -- renewal in 1678 seconds.
May 16 19:02:13 ip-xxx.xxx.xxx.xxx init: serial (ttyS0) main process (2482) killed by TERM signal
May 16 19:02:13 ip-xxx.xxx.xxx.xxx init: tty (/dev/tty1) main process (2484) killed by TERM signal
May 16 19:02:13 ip-xxx.xxx.xxx.xxx init: tty (/dev/tty2) main process (2487) killed by TERM signal
May 16 19:02:13 ip-xxx.xxx.xxx.xxx init: tty (/dev/tty3) main process (2489) killed by TERM signal
May 16 19:02:13 ip-xxx.xxx.xxx.xxx init: tty (/dev/tty4) main process (2491) killed by TERM signal
May 16 19:02:13 ip-xxx.xxx.xxx.xxx init: tty (/dev/tty5) main process (2493) killed by TERM signal
May 16 19:02:13 ip-xxx.xxx.xxx.xxx init: tty (/dev/tty6) main process (2495) killed by TERM signal
May 16 19:02:13 ip-xxx.xxx.xxx.xxx init: plymouth-shutdown main process (9032) terminated with status 1
May 16 19:02:13 ip-xxx.xxx.xxx.xxx init: splash-manager main process (9027) terminated with status 1
May 16 19:02:14 ip-xxx.xxx.xxx.xxx ntpd[2353]: ntpd exiting on signal 15
May 16 19:02:14 ip-xxx.xxx.xxx.xxx init: Disconnected from system bus
May 16 19:02:14 ip-xxx.xxx.xxx.xxx rpcbind: rpcbind terminating on signal. Restart with "rpcbind -w"
May 16 19:02:14 ip-xxx.xxx.xxx.xxx auditd[2139]: The audit daemon is exiting.
May 16 19:02:14 ip-xxx.xxx.xxx.xxx kernel: [237095.274698] audit: type=1305 audit(1463392934.546:610): audit_pid=0 old=2139 auid=4294967295 ses=4294967295 res=1
May 16 19:02:14 ip-xxx.xxx.xxx.xxx kernel: [237095.366951] audit: type=1305 audit(1463392934.638:611): auid=4294967295 ses=4294967295 op="remove_rule" key=(null) list=1 res=1
May 16 19:02:14 ip-xxx.xxx.xxx.xxx kernel: [237095.373571] audit: type=1305 audit(1463392934.646:612): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 res=1
May 16 19:02:14 ip-xxx.xxx.xxx.xxx kernel: Kernel logging (proc) stopped.
May 16 19:02:14 ip-xxx.xxx.xxx.xxx rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="2157" x-info="http://www.rsyslog.com"] exiting on signal 15.

Answer 1

OS は CentOS 6 か Amazon Linux でしょうか。
ログを見る限り、普通にシャットダウンしているように見えます。
last コマンドや /var/log/secure で該当時間にログインしていた人はいないでしょうか。

OS 内に痕跡がなければ、AWS 側からインスタンスを stop されたのかもしれません。
CloudTrail が有効であれば、AWSマネージメントコンソールや API で stop したなどのログが記録されていますので、確認ください。
そうでなければ、AWSサポートに問い合わせると何かわかるかもしれません。

ないと思いますが、1年前に cron でシャットダウンした設定が残っているとか。

Comments

[grnfnt]

ご回答誠にありがとうございます。

lastや/var/log/secureを見ても侵入されたという痕跡はなく、secureについては停止直前と思われる時間帯に以下の記録がされておりました。
May 16 19:02:14 ip-xxx.xxx.xxx.xxx sshd[2328]: Received signal 15; terminating.

インスタンスはm4.largeで、先月運用開始したばかりのものとなります。OSはAmazonLinuxです。
ロードバランサーで同内容のインスタンスでEC2は2台、RDS1台で運用してます。

お客さんに根拠ある説明ができればそれで解決ではあるのですが、もし何かアドバイス等ありましたらいただけると助かります。
よろしくお願いいたします。

[TaichiYanagiya]

AutoScaling を利用していないのであれば、次善の策として Auto Recovery を有効にしておくといいと思います。

Answer 2

AWSで300台程度のインスタンスを2年程度運用していたことがあります。
EC2インスタンス、特にバーストタイプ(t2インスタンス)はAWS側のインフラの問題で割と簡単に死にます。
（毎月1-2台くらいは死んでました）
この場合、AWSサポートに問い合わせる他原因を判明する方法がありません。
*それも有料サポート契約をしていないとスムーズに行かないと思います。

非バーストインスタンスではそういった経験はありませんが、単純に運用していた数が少ないので当たらなかった可能性もあります。

そのため、AWSでバーストインスタンスを運用するには死んでも大丈夫な状態にする（冗長化、監視、AutoScalingによる復旧など）という運用をしていました。

ご参考になれば幸いです。

Comments

[grnfnt]

ご回答誠にありがとうございます。

インスタンスはm4.largeで、先月運用開始したばかりのものとなります。OSはAmazonLinuxです。
ロードバランサーで同内容のインスタンスでEC2は2台、RDS1台で運用してます。

アクセスは画像やCSS等含めても1日300アクセス程度ですのでバーストしているとは考えにくいのですが、ロードバランサーの設定か何かで自動的に1台をシャットダウンしてしまうようなことはあるものなのでしょうか。
どうも原因がそれくらいしか思いつかないんですよね。。

お客さんに根拠ある説明ができればそれで解決ではあるのですが、どうも気持ち悪いのでアドバイス等ありましたらいただけると助かります。
よろしくお願いいたします。

[tanat]

>ロードバランサーの設定か何かで自動的に1台をシャットダウンしてしまうようなことはあるものなのでしょうか。
AutoScalingGroupを組んで、ELBでヘルスチェックしているのであればシャットダウンというよりはterminateされて新しいインスタンスが起動しますね。
あとはAWS側のメンテナンス予定が入っていて再起動予告がされていたのに気づかなかったとかもあり得ます。
が、殆どのケースでAWSサポート以外は原因がわからないことが多いので、業務で使っているものならビジネス以上のサポート契約をしてAWSサポートに聞く以外の選択肢は無いかと思いますよ。

[grnfnt]

早速のご返答ありがとうございます
AutoScalingは使っていないので、可能性があるならば、メンテナンスですかね。
同じアベイラビリティゾーン内のもう1台は生きているので可能性としては低いかもしれませんが、この角度で少し調べてみます。
ありがとうございます。