# CloudWatch アラームの欠落データの処理の設定
<a name="alarms-and-missing-data"></a>

場合によっては、メトリクスの予想されるすべてのデータポイントが CloudWatch にレポートされないことがあります。たとえば、接続が失われた場合、サーバーがダウンした場合、メトリクスがデータを断続的にのみ報告する設計になっている場合などに、これが発生する可能性があります。

CloudWatch では、アラームを評価する際の欠落データポイントの処理方法を指定できます。これにより、モニターリング対象のデータのタイプに適した場合にのみ `ALARM` 状態になるように、アラームを設定できます。欠落データが問題を示すものではない場合の誤検出を避けることができます。

各アラームが常に 3 つの状態のいずれかであるように、CloudWatch にレポートされるデータポイントはそれぞれ、次の 3 つのカテゴリのいずれかの状態に該当します。
+ Not breaching (しきい値内)
+ Breaching (しきい値を超過)
+ Missing (見つからない)

アラームごとに、CloudWatch が欠落データポイントを次のいずれかとして処理するように指定できます。
+ `notBreaching` – 欠落データポイントは「良好」かつしきい値内として扱われます。
+ `breaching` – 欠落データポイントは「不良」とされ、しきい値超過として扱われます。
+ `ignore` – 現在のアラーム状態が維持されます。
+ `missing` – アラーム評価範囲内のすべてのデータポイントがない場合、アラームは INSUFFICIENT\$1DATA に移行します。

最適な選択は、メトリクスの種類とアラームの目的によって異なります。例えば、継続的にデータをレポートするメトリクスを使用してアプリケーションのロールバックアラームを作成する場合、欠落しているデータポイントは何らかの問題の存在を示している可能性があるため、違反として扱うことが推奨されます。ただし、Amazon DynamoDB の `ThrottledRequests` など、エラー発生時のみデータポイントを生成するメトリクスの場合は、`notBreaching` として欠落データを処理します。デフォルトの動作は `missing` です。

**重要**  
Amazon EC2 メトリクスに設定されたアラームは、メトリクスデータポイントが欠落している場合、一時的に INSUFFICIENT\$1DATA 状態になることがあります。まれに、Amazon EC2 インスタンスが正常であっても、メトリクスレポートが中断されたときに、これが発生することがあります。アクションの停止、終了、再起動、復旧を行うように設定された Amazon EC2 メトリクスのアラームについては、欠落データを `missing` として扱い、アラームが ALARM 状態にある場合にのみトリガーされるように、これらのアラームを設定することが推奨されます。

アラームに最適なオプションを選択することで、アラームが、不要で誤解を招く状態に変更されることを防ぐだけでなく、システムの状態をさらに正確に表すことができます。

**重要**  
`AWS/DynamoDB` 名前空間のメトリクスを評価するアラームは、デフォルトで欠落データを無視します。アラームによる欠落データ処理に関して別のオプションを選択した場合は、これをオーバーライドできます。`AWS/DynamoDB` メトリクスに欠落データがある場合、そのメトリクスを評価するアラームは現在の状態のままです。

## データが欠落した場合のアラーム状態の評価方法
<a name="alarms-evaluating-missing-data"></a>

アラームが状態を変更するかどうかを評価するたびに、CloudWatch は [**Evaluation Periods (評価期間)**] に指定されている数よりも多くのデータポイントを取得しようとします。取得を試みるデータポイントの正確な数は、アラーム期間の長さと、基づいているメトリクスが標準解像度か高解像度かによって異なります。取得を試みるデータポイントのタイムフレームは*評価範囲*です。

CloudWatch がこれらのデータポイントを取得すると、次の処理が実行されます。
+ 評価範囲内のデータポイントが欠落していない場合、CloudWatch は収集された最新のデータポイントに基づいてアラームを評価します。評価されるデータポイントの数は、アラームの [**Evaluation Periods (評価期間)** ] と同じです。評価範囲内のよりさかのぼった時点からの余分なデータポイントは必要なく、無視されます。
+ 評価範囲内のデータポイントの一部が欠落しているが、評価範囲から正常に取得された既存のデータポイントの合計数がアラームの [**Evaluation Periods (評価期間)** ] 以上である場合、CloudWatch は、最新の正常に取得された最新のデータポイントに基づいたアラームの状態を評価します (評価範囲内のよりさかのぼった時点からの必要な追加データポイントを含む)。この場合、欠落データを処理する方法に設定した値は不要であり、無視されます。
+ 評価範囲のデータポイントの一部が欠落しており、取得された既存のデータポイントの数がアラームの [**Evaluation Periods (評価期間)**] の数を下回る場合、CloudWatch によって、欠落データ部分に欠落データの処理方法に指定された結果が入力され、アラームが評価されます。ただし、評価範囲内のすべての実際のデータポイントが評価に含まれます。CloudWatch は、欠落データポイントの使用を最小限に抑えます。

**注記**  
この動作の特殊なケースは、メトリクスのフローが停止した後の一定期間、CloudWatch アラームが最後のデータポイントのセットを繰り返し再評価する可能性があることです。この再評価により、メトリクスのストリームが停止する直前にアラームの状態が変更されていた場合に、アクションが再実行される可能性があります。この動作を軽減するには、より短い期間を使用します。

次の表は、アラーム評価の動作の例を示しています。最初の表では、[**Datapoints to Alarm (アラームを発生させるデータポイント数)**] と [**Evaluation Periods (評価期間)**] はどちらも 3 です。CloudWatch は、直近の 3 個のデータポイントの一部が欠落している場合、アラームを評価する際に直近のデータポイントを 5 個取得します。5 はアラームの評価範囲です。

列 1 は、評価範囲が 5 であるため、最新の 5 つのデータポイントを示しています。これらのデータポイントが、右側が最新のデータポイントになるように表示されます。0 は違反していないデータポイント、X は違反しているデータポイント、- は欠落しているデータポイントを示します。

列 2 は、3 つの必要なデータポイントの欠落数を示します。最新の 5 個のデータポイントが評価されている場合でも、アラーム状態を評価する上で必要なデータポイントは 3 個 ([**評価期間**] の設定) のみです。列 2 のデータポイントの数は、欠落データの処理方法に関する設定を使用して「入力する」必要があるデータポイント数です。

列 3～6 では、列ヘッダーが欠落データの処理方法を示す値になります。これらの列の行には、欠損データを処理するためのこれらの可能な方法ごとに設定されたアラーム状態が表示されます。


| データポイント | 埋める必要のあるデータポイントの数 | MISSING | IGNORE | BREACHING | NOT BREACHING | 
| --- | --- | --- | --- | --- | --- | 
|  0 - X - X  |  0  |  `OK`  |  `OK`  |  `OK`  |  `OK`  | 
|  - - - - 0  |  2  |  `OK`  |  `OK`  |  `OK`  |  `OK`  | 
|  - - - - -  |  3  |  `INSUFFICIENT_DATA`  |  現在の状態を維持  |  `ALARM`  |  `OK`  | 
|  0 X X - X  |  0  |  `ALARM`  |  `ALARM`  |  `ALARM`  |  `ALARM`  | 
|  - - X - -   |  2  |  `ALARM`  |  現在の状態を維持  |  `ALARM`  |  `OK`  | 

前の表の 2 行目で、欠落データが超過として処理されても、アラームは `OK` のままです。既存のデータポイント 1 個が超過しておらず、これが超過として処理される欠落データポイント 2 個とともに評価されるためです。次回このアラームが評価される際にデータがまだ欠落したままであれば `ALARM` に遷移します。これは、超過していないデータポイントが、評価範囲に含まれなくなるためです。

3 番目の行では、最新の 5 つのデータポイントがすべて欠落しており、欠落したデータの処理方法に関するさまざまな設定がアラームの状態にどのように影響するかを示しています。欠落しているデータポイントが超過していると見なされるとアラームは ALARM 状態になり、超過していないと見なされるとアラームは OK 状態になります。欠落しているデータポイントを無視すると、アラームは欠落しているデータポイントよりも前の現在の状態を保持します。また、欠落しているデータポイントが欠落しているとみなされた場合、アラームには評価を行うのに十分な最近の実際のデータがないため、INSUFFICIENT\$1DATA に入ります。

4 行目では、最新の 3 つのデータポイントが超過しており、アラームの [**Evaluation Periods (評価期間)**] と [**Datapoints to Alarm (アラームを実行するデータポイント)**] が両方とも 3 に設定されているため、アラーム は `ALARM` 状態になります。この場合、欠落データポイントは無視され、欠落データの評価方法の設定は必要ありません。これは、評価する実際のデータポイントが 3 つあるためです。

行 5 は、*早期アラーム状態*と呼ばれる、アラーム評価の特別なケースを表します。詳細については、「[アラーム状態への早期移行の回避](#CloudWatch-alarms-avoiding-premature-transition)」を参照してください。

次の表では、[**期間**] は再び 5 分に設定され、[**Datapoints to Alarm (アラームを発生させるデータポイント数)**] は 2 のみですが [**評価期間**] は 3 です。つまり 3 個のうち 2 個、N 個中 M のアラームです。

評価範囲は 5 です。これは、取得される最近のデータポイントの最大数であり、一部のデータポイントが欠落している場合に使用できます。


| データポイント | 欠落データポイント数 | MISSING | IGNORE | BREACHING | NOT BREACHING | 
| --- | --- | --- | --- | --- | --- | 
|  0 - X - X  |  0  |  `ALARM`  |  `ALARM`  |  `ALARM`  |  `ALARM`  | 
|  0 0 X 0 X  |  0  |  `ALARM`  |  `ALARM`  |  `ALARM`  |  `ALARM`  | 
|  0 - X - -  |  1  |  `OK`  |  `OK`  |  `ALARM`  |  `OK`  | 
|  - - - - 0  |  2  |  `OK`  |  `OK`  |  `ALARM`  |  `OK`  | 
|  - - - X -  |  2  |  `ALARM`  |  現在の状態を維持  |  `ALARM`  |  `OK`  | 

行 1 と 2 では、最新の 3 つのデータポイントのうちの 2 つが超過しているため、アラームは常に ALARM 状態になります。行 2 では、評価範囲内の最も古い 2 つのデータポイントは不要です。これは、最新の 3 つのデータポイントのいずれも欠落していないためです。したがって、これらの 2 つの古いデータポイントは無視されます。

行 3 と 4 では、アラームは ALARM 状態になります。この場合、欠落データが超過として扱われる場合のみ、最新の 2 つの欠落データポイントは両方とも超過として扱われます。行 4 では、超過として扱われるこれらの 2 つの欠落データポイントは、ALARM 状態をトリガーするのに必要な 2 つの超過データポイントを提供します。

行 5 は、*早期アラーム状態*と呼ばれる、アラーム評価の特別なケースを表します。詳細については、以下のセクションを参照してください。

### アラーム状態への早期移行の回避
<a name="CloudWatch-alarms-avoiding-premature-transition"></a>

CloudWatch アラーム評価には、データが断続的な場合にアラームが早く ALARM 状態になる誤アラームを回避しようとするロジックが含まれています。前のセクションの表の行 5 に示した例は、このロジックを示しています。これらの行および次の例では、[**Evaluation Periods (評価期間)**] は 3 で、評価範囲は 5 データポイントです。[**Datapoints to Alarm (アラームを実行するデータポイント)**] は 3 ですが、N 個のうち M の例を除いて、[**Datapoints to Alarm (アラームを実行するデータポイント)**] は 2 です。

アラームの最新のデータが `- - - - X` で 、4 つのデータポイントが欠落しており、最新のデータポイントとして超過データポイントがあるとします。次のデータポイントは超過していない可能性があるため、データが `- - - - X` または `- - - X -` で、[**Datapoints to Alarm (アラームを実行するデータポイント)**] が 3 の場合、アラームはすぐに ALARM 状態になりません。このようにして、次のデータポイントが超過しておらず、データが `- - - X O` または `- - X - O` になる場合に誤検出が回避されます。

ただし、最後の数個のデータポイントが `- - X - -` の場合、欠落しているデータポイントが欠落していると見なされても、アラームは ALARM 状態になります。これは、**[Evaluation Periods]** (評価期間) 中のデータポイントのうち、利用可能な最も古い超過データポイントが、**[Datapoints to Alarm]** (アラームへのデータポイント) の値と少なくとも同じように古く、他のすべての最新のデータポイントが超過または欠落している場合にアラームが常に ALARM 状態になるように設計されているためです。この場合、使用可能なデータポイントの総数が M ([**Datapoints to Alarm (アラームを実行するデータポイント)**]) より少ない場合でも、アラームは ALARM 状態になります。

このアラームロジックは、N 個中 M 個のアラームにも適用されます。評価範囲で最も古い違反データポイントが [**アラームを実行するデータポイント**] の値と少なくとも同じくらい古く、最近のすべてのデータポイントが違反または欠落している場合、M ([**アラームを実行するデータポイント**]) の値に関係なくアラームは ALARM 状態になります。

## CloudWatch Metrics Insights アラームの欠落データ
<a name="mi-missing-data-treatment"></a>

 ** 単一の時系列に集計される Metrics Insights クエリに基づくアラーム ** 

 欠落データシナリオとそれらのアラーム評価への影響は、設定された欠落データ処理に関する標準メトリクスアラームと同じです。「[CloudWatch アラームの欠落データの処理の設定](#alarms-and-missing-data)」を参照してください。

 ** 複数の時系列を生成する Metrics Insights クエリに基づくアラーム ** 

Metrics Insights アラームの欠落データシナリオは、次の場合に発生します。
+  1 つの時系列内の個々のデータポイントは存在しません。
+  複数の時系列を評価する際には 1 つ以上の時系列が消えます。
+  クエリによって時系列は取得されません。

 欠落データシナリオは、次の方法でアラーム評価に影響します。
+  時系列の評価では、欠落データの処理が時系列内の個々のデータポイントに適用されます。たとえば、時系列に対して 3 つのデータポイントがクエリされたが、1 つのデータポイントしか受信されなかった場合、2 つのデータポイントは設定された欠落データ設定に従います。
+  クエリによって時系列が取得されなくなった場合、欠落しているデータ処理の処理に関係なく、時系列は `OK` に移行します。コントリビューターレベルでの `OK` 移行に関連付けられたアラームアクションが実行され、`StateReason` は、前述のコントリビューターが見つからなかった場合に「このコントリビューターにデータが返されませんでした」というメッセージが表示されるように指定します。アラームの状態は、クエリによって取得された他のコントリビューターの状態によって異なります。
+  アラームレベルでは、クエリが空の結果 (時系列がまったくない) を返すと、設定されている欠落データ処理に関係なく、アラームは `INSUFFICIENT_DATA` に移行します。