0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@80-cloud

同じ「データ欠落」なのに、片方のアラームはOKで片方はALARMのままだった話

0
Posted at

はじめに

CloudWatchのアラーム一覧をなんとなく眺めていたら、同じEC2インスタンスに紐づく2つのアラームの表示が食い違っていることに気づきました。

  • myapp-prod-ec2-cpu-high → OK
  • myapp-prod-ec2-status-check-failed → ALARM

インスタンスは以前から意図的に停止していたもので、動いていないのだから両方とも同じように「データが来ない」状態のはずです。なのに片方はOK、片方はALARMのまま。最初は「片方だけ本当に何か壊れているのでは」と身構えました。

先に結論：原因は、2つのアラームでTreatMissingData(欠落データの扱い)の設定が異なっていたことでした。

環境

  • Amazon CloudWatch Alarms
  • Amazon EC2(調査対象は停止中のインスタンス)
  • AWS CLI
  • リージョン: ap-northeast-1(東京)

症状

コンソールのアラーム一覧はこう表示されていました。

名前 状態 最終状態の更新
myapp-prod-ec2-status-check-failed ⚠️ アラーム状態 2026-08-28 10:50:11 (UTC)
myapp-prod-ec2-cpu-high ✅ OK 2026-05-29 08:35:16 (UTC)

インスタンスの状態を確認すると、単にstoppedでした。

aws ec2 describe-instances \
  --instance-ids i-xxxxxxxxxxxxxxxxx \
  --query "Reservations[].Instances[].{State:State.Name,StateReason:StateTransitionReason}"

State: stopped
StateReason: User initiated (2026-08-28 10:34:54 GMT)

停止中なので、CPU使用率もステータスチェックのメトリクスも、どちらも新しいデータポイントは飛んできません。同じ「データが無い」状況のはずなのに、なぜ片方だけALARMなのか。

切り分け:何を比較したか

2つのアラームの詳細設定を、CLIで並べて見比べました。

aws cloudwatch describe-alarms \
  --alarm-names "myapp-prod-ec2-cpu-high" "myapp-prod-ec2-status-check-failed" \
  --query "MetricAlarms[].{Name:AlarmName,State:StateValue,MetricName:MetricName,TreatMissingData:TreatMissingData,Reason:StateReason}"

[
  {
    "Name": "myapp-prod-ec2-cpu-high",
    "State": "OK",
    "MetricName": "CPUUtilization",
    "TreatMissingData": "notBreaching",
    "Reason": "Threshold Crossed: 3 datapoints [...] were not greater than or equal to the threshold (80.0)."
  },
  {
    "Name": "myapp-prod-ec2-status-check-failed",
    "State": "ALARM",
    "MetricName": "StatusCheckFailed",
    "TreatMissingData": "breaching",
    "Reason": "Threshold Crossed: no datapoints were received for 1 period and 1 missing datapoint was treated as [Breaching]."
  }
]

TreatMissingDataの値が、片方はnotBreaching、もう片方はbreachingと、正反対になっていました。

原因:アラームごとの「欠落データの扱い」設定

CloudWatchアラームには、メトリクスのデータポイントが届かなかったときの扱いを決めるTreatMissingDataという設定があり、アラームごとに次の4種類から選べます(公式ドキュメント)。

設定 挙動
missing(既定) 欠落データポイントは評価に使わない。評価期間内のデータが全て欠落するとINSUFFICIENT_DATAになる
notBreaching 欠落データポイントを「閾値を超えていないもの」として評価する
breaching 欠落データポイントを「閾値を超えたもの」として評価する
ignore 現在のアラーム状態をそのまま維持する(欠落する前がALARMならALARMのまま)

今回のケースでは、

  • CPU使用率アラームはnotBreachingだったため、欠落データが「閾値を超えていないもの」として扱われ、結果としてOKになっていた
  • ステータスチェックアラームはbreachingだったため、データが1周期分来なかった時点で「閾値を超えたもの」として評価され、ALARMに切り替わった

念のため、誰かが誤って停止させた操作ではないかもCloudTrailで確認しました。

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=i-xxxxxxxxxxxxxxxxx \
  --start-time 2026-08-28T10:00:00Z --end-time 2026-08-28T11:00:00Z \
  --query "Events[].{Time:EventTime,Name:EventName,User:Username}"

Name: StopInstances
Time: 2026-08-28T19:34:55+09:00
User: (自分のIAMユーザー)

自分自身が意図的に停止した操作であることが裏付けられ、アラームの表示だけを見て焦る必要は無かったと分かりました。

解決:結論と実務での使い分け

今回は「壊れていた」わけではないので直す作業自体は不要でしたが、実務での使い分けとしては次のように整理できます。

  • 停止中は「異常ではない」として扱いたい → notBreaching
  • 停止前の状態(ALARMならALARM)をそのまま保持したい → ignore(「欠落したら正常にする」設定ではない点に注意)
  • データが来ないこと自体を異常として検知したい → breaching

なお、EC2を停止・終了・再起動・復旧させるアクション付きのアラームについては、データ欠落だけで誤って操作が実行されないようmissing(既定)のままにしておくことをAWSは推奨しています(Create alarms that stop, terminate, reboot, or recover an instance)。ここは「アラーム状態が変わること」と「その結果アクション(通知・自動操作)が実行されること」を分けて考えると理解しやすいです。

教訓

  • CloudWatchアラームの状態(OK/ALARM)だけを見て「異常が起きた」と判断するのは早計で、TreatMissingDataの設定次第で同じ状況でも表示が変わる
  • 気になるアラームがあったら、コンソールの状態表示だけでなくdescribe-alarmsでTreatMissingDataとStateReasonをCLIで見比べると、原因の切り分けが早い
  • 操作主体を確認したい場合は、CloudTrailのイベントからUsernameやuserIdentityを確認する(役割を引き受けた操作の場合、Usernameがセッション名になることもある)

おわりに

「同じインスタンスの2つのアラームなのに表示が食い違っている」と気づいた瞬間は、正直ちょっとヒヤッとしました😅 蓋を開けてみれば、アラームごとの設定の違いによる想定内の挙動だったのですが、CloudWatchアラームは「閾値」だけでなく「データが無いときどうするか」まで個別に設計できるんだな、と実感した一件でした。同じ表示の食い違いに遭遇した人の参考になれば嬉しいです🙌

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?