Q&A
どれくらいの頻度なのですか？
#今起こっている現象
EC2 が不定期に落ちる。Apache でのウェブサイトだけでなく SSH も繋がらない。
ウェブコンソールでインスタンスの再起動をすると元に戻る。
#やりたいこと
CloudWatch で EC2 の状態を監視して、落ちている時は EC2 を復旧・あるいは再起動したい。
#やったこと
- EC2 の「ステータスチェック」で「ステータスアラームの作成。
- 「アクションの実行」で「このインスタンスを再起動」を選択。
- 「ステータスチェックに失敗(インスタンス)」を選択。
- 「1分間」間隔で「2度以上」を選択。
- 「アラームを作成」をクリック。
- 「アラームが正常に作成されました」ダイアログで「閉じる」をクリック。
#やっていないこと
負荷テスト等は怖くてやっていません。(一生落ちっぱなしが怖いので)
ある時、ふとアクセスするとブラウザに 500 系エラーが表示されます。
#教えていただきたいこと
やり方が間違っている・足りないことなどがありましたらご教示ください。
また、別のやり方がある場合もご教示ください。
#追記 messageログ
Mar 31 15:01:01 linming systemd: Created slice User Slice of root. Mar 31 15:01:01 linming systemd: Starting User Slice of root. Mar 31 15:01:01 linming systemd: Started Session 748 of user root. Mar 31 15:01:01 linming systemd: Starting Session 748 of user root. Mar 31 15:01:01 linming systemd: Removed slice User Slice of root. Mar 31 15:01:01 linming systemd: Stopping User Slice of root.
ssh アクセスした覚えのない時間帯に上記ログがあります。
私のパスワードと秘密鍵が漏洩したか、別のユーザが作られて、それで侵入されているのでしょうか？
#追記2 CloudWatch Agent
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html
を参考に Agent 入れてみたのですけど、
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/common-config.toml -s
が
2020/04/03 13:58:06 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_common-config.toml.tmp ... 2020/04/03 13:58:06 Invalid json format, please check. Reason: invalid character '#' looking for beginning of value 2020/04/03 13:58:06 I! AmazonCloudWatchAgent Version 1.237768.0. 2020/04/03 13:58:06 Configuration validation first phase failed. Agent version: 1.237768.0. Verify the JSON input is only using features supported by this version.
と表示され実行できません。
common
1# This common-config is used to configure items used for both ssm and cloudwatch access 2 3 4## Configuration for shared credential. 5## Default credential strategy will be used if it is absent here: 6## Instance role is used for EC2 case by default. 7## AmazonCloudWatchAgent profile is used for onPremise case by default. 8[credentials] 9# shared_credential_profile = "{profile_name}" 10shared_credential_file = "/root/.aws/credentials" 11 12 13## Configuration for proxy. 14## System-wide environment-variable will be read if it is absent here. 15## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy 16## Note: system-wide environment-variable is not accessible when using ssm run-command. 17## Absent in both here and environment-variable means no proxy will be used. 18# [proxy] 19# http_proxy = "{http_url}" 20# https_proxy = "{https_url}" 21# no_proxy = "{domain}" 22 23# [ssl] 24# ca_bundle_path = "{ca_bundle_file_path}"
1日に2, 3度でしょうか。
定期的に監視しているわけではなく、気の向いた時にアクセスすると落ちていた、みたいな感じです。
テストサーバで、私以外はアクセスしないので、低頻度アクセスだと EC2 がスタンバイモード(?) か何かに変わる、とかあるのでしょうか？
落ちる前ぐらいのところで、ログに何か残っていませんでしょうか。
/var/log/secure を見てみましたが、特に変わったところがありませんでした。
# と言うか、不正アクセスしようとするログで埋まっていました。
どのログを確認したらいいか、ご教示いただけますでしょうか？
スタンバイモードは聞いたことないですね。あるんですかね。
テスト環境ってことは、24hではないんですよね。ってことは2-3h に 1 回。仮想マシンの落ちる頻度としては多い気がします。
落ちるっていうのは、停止状態なのですか? ステータスチェックって停止状態でも異常になりますかね?
構成が分からないので、何みたらいいかは私は助言できませんが。
テスト環境ですが 24h 立ち上げてます。
EC2 の新スタンスの状態は「running」のままです。
回答2件
0
原因解明は別として、
「再起動」ではなく「復旧」でいいのではないでしょうか。
また、下記 URL によると 2つのステータスチェックのうち、StatusCheckFailed_System のみだそうです。
復旧アクションは、StatusCheckFailed_System でのみ使用できます。StatusCheckFailed_Instance では使用できません。
Amazon CloudWatch アラームへの復旧アクションの追加
StatusCheckFailed_System で検知できない障害であれば、例えば、ELB のヘルスチェックでポート監視 ＋ AutoScaling (min=1, max=1) で、障害インスタンスを捨てて、新規インスタンスに置き換える方法が考えられます。
投稿2020/03/27 14:30
総合スコア12173
0
ベストアンサー
今回の復旧という意味だと、StatusCheckFailedの値でCloudWatchのアラームを設定し、アラームの状態変化をトリガーにEC2 RebootInstanceを呼び出してやるのがいいでしょうか。
公式ドキュメントの記載もご参照ください。
そもそもの話ですが、まず原因調査をしましょう。
落ちたときのメトリクスとCloudWatchで見たりしたら何か変わったことはありませんか？
あと、CloudWatchではメモリ使用率やディスク使用率などのサーバメトリクスが取得できないので、それを見たければCloudWatchエージェントを入れるなり、その他の監視サービスのエージェントを入れるなりする必要があります。
また、アクセスが増大するなどしてないかをログから確認してみましょう。
現在の最大の問題は何が原因で何が起こっているかを把握できていないことなので、まずは情報を集めましょう。
個人的な所感ですが、サーバのリソース不足ではないかと思っています。
負荷テスト等は怖くてやっていません。
当然ですが、やるならAMIを取得後にインスタンスをコピーしてからそっちでやってください。
投稿2020/03/27 17:22
編集2020/03/27 17:23
総合スコア7588
「いつの間にか落ちている」ので、落ちた際のログの確認ができません。
CloudWatch の SMS で自分宛にメールが来るように設定したのですが、そのメールが来ないです。
リンクで示された公式ドキュメントは、私には？？？でした。
いえ、アクセスログとかで該当の時間帯の出力内容とかを確認できませんか？
あと、該当時間帯のCloudWatchのメトリクスはいつでも確認できます。
CloudWatchのアラートをトリガーにメールを飛ばす方法は調べれば出てくるので割愛します。
見直してみてください。
当サーバにはほとんどアクセスしないので、いつ落ちたのか確認が難しいです。
/var/log/messages の最後の部分でよろしいでしょうか？
CloudWatch からメールを飛ばす設定にしているのですが、メールが来ないんです。
>当サーバにはほとんどアクセスしないので、いつ落ちたのか確認が難しいです。
難しいと仰る前に、欲しい情報を絞り込むためにどういった情報を取ればいいかを考えてみてください。
CloudWatchでEC2のメトリクスのStatusCheckFailedを確認してください。
StatusCheckFailedでなくても、ダウンしたと思われる付近では何かしらメトリクスに異変が起きている可能性が高く、その時間帯に落ちていたことが推測できます。
他には何でもいいですが、向上的に出力されているログの出力が途切れている可能性が高く、そうなっていれば恐らくその時間帯には落ちていたと推測できます。
メールが飛ぶかどうかはまた別なので、まずはCloudWatchのほうを見てください。
メールが飛ばないと仰ってますが、アラートを設定しただけではメールは飛ばないので、アラートをトリガーにメールを飛ばす方法を調べてみてください。
落ちたのでmessageログを見てみました。
侵入されているのでしょうか？
CloudWatch の「Status Check Failed Sum」「Status Check Failed Instance Sum」「Status Check Failed System Sum」は「0」のままでした。
> ssh アクセスした覚えのない時間帯に上記ログがあります。
私のパスワードと秘密鍵が漏洩したか、別のユーザが作られて、それで侵入されているのでしょうか？
それを確認するなら、見るべきは/var/log/secureです
また、CloudWatchをみるなら他のメトリクスもチェックしてください。
該当のEC2インスタンスの該当時間帯のCPU使用率やディスクIOなど
ステータスチェックについては、HTTPリクエストが通らなくなると失敗します。
>Apache でのウェブサイトだけでなく SSH も繋がらない。
という状態であればステータスチェックも失敗している可能性が高いのですが、落ちたとは上記の状態でしょうか？
/var/log/secure を見たのですが、該当の時間にアクセスした形跡はありませんでした。
「落ちた」は、HTTP(S) も SSH も繋がらない状態です。
落ちた時間帯にサーバリソースはどうなってますか？（というのも合わせて見てくださいと書いているつもりなのですが…）
CloudWatchでデフォルトで取れるメトリクスで足りないのであれば、CloudWatch Agentを入れるなり、その他の監視サービスのエージェントを使うなりしてもっと詳細なメトリクスを取ってください。
例えばメモリ使用率とかはエージェント入れるなどでCloudWatchや監視サービスに送るか、直接サーバで見ないとわかりません。
CloudWatch Agent を入れるのに失敗しました。
質問を追記したので、ご参照ください。
昨日 ec2 が落ちて、再起動されたことが確認できました。
CloudWatch Agent はまた改めて起票したいと思います。
色々と付き合っていただきありがとうございました。
あなたの回答
tips
プレビュー
