Amazon Web Services ブログ

Amazon CloudWatch アラームで繰り返し通知を送信する

この記事は How to enable Amazon CloudWatch Alarms to send repeated notifications (記事公開日: 2022 年 1 月 28 日) を翻訳したものです。

Amazon CloudWatch アラームは、Amazon CloudWatch メトリクスとネイティブに統合されています。 多くのAWSサービスはメトリクスを CloudWatch に送信します。また、AWSは、ユーザのアプリケーションのメトリクスをカスタムメトリクスとして出力できる多くのアプローチも提供しています。 CloudWatch アラームを利用して、メトリクスが静的しきい値を超えたり、異常検出帯域から外れたりといったメトリクスの変化を監視できます。 さらに、複数のアラームの計算結果を監視できます。 そして、 CloudWatch アラームは、状態が OK 、 ALARM 、 INSUFFICIENT_DATA の間で変化すると、アクションを自動的に開始します。

最も一般的に使用されるアラームアクションは、Amazon Simple Notification Service (SNS) トピックにメッセージを送信することにより、関心のある人に通知するか、後続の自動処理をトリガーすることです。 CloudWatch アラームは、状態が変化したときにのみアラームアクションを呼び出すように設計されています。 唯一の例外は Auto Scaling アクションです。このアクションでは、アラームの状態が指定された値である間、スケーリングアクションを定期的に呼び出し続けます。

特定の重大なアラームについて、繰り返し通知を行うことが役立つようなシナリオがあります。それは、対応するチームが迅速に行動を起こすように警告するためです。 この投稿では、Amazon EventBridgeAWS Step FunctionsAWS Lambda を使用して、指定した CloudWatch アラームの繰り返し通知を有効にする方法を紹介します。 また、同じソリューションモデルでアラームの状態変化を利用して実現できる、他のカスタマイズのユースケースについても説明します。

概要

2019 年以降、 Amazon EventBridge は Amazon CloudWatch と統合されており、CloudWatch アラームの状態が変化すると CloudWatch アラーム状態変化イベントが EventBridge サービスに送信されるようになっています。 ルールパターンをカスタマイズすることで、以下のような事象をキャプチャする EventBridge ルールを作成できます。

  • すべてのアラームのステージ変更イベント
  • アラームの特定の状態への移行
  • 名前に特定のプレフィックスが付いたアラームの状態変更イベント

イベントが一致すると、ルールが後続の自動処理を呼び出して、アラームの状態変更イベントを処理します。 このソリューションは、AWS Step Functions を使用して、アラームの繰り返し通知を行うワークフローを設定します。

このソリューションでは、 CloudWatch アラームのリソースに特定のタグを適用することで、アラームの繰り返し通知を有効にします。 Step Functions 内で、Lambda 関数はトリガーされたアラームのタグを取得し、特定のタグの <key:value> が存在する場合にのみ追加処理を実行します。 さらにこのアプローチでは、タグベースのリソースグループを作成することで、繰り返し通知が有効になっているすべてのアラームを一覧化できます。 リソースグループは、このソリューションのオプションとして含まれています。

ソリューションアーキテクチャ

このソリューションは AWS クラウド開発キット (CDK) アプリケーションとしてデプロイされ、下図の青い長方形内で強調表示されているリソースを AWS アカウントにデプロイします。 含まれるリソースは以下の通りです。

  • すべてのアラームの状態変更イベントをキャプチャする EventBridge ルール
  • アラームのタグをチェックし、アラームの現在の状態を取得して、アラームの既存のSNSアラームアクションに通知を送信する Lambda 関数
  • Wait タスク、タスクとしての前述の Lambda 関数、Choice タスクからなる Step Functions ステートマシン
  • EventBridge が Step Functions を呼び出すために使用する AWS Identity and Access Management (IAM) ロールと、Lambda が必要なアクションを実行するために利用する IAM ロールの 2 つの IAM ロール
  • (オプション) 繰り返し通知を有効化するタグが付与された CloudWatch アラームをすべて含む、タグベースのリソースグループ

この投稿で説明するアーキテクチャ図

このソリューションは次のように動作します。

  1. CloudWatch アラームがトリガーされ、 ALARM 状態になります。
  2. CloudWatch アラームは、関連する SNS アラームアクションに最初のアラーム通知を送信します。
  3. CloudWatch アラームサービスがアラーム状態変更イベントを送信し、EventBridge ルールがトリガーされます。使用されるルールパターンは次のとおりです。このルールは、アラームの ALARM 状態への遷移をすべてのアラームについてキャプチャします。
    CloudWatch アラームの ALARM 状態への変化をキャプチャするために使用する EventBridge ルールパターン
  4. このルールに一致するイベントが発生すると、 EventBridge ルールは Step Functions ターゲットを呼び出します。
  5. Step Functions が実行を開始すると、まず Wait ステートに遷移します (下図の「Wait X Seconds」) 。待機する秒数は CDK アプリケーションで設定することができ、その設定内容はステートマシン定義に渡されます。
  6. 次に、 Step Functions は Lambda 実行タスクに遷移します (下図の「Check alarm tag and status」)。Lambda 実行タスクは以下の処理を実行します。
    1. アラームに、指定したタグのキーと値があるかどうかを確認します (例:RepeatedAlarm:true)。タグがない場合、関数は終了します。
    2. アラーム名に対して DescribeAlarms API を実行し、アラームの現在の状態を確認します。
    3. DescribeAlarms API 呼び出しから返された既存のアラームのステータスを、アラームをサブスクライブしているすべてのSNSトピックに送信します。
    4. アラームの現在の状態を、元の受信イベントとともに Step Functions に返します。
    5. Choice ステート (下図の「Is alarm still in ALARM state?」) は、 Lambda 関数が返したアラームの状態をチェックし、アラームの状態が「ALARM」の場合は Wait ステートに戻るようにワークフローに指示します。すでに「ALARM」状態でなくなっていれば、 Step Functions の実行を終了します。

投稿中で説明した StepFunctions のステートマシン上記ワークフローでのアラームの繰り返し通知は、次の場合に停止します。

  • アラームが ALARM 状態ではなくなった
  • アラームが削除された
  • 指定したタグがアラームから削除された

手順

前提条件

Step 1:AWS CDK でソリューションをデプロイする

CDK アプリケーションをデプロイする前に、このドキュメントで記載されているように、AWS CDK CLI がインストールされ、AWS アカウントがブートストラップされていることを確認してください。 次に、ターミナルから次のコマンドを実行して、ソリューションのコードをダウンロードしてデプロイします。

git clone https://github.com/aws-samples/amazon-cloudwatch-alarms-repeated-notification-cdk.git
cd amazon-cloudwatch-alarms-repeated-notification-cdk
npm install
npm run build
cdk bootstrap #Required for first time CDK deployment
cdk deploy --parameters RepeatedNotificationPeriod=300 --parameters TagForRepeatedNotification=RepeatedAlarm:true --parameters RequireResourceGroup=false

「cdk deploy」コマンド実行時、次のパラメーターを設定することもできます。

  • RepeatedNotificationPeriod:アラームからの繰り返し通知の間隔 (秒単位)。 CDK コードのデフォルト値は 300 秒に設定されています。
  • TagForRepeatedNotification:アラームの繰り返し通知を有効にするために使用されるタグ。 キーと値のペアである必要があります。 このパラメーターのデフォルト値は RepeatedAlarm:true です。
  • RequireResourceGroup:繰り返し通知が有効な CloudWatch アラームを一括で監視するための、タグベースのリソースグループを作成するかどうか。 許可される値は true/false のいずれかです。

Step 2:デプロイ完了を待つ

新規のデプロイとなるため、対象アカウントで作成される IAM リソースの概要が表示されます。 これらの IAM リソースは、ソリューションのコンポーネントが使用するものです。 アカウント内の既存の IAM リソースは変更されません。 変更を確認し、「y」を入力して承認できます。すると、デプロイが続行されます。

ソリューションが実際にアカウントにデプロイされる前に、CDK CLI ツールは作成される IAM リソースの概要を表示し、承認を求めます。

ターミナルからデプロイの進行状況が表示されるので、完了を待ちます。また、 CloudFormation からデプロイの進行状況を確認することもできます。

Step 3:ソリューションをテストする

デプロイが完了したら、タグを適用して、アラームでソリューションをテストできます。

  • テスト用に、ALARM 状態にあり、SNS アラームアクションが関連付けられているアラームを見つけます。
  • 次の AWS CLI コマンドを使用して、選択したアラームにタグを適用します。
    aws cloudwatch tag-resource --resource-arn arn:aws:cloudwatch:<region>:<account_id>:alarm:<alarm_name> --tags Key=RepeatedAlarm,Value=true
  • set-alarm-state CLI コマンドを使用して、手動でアラーム状態を OK に変更します。
    aws cloudwatch set-alarm-state --alarm-name <alarm_name> --state-value OK --state-reason "test"
    
  • 次のアラーム評価を待ちます。 標準アラームの場合、1 分以内に再評価されて、実際の状態に移行します。
  • 5 分ごとにアラーム通知を受け取れることを確認します。 繰り返し通知は次のようなタイトルになっています。

アラームの繰り返し通知のタイトルは次のようになります: “ALARM: <alarm-name> remains in ALARM state in <region>”

Step 4:繰り返し通知が有効になったアラームをすべて見る

AWS Resource Groups を使用すると、タグに基づいて AWS リソースを検索したりグループ化したりできます。 この投稿では、リソースグループを利用して、繰り返し通知が有効なアラームを集約したビューを作る方法を紹介します。

  • Resource Groups & Tag Editor コンソールに移動します。
    AWS コンソールで、「Resource Groups & Tag Editor」のサービスを検索します
  • CDK コードをデプロイするときに RequireResourceGroup パラメータを true にしていれば、「repeatedAlarmsGroup」という名前のタグベースのリソースが表示されます。
    [保存されたリソースグループ] の下に、「RepeatedAlarmsGroup」という名前のタグベースのリソースグループが表示されます。
  • 繰り返し通知が有効になっているアラームをすべて表示できます。
    「RepeatedAlarmsGroup」の詳細と、このリージョンで繰り返し通知タグが付いている CloudWatch アラームのリストが表示されます。

Step 5:繰り返し通知を無効化し、アラームのタグを削除する

次のCLIコマンドを実行して、 CloudWatch アラームからタグを削除します。 前のステップで作成されたリソースグループからアラームが消えたことが確認できます。

aws cloudwatch untag-resource --resource-arn arn:aws:cloudwatch:<region>:<account_id>:alarm:<alarm_name> --tag-keys RepeatedAlarm

参考

2021年4月、 EventBridge はクロスリージョンのイベントルーティングをサポートするようになりました。これにより、どこか一つのサポートされたリージョンにこのソリューションをデプロイすれば、すべての商用 AWS リージョンのアラームに対して繰り返し通知ワークフローを処理できます。 このソリューションをデプロイできるリージョンの一覧はこちらで、この中からデプロイ先を選択できます。 ソリューションの図は以下のようになります。

「CloudWatch アラーム状態変化」イベントは、クロスリージョンの EventBus を使用して、サポートされている単一のリージョンに集約され、送信先リージョンのソリューションによって処理されます。

このフレームワークにより、あらゆる商用リージョンからのアラーム状態変化イベントを、単一のサポートされたリージョンに集約できます。 そのため、リソース管理とトラブルシューティングに関連する運用上のオーバーヘッドを大幅に削減できます。

また、 Amazon EventBridge でアラーム状態変化イベントをキャプチャして後続ワークフローを設定し、Amazon EventBridge がサポートするさまざまなターゲットを利用した高度なアラーム処理タスクも実行できます。 例えば、アラームメッセージを改善/整形/pretty-printしたり、Lambda 関数ターゲットや SSM オートメーションでプレイブックを実行したりできます。

クリーンアップ

この投稿で説明した例で発生する追加のインフラストラクチャ費用を回避するには、作成したすべてのリソースを削除してください。 次のコマンドを実行して、リソースをクリーンアップするだけです。

cd amazon-cloudwatch-alarms-repeated-notification-cdk
cdk destroy

また、このソリューションで作成された Lambda 関数は、「/aws/lambda/RepeatedCloudWatchAlarm」プレフィックスのついた CloudWatch ロググループにログを記録します。 CloudWatch ログストレージ料金を避けるために、ロググループも削除してください。

まとめ

この投稿では、Amazon Eventbridge と AWS Step Functions を介してアラームの状態変更イベントを利用することで、CloudWatch アラームでの繰り返し通知を実現するソリューションを提供しました。 このソリューションにより、ミッションクリティカルなアラームを見逃すことがなくなり、インシデントの応答時間が改善されること願っています。また、同じフレームワークを拡張して、より高度なアラーム処理タスクを実行することもできます。

著者について

Sarah Luo

Sarah Luo は、オーストラリアのシドニーに拠点を置くAWSプレミアムサポートエンジニアです。 Sarah は Amazon CloudWatch サービスの Subject Matter Expert であり、顧客がベストプラクティスに即して AWS の監視サービスを利用するのを支援するのが大好きです。彼女はテクノロジーを使用して、顧客のニーズに対応するソリューションを作成することを楽しんでいます。

Jie Dong

Jie Dongは、オーストラリアのシドニーに拠点を置くAWSクラウドアーキテクトです。 Jie は自動化に情熱を傾けており、顧客が生産性を向上させるためのソリューションを開発するのが大好きです。 イベント駆動型のシステムとserverless framework が彼の強みです。 Jie は余暇の時間でスマートホームの構築に取り組み、新しいスマートホームガジェットを探すのが大好きです。

Nimita Shrivastava

Nimita は、AWS のシニアクラウドサポートエンジニアです。 彼女は、顧客が複雑なネットワーキングの問題を解決するのを支援し、さまざまなユニークなシナリオに合わせたソリューションとベストプラクティスを提供します。 Nimita は、ボストンのノースイースタン大学でコンピューターネットワーキングを専攻し、通信システム管理の修士号を取得しています。

翻訳はソリューションアーキテクトの馬渕が担当しました。原文はこちらをご覧ください。