Cloudwatch メトリクスとアラームのイメージ
Cloudwatch メトリクスとアラームのイメージを図に書くと、こんなイメージです。以降で解説していきます。
AWS の Cloudwatch Metric のイメージ
CDK のAlarmを見てみると、threshold,datapointsToAlarm,evaluationPeriodsなどの用語がとても混乱しやすいです。
Cloudwatch メトリクスには、いくつか単位（Unit）と呼ばれる数値の観測の仕方の種類がありますが、今回は一番イメージがわかりやすい合計（Sum）方式を利用して例を見てみます。
Lambda にはThrottlesという、アカウントにおけるスロットルされた関数呼び出しの合計を観測するメトリクスがあるのでこれを例に取ります。
Cloudwatch メトリクスのPeriod（時間）
Cloudwatch メトリクスは、特定の期間にどのような値が取得できるのか？という値です。
Lambda のThrottlesであれば、1分間（デフォルト）に、どれだけスロットリングが発生したのか？という話になります。
（CDK ではmetric のperiod）
Cloudwatch メトリクスはシンプルでこのように特定の期間に観測された値を表します。
このメトリクスが生成される間隔がPeriodと呼ばれます。
Cloudwatch アラームのThreshold（閾値）
Cloudwatch アラームは、Cloudwatch メトリクスを利用してアラームを設定します。
Cloudwatch メトリクスの特定の期間に観測された値に対して、特定の閾値を設定します。これがthresholdと呼ばれます。
今回、Lambda のThrottlesが1分間に5回起きたらまずい！という制限をつけるとします。
以下のようなイメージになります。
Cloudwatch アラームの Data Point（データポイント）
先ほど設定したthresholdを超えると、対象のデータは違反したメトリクス（＝異常値）として観測されます。これを Cloudwatch アラームでは「データポイント」と呼ばれます。
今回、thresholdを5として設定したので、1分間に5回スロットリングが発生すると、データポイントとして扱われます。
Cloudwatch アラームはこのthresholdに到達しただけでは発火するわけではなく、あくまでデータポイントとしてカウントされるだけです。
Cloudwatch アラームのdatapointsToAlarm（アラーム発火に必要なデータポイント）とevaluationPeriods（評価期間）
Cloudwatch アラームが発火するためにはdatapointsToAlarmとevaluationPeriodsが必要になってきます。
Cloudwatch アラームは、評価対象のメトリクスのうち、どれだけデータポイントとなるメトリクス（異常と判定した値）があるのか、によってアラームが発火するかどうかが決まります。
この評価対象のメトリクスの数をevaluationPeriodsで決定します。
例えば、evaluationPeriodsで 5 を指定したならば、直近5つのメトリクスの遡って確認します。
この確認したメトリクスの中で、いくつデータポイントがあればアラームを発火するのか？、これがdatapointsToAlarmとなります。
今回、このdatapointsToAlarmを4として設定した場合、データポイントが4つ発生すると、アラームが発火することになります。
つまり、1分間隔で取得されるスロットリングが5回異常発生する事象が、5分間の中で（直近5回のメトリクスの中で）4回異常発生していたら発火する、というアラームになります。
Cloudwatch アラームはこれの繰り返し
Cloudwatch アラームは、このように対象とするメトリクスの幅を時間と一緒にスライドさせながらアラームを発生させるか否かをチェックしていく仕組みになっています。
Cloudwatch メトリクスとアラームは二重の構造
このように監視は、単一のメトリクスの中でのperiodとthresholdで異常が発生するか、と、複数のメトリクスを対象としてdatapointsToAlarmとevaluationPeriodsで異常が続くか、をみる二重構造になっています。
thresholdなどの名前がややこしくて私は混乱したのですが、この閾値を超えただけではあくまで観測した一つ数値が異常値がどうか、だけです。
Cloudwatch メトリクスのperiodと Cloudwatch アラームのthresholdだけでは、異常な状態が継続しているのか？がわかりません。
一時的な異常だけでは、システムが本当におかしくなって対処が必要なのか、それとも、無視していい一時的な異常なのかがわからないわけです。
そこで、このような構造にしてきっちり異常の継続が監視できるような構造になっているようです。
