CloudWatch アラーム
このソリューションは、注意が必要な運用状態をモニタリングする 2 つの CloudWatch アラームをデプロイします。デフォルトでは、これらのアラームには通知アクションが設定されていません。各アラームに Amazon SNS トピックをサブスクライブして、問題が発生したときにオペレーターがすぐに通知を受け取るようにすることをお勧めします。
アラーム通知をサブクスライブする
アラームが発生したときに通知を受け取るには。
-
CloudWatch アラームコンソール
を開きます。 -
スタック名のプレフィックスが付いたアラーム (
my-stack-OrphanCleanupFailureなど) を検索します。 -
アラームを選択してから、[編集] を選択します。
-
[通知] で、[通知の追加] を選択します。
-
任意の通知エンドポイント (E メール、SMS、または Lambda) を使用して SNS トピックを選択または作成します。
-
[Update alarm] (アラームの更新) を選択します。
アラームごとに繰り返します。
OrphanCleanupFailure
| 属性 | 値 |
|---|---|
|
アラーム名 |
|
|
メトリクス |
|
|
Threshold |
>= 5 分以内に 1 回の失敗 |
|
欠落データの処理 |
しきい値超過 |
このアラームがモニタリングするもの: このソリューションは、3 つの防御レイヤーを使用して、ECS サービスが暴走するのを防ぎます。
-
レイヤー 1: 自動エラー処理 - テストオーケストレーションワークフローには、すべてのステップでエラー処理が含まれます。プロビジョニング、安定化、または実行中に何らかの障害が発生した場合、ワークフローは自動的にクリーンアップをトリガーして ECS サービスをドレインおよび削除します。
-
レイヤー 2: 実行失敗の検出 - オーケストレーションワークフロー自体が予期せず終了した場合 (例えば、通常のエラー処理をバイパスするタイムアウトや内部エラーなど)、EventBridge ルールは失敗を検出し、テストに関係するすべてのリージョンに対してクリーンアップを個別にトリガーします。
-
レイヤー 3: 時間単位の孤立のクリーンアップ - スケジュールされたプロセスは 1 時間ごとに実行され、アクティブなテストに関連付けられていない ECS サービスをスキャンして、強制的に削除します。これは最後の手段のセーフティネットです。レイヤー 1 とレイヤー 2 の両方が失敗しても、リークしたサービスは 1 時間以内に削除されます。孤立のクリーンアッププロセス自体が失敗すると、このアラームが発生します。
これが重要な理由: 孤立した ECS Fargate サービスは、DLT コンソールで可視化されないまま、引き続き実行され、料金が発生し続けます。通知サブスクリプションがないと、オペレーターは予期しないコストが請求書に表示されたときに初めて問題に気づくことになります。
推奨されるレスポンス: このアラームが発生した場合は、Amazon ECS コンソール
MetricFilterCount
| 属性 | 値 |
|---|---|
|
アラーム名 |
|
|
メトリクス |
|
|
Threshold |
>= 90 |
|
欠落データの処理 |
しきい値超過ではない |
このアラームがモニタリングするもの: このソリューションは、テスト実行中にライブメトリクスをサポートするために、ECS ロググループに CloudWatch メトリクスフィルターを動的に作成します。AWS は、各ロググループを 100 個のメトリクスフィルターに制限します。このアラームは、使用量がその制限の 90% に達すると発生します。
重要な理由: 制限に達すると、新しい負荷テストの実行は失敗します。
推奨されるレスポンス: 不要になったテストシナリオを削除します。テストシナリオが削除されると、ソリューションは関連するメトリクスフィルターを削除し、新しいテストのための容量を解放します。
