69. アラームは3状態の状態機械である — M out of N評価と欠落データの4つの流儀
CloudWatchアラームがどうやって「鳴る/鳴らない」を決めているのか——状態の遷移、N個中M個の数え方、そしてデータが来なかったときの4つの流儀を、上から下へ図で追っていきます。
① アラームは常に3状態のどれか
- 「Similar to how each alarm is always in one of three states」——アラームは常にこの3状態のいずれか
- ダッシュボード上ではOK=無色、ALARM=赤、INSUFFICIENT_DATA=灰色で表示される
アラームは「壊れているか/いないか」の2値ではなく、「判断できない(INSUFFICIENT_DATA)」を含む3状態の有限状態機械(FSM)である。状態×入力→次状態という遷移表がこの図の正体。
② アクションは状態変化の瞬間だけ
- 「An alarm invokes actions only when the alarm changes state.」——アクションは状態変化時のみ
- 「The exception is for alarms with Auto Scaling actions. For Auto Scaling actions, the alarm continues to invoke the action once per minute that the alarm remains in the new state.」——Auto Scalingアクションのみ、新状態に留まる限り毎分再発火
- アクション先はSNSトピック通知/EC2アクション/Auto Scalingアクションなど
状態が同じままなら何もしない、変わった瞬間だけ動く——これがエッジトリガの発想。ALARM→SNSトピックへの通知は、メッセージング編で見たpub/subの購読者へファンアウトする現場そのもの。
③ 評価の3つのつまみ: period × N × M
- ドキュメントの例そのまま——「Datapoints to Alarm is only 2 while Evaluation Periods is 3. This is a 2 out of 3, M out of N alarm.」
- 評価期間には上限がある: periodが1時間(3600秒)以上なら最大7日分、それ未満なら最大1日分(period × evaluation periods で計算)
M=N=1なら「1回でも跨いだら即ALARM」の敏感なアラーム。M<Nにすると「N回中M回」を要求し、瞬間的なスパイク1発では鳴らなくなる。これがヒステリシス(チャタリング防止)——閾値を1度跨いだだけでは反応させない制御工学の基礎の実装。
④ 欠落データの扱いは4択
- 4択と各挙動は原文通り——「notBreaching – Missing data points are treated as "good"」「breaching – ... treated as "bad"」「ignore – The current alarm state is maintained」「missing – If all data points in the alarm evaluation range are missing, the alarm transitions to INSUFFICIENT_DATA.」
- 「The default behavior is missing.」——デフォルトは missing
- AWS/DynamoDB名前空間のメトリクスは例外的にデフォルトが ignore(欠落時は現状維持)
欠落は「良い」とも「悪い」とも決めつけられない——だから利用者が意味を与える。データポイントもアラームと同じ3分類(非超過/超過/欠落)なのが対称的。
⑤ 選び方: 途絶=異常か、無音=正常か
- 原文の例そのまま——「a metric that continually reports data, you might want to treat missing data points as breaching」
- 「a metric that generates data points only when an error occurs, such as ThrottledRequests in Amazon DynamoDB, you would want to treat missing data as notBreaching」
- EC2の停止/終了/再起動/復旧アクションを持つアラームは、欠落を missing にしてALARM時のみ発火する構成が推奨される
同じ「データが来ない」でも、メトリクスによって「異常」にも「正常」にも解釈が真逆になる。DynamoDB編で見たThrottledRequests(スロットリング)が、ここでは「普段は無音であるべきメトリクス」の代表例として再登場する。
⑥ 欠落設定は「最後の手段」
- 「CloudWatch attempts to retrieve a higher number of data points than the number specified as Evaluation Periods. ... The time frame ... is the evaluation range.」
- 実データが足りるなら「the value you set for how to treat missing data is not needed and is ignored.」——欠落設定を使うのは実データがN個に満たないときだけ
- 「多めに取る」動作はデフォルトのスライディング評価ウィンドウの場合で、ウォールクロック評価ウィンドウでは period × evaluation periods ちょうどの点だけを取得する
- アラーム履歴は30日保持
- 複数アラームを束ねる複合アラーム(composite alarm)はルール式内の全条件が満たされたときだけALARMになり、状態変化時にSNS通知を送れるが、EC2アクション/Auto Scalingアクションは実行できない
欠落設定(notBreaching等)は常に効くわけではない——CloudWatchはまず実データをかき集め、それでも足りないときの穴埋めにだけ使う。だから「常時データが流れるメトリクス」では欠落設定がほとんど出番を持たない。複合アラームを使えば、複数のノイズの多いアラームを1つに束ねて、通知先を1本に絞れる。