CloudWatchの「最終状態の更新」の更新タイミングを教えてください

Question

質問概要

CloudWatchにて、EC2の「StatusCheckFailed」を監視しています。
アラートの「期間」を「1分」にしており、想定では1分間隔で監視をしているつもりでした。

しかし、EC2をDownさせてからもしばらく「最終状態の更新」が更新されず、
結局10分後に「最終状態の更新」が更新され、アラート通知がされました。

CloudWatchの監視対象のメトリクスの更新間隔はどこで設定をすればよいのでしょうか。

＜CloudWatch設定一覧＞

＜アラート設定内容＞

＜メトリクス画面＞

Answer 1

言葉だけじゃなくて具体的に設定をスクリーンショットで貼ったほうがわかりやすいです。

「期間」で設定するのはアラートの期間ではなくて、該当メトリクスの間隔です。
統計が平均なのか合計なのかそれ以外なのかによっても変わってしまう可能性がありますので設定を貼ってください。
アラートの設定の前にそもそもメトリクスはどうなっていますか？

条件の方の設定が記載されてませんが、そちらによっても変わる可能性があります
コンソールではその他の設定にありますが、設定した条件をいくつのデータポイントが満たしたらアラートになるかを設定ができます。
もっともそちらはデフォルトだと1/1なので影響している可能性は低いですけど。

また、メトリクスによっては設定間隔が短すぎると取得できていない可能性があります。
期間を指定した際、取得できていない箇所（欠落データ）をどういう扱いにするのかというのもここで指定が可能です。

おそらくいずれかに問題があるので、その設定を見直すかここに貼るかしてみてください。
貼る際はもし見えたらまずそうな情報があれば適宜マスクしてください。

Comments

[YasumiJP]

@yu_1985 様
ご返信ありがとうございます。大変助かります。
現在の状態の、スクリーンショットを貼らせていただきました。
他にも取得が必要な画面があれば教えてください。

気になっているのは、「最終状態の更新」です。なぜここが更新されないのか、私は理解できていないです。

[yu_1985]

「設定」を貼ってください。今の状態だけでは不十分です。

[yu_1985]

一覧でも統計と期間が確認できますが、その設定で該当のメトリクスを表示するとどの様になっていますか？

[yu_1985]

最終状態の更新のタイミングはステータスが変わったタイミングなので、ステータスが変わっていなければ更新はされません。

[yu_1985]

ちなみに、メトリクスそのものの更新間隔についてはメトリクスの送信元がどういう間隔でメトリクスを送っているかに依存するので、送信元がメトリクスを送る間隔よりも細かい間隔を表示しようとしても、ないものは表示できません。
該当のメトリクスを表示するとどうなるか見たいのはそういう理由です。

1回発生したら即アラート通知したいのに対象メトリクスがAverageになってるのも怪しいです。

また、EC2をDownさせたというのは具体的にどうやりましたか？
Downさせてからステータスチェックが失敗するまでにラグはありませんか？

[YasumiJP]

ありがとうございます。スクリーンショットを追加しました。

「最終状態の更新」の仕様は理解しました。

「EC2をDownさせた」は、コンソールから「インスタンスを停止」を実行しました。
「インスタンスを停止」実行後から1分後に、EC2は「停止中」ステータスになりましたが、
CloudWatchでアラート判定されて、通知されるまでには「停止中」になってからさらに9分を要しました。

「Average」は「Maximum」に変更しようと思います。

[yu_1985]

インスタンスを正常に停止したのにStatusCheckFailedのアラートが飛ぶのは逆におかしいと思うのですが…。それStatusCheckとは違いますよね？
StatusCheckFailedのアラート設定はどうなっていますか？欠落したデータを失敗とみなしてるのでは？

[YasumiJP]

私が「StatusCheckFailed」の認識を間違えているかもしれません。

「EC2がDownした場合に通知したい」というのが思いです。
「StatusCheckFailed」は、「インスタンスチェックまたはシステムステータスチェックに失敗」した場合に「1」が記録されると思っていましたが、正常なDownは含まないのですね。

スクリーンショットであげていますが、StatusCheckFailedのアラート設定は欠落したデータを失敗としています。

[yu_1985]

そもそもStatusCheckで何をしているかを確認してください。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html

仰っているDownの定義はなんですか？それによって設定すべきアラームが変わります。
StatusCheckに失敗したらDownにはなるでしょうが、Downしているときは常にStatusCheckに失敗しているわけではありません。
例えばインスタンスが想定したレスポンスを返してくれないことをDownとするならそれでは不十分です。
アプリケーションが落ちててもサーバは落ちていない、というケースは普通にありますね。
この辺は監視設計の話です。

また、StatusCheckの欠落データを失敗としたなら、正常にインスタンスを停止してもアラートになってしまいます。
そういう設計です、というならそれでもいいとは思いますが、個人的には違和感があります。

[YasumiJP]

理解が進んできました。ありがとうございます。

Downの定義は「OS停止」です。「StatusCheckFailed」でOS停止を監視できる、と思っていましたが、どうも違うようですね。

まだ、CloudWatchでOS停止を監視するのに最も適切な設定を理解していませんが、
私のDownの定義であれば「欠落データを失敗」にしても良いのでは？　と感じています。

「インスタンスが想定したレスポンスを返してくれない」は、別途Canaryでアラート設定をします。

[yu_1985]

「インスタンスの停止」をアラートの対象にするのならそれでもいいでしょう。
OS停止とインスタンスの停止は若干異なります。
だからそのへんは設計次第です。
Canaryでレスポンスのアラートを設定しているのなら、OSが停止したらどのみちそっちが引っかかるとは思いますけれど。

当然ですが、もしAutoScalingを使用する構成にする予定がある場合はインスタンスのStatusCheckを監視することにそれほど意味はなくなるのでそのあたりは再度設計してみてください。

[YasumiJP]

ありがとうございます。監視設計の最適について理解が進みました。

ただ、監視間隔に関しては、結局「欠落データを失敗」と判定されるまで
アラート設定が「Average」になっていたために、
EC2停止中になってから「9分」要した、という理解でよいのでしょうか。

可能ならば停止中になって数分程度で検知したいですが、
「最大」であれば想定通りに行くか分かりましたら、本質問クローズできそうです。

[yu_1985]

見たいのは平均値ではなくて回数かと思うので平均値でない設定が望ましいと思いますね。
想定より遅くアラートになった理由については、EC2を停止させてから次のメトリクス更新タイミングまでのラグと、1分平均が0でなくなるまでの期間がどの程度だったかという話です。
このあたりは実際に10分かかったところのメトリクスを表示してみれば情報自体は得られるとは思います。
もう一度再現させてみてもいいでしょう。

[YasumiJP]

了解しました。大変丁寧に回答いただき、助かりました。
ありがとうございます。