EC2停止後にCloudWatchアラームがALARM状態に変化してしまうときの解決法

CloudWatch_Alarm AWS
CloudWatch_Alarm
2022.01.27

発生事象

CloudWatch × SNSを利用してEC2の監視＆アラーム設定をした際、
EC2が停止しているにも関わらずアラートが通知されてしまう事象が発生しました。

下記はSNSから通知されるメールの一部抜粋になります。

You are receiving this email because your Amazon CloudWatch Alarm "アラーム名" in the "リージョン名" region has entered the ALARM state, because "Threshold Crossed: no datapoints were received for 1 period and 1 missing datapoints was treated as [Breaching]

本記事ではCloudWatch × SNSを利用したアラートのメール通知を実装する際に
不要な欠落データの処理方法を調査した結果を記録しております。

前提条件
　OS：Linux RHEL8
　AWSサービス：Amazon EC2 , Amazon CloudWatch , Amazon SNS
　対象メトリクス：disk_used_percent
　欠落データの処理設定：欠落データを不正(しきい値を超えている)として処理

こちら関連サイトです。

RHEL8のオンプレミス環境にCloudWatch Agentを導入する際のエラー対応
Red Hat Enterprise Linux8のオンプレミス環境にCloudWatch Agentを導入する際に様々なエラー対応を行いました。アクセス権限がない、構成設定が作成・設定されていない、プロキシ設定がないなどを解決。メトリクスやログを監視・転送するために必要な設定のため、分かりやすくまとめております。
sukeplog.com
2023.01.14
RHEL8のオンプレミス環境にCloudWatch Agentを導入する際のエラー対応

結論

CloudWatchアラームを以下修正する。

  1. 対象アラームを選択⇒アクション⇒編集
  2. 条件 > その他の設定 > 欠落データの処理設定を「欠落データを無視」に変更

この設定により、EC2停止後にCloudWatchアラームがALARM状態になることがなくなり
ALARM状態を通知するSNSの不要なメールがきっぱりなくなりました。

調査内容

アラームおよびデータポイントは以下3つの状態があります。

メトリクスアラームには次の状態があります。
・OK – メトリクスや式は、定義されているしきい値の範囲内です。
・ALARM – メトリクスまたは式が、定義されているしきい値を超えています。
・INSUFFICIENT_DATA – アラームが開始直後であるか、メトリクスが利用できないか、メトリクス用のデータが不足しているため、アラームの状態を判定できません。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html

CloudWatch にレポートされるデータポイントはそれぞれ、次の 3 つのカテゴリのいずれかの状態に該当します。
・Not breaching (しきい値内)
・Breaching (しきい値を超過)
・Missing (見つからない)

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html

今回はメール内容に[Breaching]と記載されていることから、
しきい値超過状態 = ALARM状態 にならないよう設定する必要があります。

CloudWatchアラーム設定から「条件 > その他の設定 > 欠落データの処理」が選択できます。

CloudWatchアラーム作成-欠落データ処理

欠落データの処理設定は下記4つになります。

  • 欠落データを適正(しきい値を超えていない)として処理
  • 欠落データを不正(しきい値を超えている)として処理
  • 欠落データを無視(アラーム状態を維持する)として処理
  • 欠落データを見つかりませんとして処理

この設定について、公式ユーザガイドでは以下のように定義付けられています。

アラームごとにCloudWatchが欠落データポイントを次のいずれかとして処理するように指定できます。
・notBreaching – 欠落データポイントは「良好」とされ、しきい値内として扱われます。
・breaching – 欠落データポイントは「不良」とされ、しきい値超過として扱われます。
・ignore – 現在のアラーム状態が維持されます。
・missing – アラーム評価範囲内のすべてのデータポイントがない場合、アラームは INSUFFICIENT_DATA に移行します。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html

アラームの状態およびデータポイントに正しい結果を返させるためにも
欠落データの処理設定を適切に施す必要があるといえます。

簡単な例を以下記載します。

例：18:00(JST)に自動停止するサーバの「disk_used_percent」を監視する場合

  • 欠落データを適正(しきい値を超えていない)として処理
    17:55(JST)にアラームがOK状態 → 18:00(JST)以降にOK状態
    17:55(JST)にアラームがAlart状態 → 18:00(JST)以降にOK状態
  • 欠落データを不正(しきい値を超えている)として処理
    17:55(JST)にアラームがOK状態 → 18:00(JST)以降にAlart状態
    17:55(JST)にアラームがAlart状態になる → 18:00(JST)以降にAlart状態
  • 欠落データを無視(アラーム状態を維持する)として処理
    17:55(JST)にアラームがOK状態 → 18:00(JST)以降にOK状態
    17:55(JST)にアラームがAlart状態になる → 18:00(JST)以降にAlart状態
  • 欠落データを見つかりませんとして処理
    17:55(JST)にアラームがOK状態 → 18:00(JST)以降にINSUFFICIENT_DATA 状態
    17:55(JST)にアラームがAlart状態になる → 18:00(JST)以降にINSUFFICIENT_DATA 状態

これらのことから
欠落データの処理設定を「欠落データを無視」に変更する結論に至りました。

参考文献

コメント

タイトルとURLをコピーしました