困っていること
CloudWatch アラームを利用して、特定のメトリクスの閾値（しきい値）を越えたら、SNS で通知が行われるように設定しています。
ある日、通知があったため対象アラームの CloudWatch メトリクスを確認したところ、設定の閾値を越えていないのに、ALARM 状態になっていました。
CloudWatch アラームで設定した閾値を越えていないのに、なぜ ALARM 状態となるのか原因と対処法を教えてください。
※CloudWatch アラームの設定例
- メトリクス名：CPUUtilization
- 統計：平均値
- 期間：5 分
- しきい値の種類：静的
- CPUUtilizationが次の時…：以上…よりも：80
- アラームを実行するデータポイント：1/1
- 欠落データの処理：欠落データを見つかりませんとして処理
どう対応すればいいの?
原因
CloudWatch メトリクスはメトリクスの取得に遅延が発生することがあり、異なる集計データポイントが使用される可能性があります。
下記 AWS re:Post 記載の通り、CloudWatch アラームは特定の時点で利用可能なデータポイントに基づいてメトリクスを評価する仕様です。
新しい値が CloudWatch メトリクスに流入し続けるため、後続の各アラーム評価では、異なる集計データポイントが使用される可能性があります。新たなデータが、まだメトリクスに到達していない場合、アラームをトリガーした違反データポイントを確認できない事がございます。
当該事象の場合
原因として異なる集計データポイントが使用された可能性がございます。
設定例より「統計：平均値」であることからも、対象メトリクスの統計を「最大」で確認した場合、CPU 使用率が 80% 以上になっていることが考えられます。
こちらのデータポイントを使用されたため「統計：平均値」では 80% 以上になっていないものの、ALARM 状態になったと考えられます。
アラームの履歴 よりアラームがトリガーされた時刻、アラームが OK または ALARM に変更された時刻、データポイントの値などを調査可能なのでご活用ください。
アラームの履歴を表示するには、CloudWatch コンソール、DescribeAlarmHistory API アクション、または AWS CLI の describe-alarm-history コマンドを使用します。CloudWatch は、アラーム履歴を 2 週間保存します。状態変化ごとに固有のタイムスタンプが付きます。まれに、1 つの状態変化に対して複数の通知が履歴に残されることがあります。タイムスタンプによって状態変化を区別できます
対処法
前途での説明および、AWS re:Post より、「アラームを実行するデータポイント」を 1/1 から 3/3 へ変更するなど、複数のデータポイントを評価対象とする設定の変更をご検討ください。
アラームの条件緩和を行うことで、当該事象は解消されるかと思います。
アラーム設定の推奨値
アラームの設定において、”評価期間” や “アラームを実行するデータポイント” の設定に推奨値はなく、どのようにアラーム状態 (異常な状態) と判定するかについては、監視するサービスやメトリクスの種類、ご自身のユースケース次第です。
正常時（OK 対象）のメトリクスがどのようなものであるかを把握され、どのような状態が異常（ALARM 対象）であるかを十分に定義されたうえで適切な設定をしてください。
その際は検証をしつつ、ご自身のご要件に応じて値を変更され想定する挙動となるかといった運用をご検討ください。
弊社ブログも参考となるので、ご一読頂ければ幸いです。
7
