本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 設定 CloudWatch 警示如何處理遺失資料
<a name="alarms-and-missing-data"></a>

有時候，並非每個指標的預期資料點都會報告給 CloudWatch。例如，發生遺失連線情況、伺服器停機或根據設計指標只會間歇性報告資料時。

CloudWatch 可讓您指定評估警示時如何處理遺失的資料點。這可協助您設定警示，從而在適合受監控的資料類型時進入 `ALARM` 狀態。當遺失資料未指出問題時，您可以避免誤報。

與每個警示總會是三種狀態中的其中一種相似，每個向 CloudWatch 報告的特定資料點都會是三種類別中的其中一種類別：
+ 未違反 (在閾值中)
+ 違反 (超出閾值)
+ 缺少

針對每種警示，您可以指定 CloudWatch 將遺失的資料點視為以下任何一種項目：
+ `notBreaching` – 將遺失的資料點視為「良好」且在閾值內
+ `breaching` – 將遺失的資料點視為「不良」且超出閾值
+ `ignore` – 維持目前的警示狀態
+ `missing` – 如果所有資料點在警示評估範圍內遺失，警示會轉換為 INPOLATENT\$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 會擷取 5 個最新的資料點，這是為了避免遺失最近 3 個資料點當中的一部分。5 是警示的評估範圍。

第 1 欄顯示了 5 個最新的資料點，因為評估範圍為 5。這些資料點會與右側的資料點一起顯示。0 是未違反的資料點、X 是違反的資料點，以及 - 是遺失的資料點。

欄 2 顯示遺失多少必要的 3 個資料點。即使最近 5 個資料點已完成評估，只需要 3 (**Evaluation Periods (評估期間)** 的設定) 個便可以評估警示狀態。欄 2 中資料點的數量，是必須使用如何處理遺失資料設定「填入」的資料點數量。

在 3-6 欄中，欄標題是如何處理遺失資料的可能值。這些欄位中的列會顯示針對處理遺失資料的每種可能方式設定的警示狀態。


| 資料點 | 必須填充的資料點數 | 缺少 | 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`  | 

在前一個表格的第二列中，該警示會保持在 `OK`，即使將遺失資料都視為違規也一樣，因為一個現有的資料點沒有違規，並且它是隨著兩個視為違規的遺失資料點評估的。下一次評估此警示時，若仍然遺失資料，它便會進入 `ALARM`，因為未違反的資料點將不再於評估範圍內。

第三列 (最近五個資料點全部遺失) 說明了如何處理遺失資料的各種設定會如何影響警示狀態。如果遺失的資料點被視為違規，則警示會進入 ALARM 狀態，而如果它們被視為未違規，則警報會進入 OK 狀態。如果忽略遺失的資料點，警示會保留遺失資料點之前的目前狀態。如果遺失的資料點被視為遺失，則警示沒有足夠的最新實際資料來進行評估，並且會進入 INSUFFICIENT\$1DATA。

在第四列，警示進入 `ALARM` 狀態，因為當警示的最近三個資料點違規時，警示的 **Evaluation Periods** (評估期間) 和 **Datapoints to Alarm** (資料點到警示) 均設為 3。於此狀況下，遺失資料點會予以忽略，且無須如何評估遺失資料的設定，因為有 3 個實際資料點要評估。

第 5 列代表警示評估的特殊情況，稱為*過早警示狀態*。如需詳細資訊，請參閱[避免過早轉換到警示狀態](#CloudWatch-alarms-avoiding-premature-transition)。

在下一個表格中，**Period (期間)** 會再次設為 5 分鐘，**Datapoints to Alarm (要警示的資料點)** 為 2，而 **Evaluation Periods (評估期間)** 則為 3。這是一個 2 來自 3、M 來自 N 警示。

評估範圍為 5。這是已擷取且可以在遺失某些資料點時使用的最近資料點數量上限。


| 資料點 | \$1 遺失資料點 | 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 列中，警示始終處於 ARMARM 狀態，因為 3 個最新的資料點中有 2 個違規。在第 2 列中，不需要評估範圍中的兩個最舊的資料點，因為 3 個最新的資料點都不會遺失，因此會忽略這兩個較舊的資料點。

在第 3 列和第 4 列中，只有當遺失資料被視為違規時，警示才會進入 ALARM 狀態，在這種情況下，兩個最近的遺失資料點都會被視為違規。在第 4 列，這兩個被視為違規的遺失資料點提供兩個必要違規的資料點以觸發 ALARM 狀態。

第 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`，其中有四個遺失的資料點，然後有一個作為最新資料點的違規資料點。由於下一個資料點可能是未違反，因此當資料為 `- - - - X` 或 `- - - X -` 且 **Datapoints to Alarm** (要警示的資料點) 為 3 時，警示不會立即進入 ARMARM 狀態。透過這種方式，當下一個資料點沒有違反時，可避免誤判，並導致資料成為 `- - - X O` 或 `- - X - O`。

但是，如果最新幾個資料點是 `- - X - -`，即使遺失的資料點被視為遺失，警示也會進入 ARMARM 狀態。這是因為警示旨在於 **Evaluation Periods** (評估期間) 最舊的可用違反資料點數目至少與 **Datapoints to Alarm** (要警示的資料點) 的值一樣陳舊並且所有其他最新的資料點違規或遺失時，始終能進入 ALARM 狀態。在這種情況下，即使可用的資料點總數小於 M (**Datapoints to Alarm** (要警示的資料點))，則警示會進入 ALARM 狀態。

此警示邏輯也適用於 N 個中的 M 個警報。如果評估範圍期間最舊的違規資料點至少與 **Datapoints to Alarm** (要警示的資料點) 同樣陳舊，並且所有最新的資料點均已違規或遺失，則無論 M (**Datapoints to Alarm** (要警示的資料點)) 的值為何，警示會進入 ALARM 狀態。

## CloudWatch Metrics Insights 警示中的遺失資料
<a name="mi-missing-data-treatment"></a>

 ** 根據彙總至單一時間序列的 Metrics Insights 查詢的警示 ** 

 遺失資料案例及其對警示評估的影響，與設定遺失資料處理的標準指標警示相同。請參閱 [設定 CloudWatch 警示如何處理遺失資料](#alarms-and-missing-data)。

 ** 根據產生多個時間序列的 Metrics Insights 查詢的警示 ** 

在下列情況下，會發生 Metrics Insights 警示的遺失資料案例：
+  時間序列內的個別資料點不存在。
+  一或多個時間序列在評估多個時間序列時消失。
+  查詢不會擷取任何時間序列。

 遺失的資料案例會以下列方式影響警示評估：
+  為了評估時間序列，處理遺失的資料處理會套用至時間序列內的個別資料點。例如，如果針對時間序列查詢了 3 個資料點，但只收到 1 個資料點，則 2 個資料點會遵循設定的遺失資料組態。
+  如果查詢不再擷取時間序列，無論處理遺漏的資料處理方式`OK`為何，都會轉換為 。在貢獻者層級執行與`OK`轉換相關聯的警示動作，並`StateReason`指定找不到上述貢獻者並顯示訊息「未為此貢獻者傳回資料」。警示的狀態取決於查詢所擷取的其他參與者的狀態。
+  在警示層級，如果查詢傳回空白結果 （完全沒有時間序列），`INSUFFICIENT_DATA`則無論設定的資料處理是否遺失，警示都會轉換為 。