ロードバランサーがHTTPCode_Backend_5XX
メトリックとsum
統計を使用して5xxをスローしていることを知らせるアラームを設定しています。問題は、sum
が0をデータポイントとして登録しないため、5xxがスローされない場合、アラームが不十分なデータとして扱われることです。これは特にイライラします。5xxが多すぎる(アラーム状態)ときや、正常に戻ったときに通知するようにSNSをセットアップしているからです。厄介なことに、0 5xxsはINSUFFICIENT DATA
ステータスにあることを意味しますが、1 5xxはOK
ステータスにあることを意味します。これを回避する方法はありますか?理想的には、データがまったくない(不十分なデータ)のではなく、ゼロのデータポイントとして表示されるものを0個だけにしたいです。
2017年3月 の時点で、欠落データを許容可能なものとして扱うことができます。これにより、アラームがINSUFFICIENTとしてマークされなくなります。
TreatMissingData プロパティを使用して、CloudFormationでこれを設定することもできます。
一部のアラームについても同様の問題がありました。オーバーヘッドを本当に処理したい場合は、いくつかの作業で実際にこの動作を回避できます。
SNS通知を電子メールに直接送信する代わりに、ラムダ関数を作成し、SNSトピックに通知があるとそれをトリガーしました。
これにより、アラームがトリガーされたときに実行できるアクションをより詳細に制御できます。コンテキストは古い状態の値も提供します。
幸いなことに、始めるためのラムダテンプレートが既にあります。 https://aws.Amazon.com/blogs/aws/new-slack-integration-blueprints-for-aws-lambda/
CloudWatchアラームをSlackに送信するように設計されたものを選択してください。その後、必要に応じてコードを変更し、スラック部分を破棄してメールを使用するか、スラックのままにしておくことができます。 (これは私たちがやったことであり、魅力のように機能します)
私は2年前にAWSフォーラムでこれを求めました: ---(https://forums.aws.Amazon.com/thread.jspa?threadID=153753&tstart=
残念ながら、特定の状態変化に基づいて通知を作成することはできません(あなたの場合、状態がALARMからOKに変わったときに通知が必要ですが、状態がINSUFFICIENTからOKに変わったときではありません)。私もあなたがそれを求めることを提案することができます、そして、願わくば、それが最終的に加えられることを望みます。
INSUFFICIENT状態にあることが多いメトリックについては、通常、ALARMSの通知を作成するだけで、これらのメトリックに対してOKの通知はありません。彼らが解決した場合。