CloudWatch Alarmは「評価範囲」に基づいて状態遷移する
概要
最近、CloudWatch Alarmの検証をしていた時に、CloudWatch Alarmがアラーム状態になった後、次のデータポイントが閾値を超えていない正常な値だったとしてもOK状態に回復しないことに気付きました。個人的には納得のいく答えに辿り着くことができたので記事にしてみます。
構成
以下の記事で作成した構成で実験しました。CloudWatch Agentで/var/log/secureをLogsに収集した後に、メトリクスフィルタでSSHパスワード認証失敗ログを拾ってアラームを発報するという構成です。
CloudWatch Alarmのパラメータは以下のようになっています。「しきい値：1分内の1データポイントのSSH-Failure-0≧10」とあるように、「期間」として設定した1分間の間に10回以上のSSHパスワード認証失敗が発生すると即座にアラーム状態に遷移します。
また、メトリクスフィルタの「デフォルト値:0」かつ「欠落データの処理：欠落データを適正として処理」のように設定しているため、/var/log/secureにおいてSSHパスワード認証失敗のログが発生しない限りOK状態を維持するような構成となっています。
事象
実際に1分間の間にSSHパスワード認証を10回以上失敗してみると、想定通りOK状態からアラーム状態に遷移しました。今回は「欠落データの処理：欠落データを適正として処理」と設定しているため、1分後の次の評価期間には欠落データが適正として認識され、OK状態に戻ると想定していました。しかし、実際に履歴を見ると、アラーム状態からOK状態に回復したのは6分後でした。
結論
評価範囲とは
この理由を一言で言えば、CloudWatch Alarmは「評価期間」ではなく「評価範囲」に基づいてアラームの状態遷移を判断しているからです。公式リファレンスに記載がありましたので、詳しく説明します。
CloudWatch Alarmにはアラームの作成時に設定する評価期間（Evaluation Period）という概念の他に、評価範囲（Evaluation Range）という概念が存在します。公式リファレンスでは "The time frame of the data points that it attempts to retrieve is the evaluation range." と定義されています。少しイメージしにくいですが「CloudWatch Alarmがアラーム状態遷移を評価するためのデータポイントを取得する対象となる時間範囲」と解釈できるのかなと思います。CloudWatch Alarmにおける状態遷移の判断基準が、評価範囲内のデータポイントの振る舞いとなるということですね。なお、状態遷移の判断基準となるデータポイント数の正確な値は決まっておらず、評価期間の長さやメトリクスの種類に応じて変化するようです。
取得を試みるデータポイントの正確な数は、アラーム期間の長さと、基づいているメトリクスが標準解像度か高解像度かによって異なります。
評価範囲に基づくアラーム状態への遷移
この評価範囲内のデータポイントがどういう状態ならアラーム状態に遷移するのかという疑問が湧いてくるのが自然だと思います。これは状況に応じて以下の3通りに分かれます。
- 評価範囲内のデータポイントが欠落していない場合
→ CloudWatchは収集された最新のデータポイントに基づいて状態を評価 - 評価範囲のデータポイントの一部が欠落しており、「評価範囲において正常に取得されたデータポイントの合計数」≧「アラームの評価期間」である場合
→ CloudWatchは正常に取得された最新のデータポイントに基づいて状態を評価 - 評価範囲のデータポイントの一部が欠落しており、「取得されたデータポイントの合計数」<「アラームの評価期間」である場合
→ CloudWatchは欠落データを「欠落データの処理」で指定したように認識して状態を評価
具体例を見ていきましょう。以下に23:10-23:17のアラームの状態遷移を図示しました。水色の部分が評価範囲、★がSSH-Failures-0が発生した事象を表しており、★の右下にSSHパスワード認証に失敗した回数を記載しています。検証の結果、今回の評価範囲は6データポイント分と想定されたため、図ではそのように表現しています。
23:10時点（一段目）では、23:05-23:10が評価範囲に該当します。23:10では、以下の画像から分かるように2回SSHパスワード認証に失敗しており、SSH-Failures-0メトリクスの値が2となっています。23:05-23:09の期間はサーバ操作をしていないため、データの欠落が発生しています。
ここでは、データの欠落が発生しており、「評価範囲において正常に取得されたデータポイントの合計数（1）」≧「アラームの評価期間（1）」となるため２番目のパターンが該当します。正常に取得された最新のデータポイントは23:10のものであり、SSH-Failures-0の値は2であり、閾値を超えていないためOK状態と評価されます。
23:11時点（二段目）では、23:06-23:11が評価範囲に該当します。23:11にSSH-Failures-0の値が10を超える事象が発生し、評価範囲の中にアラームをトリガーしたデータポイントが存在することとなります。
ここでは、データの欠落が発生しており、「評価範囲において正常に取得されたデータポイントの合計数（1）」≧「アラームの評価期間（1）」となるため２番目のパターンが該当します。正常に取得された最新のデータポイントは23:11のものなので、アラーム状態と評価されます。
23:12時点~23:16時点まで（三段目）は、常に評価範囲の中に閾値を超えるデータポイントが存在するため、23:11の場合と同様に２番目のパターンに該当し、アラーム状態と評価されます。
23:17時点（四段目）では、23:12-23:17が評価範囲に該当します。23:12-23:17の期間はサーバ操作をしていないため、評価範囲内の全てのデータポイントが欠落した状態になります。
ここでは、データの欠落が発生しており、「取得されたデータポイントの合計数(0)」<「アラームの評価期間(1)」となるため、3番目のパターンが該当します。今回は「欠落データを適正として処理」するため、ここでようやく23:11にアラーム状態になったアラームがOK状態に戻ります。
最後に
CloudWatch AlarmがOK状態に戻るタイミングがようやく分かった気がします。
ただ、評価期間として取得するデータポイントの数は変動するっぽいので、結局毎回試してみる必要がありそうですね...
Discussion