TargetGroupのUnHealthyHostCountをCloudWatchアラームで監視する場合、AZの概念の含まれないメトリクスを選んだほうが良い
リファレンスの以下部分の、
UnHealthyHostCount
異常と見なされるターゲットの数。レポート条件: ヘルスチェックが有効になっている場合にレポートされます
統計値: 最も有用な統計値は Average、Minimum、および Maximum です。
[Dimensions] (ディメンション):
TargetGroup, LoadBalancer
TargetGroup, AvailabilityZone, LoadBalancer
ここ。
TargetGroup, LoadBalancer
TargetGroup, AvailabilityZone, LoadBalancer
下の方のAZを含むメトリクスだと、メトリクスで指定していないAZでターゲットが起動したときに、データが取れなくなる。
上の方のメトリクスを使えば、AZは気にしなくなるので、ターゲットがどのAZで起動していようと、データが取れなくなることはない。
CloudWatchアラームで、複合アラームを使わない場合、メトリクスとして指定できるのは1つなので、AZが含まれるメトリクスを指定してしまうと、対象でないAZでターゲットが起動したときにデータが取れない。
ECSでタスク1だと、タスクが起動するたびにAZが変わるので、タスク再起動時にデータが取れない状態になりうる。
CloudWatchで上記の下の方、AZを含まないメトリクスを指定する場合は以下をたどる
AWS名前空間
AWS/ApplicationELB
↓
メトリクス
AppELB 別、TG 別メトリクス
※ここでAZと表記があるものを避ける
↓
AppELB 別、TG 別メトリクス
↓
対象のALB/TargetGropの、UnHealthyHostCountを選択
そもそもECSの監視手法としてTargetGroupのUnHealthyHostCountを利用するのが適切か、検証が必要そう
同様に、起動中のタスク数、のチェックも有効なのかどうか。
Route53ヘルスチェックとかCloudWatch Synthetics使えばいいんだけどNW要件とかシステム的に無理とかだと工夫が必要