CloudWatch アラームの状態が変わるタイミング
こんにちは、米須です。
CloudWatch アラームって使ってますか？アラーム状態になると通知してくれる便利なサービスですが、アラーム状態が変化するタイミングが分かりにくかったので整理してみました。
アラームの設定
ALB に EC2 が 1 台紐づいている構成を作成し、サーバの正常稼働を確認することを想定したアラームを作成しました。アラームの設定値は下記のとおりです。
アラーム状態の変化と気になったこと
EC2 を起動／停止することにより、アラーム状態の変化を確認した結果は下記のとおりです。
※ 下記画像の「履歴」に表示されている日時は UTC のため、他で表示されている日時と9時間ずれています。
この結果を見たとき、私は下記2点が気になりサポートに確認してみました。
しきい値が「10 分内の 5 データポイント」なのに、
① EC2 を起動してから状態が「OK」となるまでに 7 分も掛かっているのはなぜか。
② EC2 を停止してから状態が「アラーム状態」となるまでに 11 分も掛かっているのはなぜか。
結論
① EC2 を起動してから状態が「OK」となるまでに 7 分も掛かっているのはなぜか。
私は「10 分内の 5 データポイント」というところだけ頭に入っていたので、5 分経ったても「OK」にならないのはなぜかと気になっていました。しかし、設定内容をよくよく確認すると「10 分内の 5 データポイントで HealthHostCount < 1というしきい値を満たすとアラーム状態になる」というのが私が設定した内容でした。裏を返すと、「10 分内で HealthHostCount < 1 となっているデータポイントが 5 つ未満にならないと OK にならない」ということです。
また、メトリクスがデータポイントとして取得されるまでに時間が掛かることもあり、HealthHostCount = 1 となっているデータポイントが 6 つになったことを検知し状態が変わるまでに 7 分掛かったということでした。
② EC2 を停止してから状態が「アラーム状態」となるまでに 11 分も掛かっているのはなぜか。
今度は②の疑問です。アラーム状態から OK に変わるのに 7 分なら、OK からアラーム状態になるのも 7 分では？って思いますよね。理由はドキュメントにありました。
[AWS ドキュメント]
データが欠落した場合のアラーム状態の評価方法
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-evaluating-missing-data
評価範囲のデータポイントの一部が欠落しており、取得された既存のデータポイントの数がアラームの [Evaluation Periods (評価期間)] の数を下回る場合、CloudWatch によって、欠落データ部分に欠落データの処理方法に指定された結果が入力され、アラームが評価されます。ただし、評価範囲内のすべての実際のデータポイントが評価に含まれます。CloudWatch は、欠落データポイントの使用を最小限に抑えます。
先に「評価範囲」について少し説明したいと思います。
データが欠落している場合、CloudWatch は「評価期間」 に指定されている数よりも多くのデータポイントを取得しようとします。これが「評価範囲」になります。少し言い換えると、データが欠落してる時は評価期間にあたるデータポイントを確保するために、評価期間よりも広い範囲（評価範囲）でデータを拾いに行っているということです。この値は、アラーム期間の長さや、基づいているメトリクスが標準解像度か高解像度かによって異なっており、算出方法等については公開されていないそうです。そのため、結果から推測するしかなく、今回は 15 データポイントと想定されます。
では、上記を踏まえて今回の結果を見ていきましょう。
19:23 を超えると評価範囲（15 データポイント）内で取得できたデータポイントの数が評価期間（10 データポイント)を下回るようになります。不足しているデータポイント分は、欠落データの処理方法に指定された結果が適用されます。今回の設定では、欠落データは「不正（閾値を超えている）」としているので、このタイミングで初めて HealthHostCount < 1 となっているデータポイントが検知され始めます。アラーム状態と判定するためには、HealthHostCount < 1 となっているデータポイントが 5 つ必要なため 19:23 から 5 分ほど掛かったことと、メトリクスがデータポイントとして取得されるまでに少し時間が掛かることから、状態が OK からアラーム状態になるのに 11 分掛かったということです。
ちなみに、今回の検証では EC2 を停止したためデータポイントが欠落しましたが、 EC2 は停止せずに Apache のみ停止するとデータは欠落せず HealthHostCount < 1 となります。その場合は、データポイントが欠落しないため ① と同じように 7 分程で OK からアラーム状態になります。（データが欠落しなければ、起動時と同様に評価期間で判断されるため 7 分で状態が変化するということです）
さいごに
監視の目的で気軽に CloudWatch アラームを使ってましたが、思ったより奥が深いなと感じました。最初に設定してそのままにしておくのではなく、状態変化のタイミングをみながらチューニングするのが大事ですね。