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 EventBridge、AWS Step Functions、 AWS 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 アラームをすべて含む、タグベースのリソースグループ
このソリューションは次のように動作します。
- CloudWatch アラームがトリガーされ、 ALARM 状態になります。
- CloudWatch アラームは、関連する SNS アラームアクションに最初のアラーム通知を送信します。
- CloudWatch アラームサービスがアラーム状態変更イベントを送信し、EventBridge ルールがトリガーされます。使用されるルールパターンは次のとおりです。このルールは、アラームの ALARM 状態への遷移をすべてのアラームについてキャプチャします。
- このルールに一致するイベントが発生すると、 EventBridge ルールは Step Functions ターゲットを呼び出します。
- Step Functions が実行を開始すると、まず Wait ステートに遷移します (下図の「Wait X Seconds」) 。待機する秒数は CDK アプリケーションで設定することができ、その設定内容はステートマシン定義に渡されます。
- 次に、 Step Functions は Lambda 実行タスクに遷移します (下図の「Check alarm tag and status」)。Lambda 実行タスクは以下の処理を実行します。
- アラームに、指定したタグのキーと値があるかどうかを確認します (例:RepeatedAlarm:true)。タグがない場合、関数は終了します。
- アラーム名に対して DescribeAlarms API を実行し、アラームの現在の状態を確認します。
- DescribeAlarms API 呼び出しから返された既存のアラームのステータスを、アラームをサブスクライブしているすべてのSNSトピックに送信します。
- アラームの現在の状態を、元の受信イベントとともに Step Functions に返します。
- Choice ステート (下図の「Is alarm still in ALARM state?」) は、 Lambda 関数が返したアラームの状態をチェックし、アラームの状態が「ALARM」の場合は Wait ステートに戻るようにワークフローに指示します。すでに「ALARM」状態でなくなっていれば、 Step Functions の実行を終了します。
上記ワークフローでのアラームの繰り返し通知は、次の場合に停止します。
- アラームが ALARM 状態ではなくなった
- アラームが削除された
- 指定したタグがアラームから削除された
手順
前提条件
- AWS Command Line Interface (CLI) でアクセスできる AWS アカウント
- Node.js 10.13 以降
- AWS CDK
- Docker サービス (以下の手順を実行するときに稼働している必要があります)
Step 1:AWS CDK でソリューションをデプロイする
CDK アプリケーションをデプロイする前に、このドキュメントで記載されているように、AWS CDK CLI がインストールされ、AWS アカウントがブートストラップされていることを確認してください。 次に、ターミナルから次のコマンドを実行して、ソリューションのコードをダウンロードしてデプロイします。
「cdk deploy」コマンド実行時、次のパラメーターを設定することもできます。
- RepeatedNotificationPeriod:アラームからの繰り返し通知の間隔 (秒単位)。 CDK コードのデフォルト値は 300 秒に設定されています。
- TagForRepeatedNotification:アラームの繰り返し通知を有効にするために使用されるタグ。 キーと値のペアである必要があります。 このパラメーターのデフォルト値は RepeatedAlarm:true です。
- RequireResourceGroup:繰り返し通知が有効な CloudWatch アラームを一括で監視するための、タグベースのリソースグループを作成するかどうか。 許可される値は true/false のいずれかです。
Step 2:デプロイ完了を待つ
新規のデプロイとなるため、対象アカウントで作成される IAM リソースの概要が表示されます。 これらの IAM リソースは、ソリューションのコンポーネントが使用するものです。 アカウント内の既存の IAM リソースは変更されません。 変更を確認し、「y」を入力して承認できます。すると、デプロイが続行されます。
ターミナルからデプロイの進行状況が表示されるので、完了を待ちます。また、 CloudFormation からデプロイの進行状況を確認することもできます。
Step 3:ソリューションをテストする
デプロイが完了したら、タグを適用して、アラームでソリューションをテストできます。
- テスト用に、ALARM 状態にあり、SNS アラームアクションが関連付けられているアラームを見つけます。
- 次の AWS CLI コマンドを使用して、選択したアラームにタグを適用します。
- set-alarm-state CLI コマンドを使用して、手動でアラーム状態を OK に変更します。
- 次のアラーム評価を待ちます。 標準アラームの場合、1 分以内に再評価されて、実際の状態に移行します。
- 5 分ごとにアラーム通知を受け取れることを確認します。 繰り返し通知は次のようなタイトルになっています。
Step 4:繰り返し通知が有効になったアラームをすべて見る
AWS Resource Groups を使用すると、タグに基づいて AWS リソースを検索したりグループ化したりできます。 この投稿では、リソースグループを利用して、繰り返し通知が有効なアラームを集約したビューを作る方法を紹介します。
- Resource Groups & Tag Editor コンソールに移動します。
- CDK コードをデプロイするときに RequireResourceGroup パラメータを true にしていれば、「repeatedAlarmsGroup」という名前のタグベースのリソースが表示されます。
- 繰り返し通知が有効になっているアラームをすべて表示できます。
Step 5:繰り返し通知を無効化し、アラームのタグを削除する
次のCLIコマンドを実行して、 CloudWatch アラームからタグを削除します。 前のステップで作成されたリソースグループからアラームが消えたことが確認できます。
参考
2021年4月、 EventBridge はクロスリージョンのイベントルーティングをサポートするようになりました。これにより、どこか一つのサポートされたリージョンにこのソリューションをデプロイすれば、すべての商用 AWS リージョンのアラームに対して繰り返し通知ワークフローを処理できます。 このソリューションをデプロイできるリージョンの一覧はこちらで、この中からデプロイ先を選択できます。 ソリューションの図は以下のようになります。
このフレームワークにより、あらゆる商用リージョンからのアラーム状態変化イベントを、単一のサポートされたリージョンに集約できます。 そのため、リソース管理とトラブルシューティングに関連する運用上のオーバーヘッドを大幅に削減できます。
また、 Amazon EventBridge でアラーム状態変化イベントをキャプチャして後続ワークフローを設定し、Amazon EventBridge がサポートするさまざまなターゲットを利用した高度なアラーム処理タスクも実行できます。 例えば、アラームメッセージを改善/整形/pretty-printしたり、Lambda 関数ターゲットや SSM オートメーションでプレイブックを実行したりできます。
クリーンアップ
この投稿で説明した例で発生する追加のインフラストラクチャ費用を回避するには、作成したすべてのリソースを削除してください。 次のコマンドを実行して、リソースをクリーンアップするだけです。
また、このソリューションで作成された Lambda 関数は、「/aws/lambda/RepeatedCloudWatchAlarm」プレフィックスのついた CloudWatch ロググループにログを記録します。 CloudWatch ログストレージ料金を避けるために、ロググループも削除してください。
まとめ
この投稿では、Amazon Eventbridge と AWS Step Functions を介してアラームの状態変更イベントを利用することで、CloudWatch アラームでの繰り返し通知を実現するソリューションを提供しました。 このソリューションにより、ミッションクリティカルなアラームを見逃すことがなくなり、インシデントの応答時間が改善されること願っています。また、同じフレームワークを拡張して、より高度なアラーム処理タスクを実行することもできます。
著者について
翻訳はソリューションアーキテクトの馬渕が担当しました。原文はこちらをご覧ください。