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

# 限制
<a name="alarm-limits"></a>

## 一般 CloudWatch 配額
<a name="general-cloudwatch-quotas"></a>

如需適用於警示的一般 CloudWatch 服務配額資訊，請參閱 [CloudWatch 服務配額](cloudwatch_limits.md)。

## 根據指標數學表達式套用至警示的限制
<a name="metric-math-alarm-limits"></a>

根據指標數學表達式的警示最多可參考 10 個指標。這是無法提高的硬性限制。如果您需要在單一警示中監控超過 10 個指標，請考慮下列其中一種方法：
+ 如果指標位於相同的命名空間中，請在警示中使用 Metrics Insights 查詢，而不是指標數學表達式。Metrics Insights 可以透過單一查詢彙總許多指標。
+ 使用 Lambda 函數將指標預先彙總為自訂指標，然後在警示表達式中參考彙總指標。
+ 將您的邏輯分割為多個警示，並使用複合警示結合它們。

## 根據 Metrics Insights 查詢套用至警示的限制
<a name="metrics-insights-alarm-limits"></a>

使用 CloudWatch Metrics Insights 警示時，請注意以下功能限制：
+ 每個區域每個帳戶使用 Metrics Insights 查詢的預設 200 個警示
+ 僅能使用最近 3 小時的資料評估警示條件。不過，您可以在警示的詳細資訊頁面圖表上視覺化呈現最多兩週的資料
+ 評估多個時間序列的警示會將 ALARM 中的參與者數量限制為 100
  + 假設查詢會擷取 150 個時間序列：
    +  如果 ALARM 中的貢獻者少於 100 個 （例如 95)，則 `StateReason`將是「150 個時間序列中的 95 個評估為 ALARM」 
    +  如果 ALARM 中有超過 100 個參與者 （例如 105)，則 `StateReason`將是「評估為 ALARM 的時間序列超過 100 個」 
  + 此外，如果屬性量太大，ALARM 中的參與者數量可以限制為小於 100。
+ Metrics Insights 對分析或傳回的時間序列數目設有上限
+ 在警示評估期間， `EvaluationState`將`PARTIAL_DATA`針對下列限制設為 ：
  +  如果 Metrics Insights 查詢傳回超過 500 個時間序列。
  +  如果 Metrics Insights 查詢符合超過 10，000 個指標。

如需 CloudWatch 服務配額和限制的詳細資訊，請參閱 [CloudWatch Metrics Insights 服務配額](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-limits.html)。

## 根據 PromQL 查詢套用至警示的限制
<a name="promql-limits"></a>

使用 CloudWatch PromQL 警示時，請注意下列功能限制：
+ 評估多個時間序列的警示會將 ALARM 中的參與者數量限制為 100
  +  如果 ALARM 中的貢獻者少於 100 個 （例如 95)，則 `StateReason`將是「評估為 ALARM 的 95 個時間序列」 
  +  如果 ALARM 中有超過 100 個參與者 （例如 105)，則 `StateReason`將是「評估為 ALARM 的時間序列超過 100 個」 
  + 此外，如果屬性量太大，ALARM 中的參與者數量可以限制為小於 100。
+ PromQL 查詢會限制分析或傳回的時間序列數目上限
+ 在警示評估期間，`PARTIAL_DATA`如果 PromQL 查詢傳回超過 500 個時間序列，`EvaluationState`則會將 設定為 。

## 根據連線資料來源套用至警示的限制
<a name="MultiSource_Alarm_Details"></a>
+ CloudWatch 評估警示時，即使警示的時間長度超過一分鐘，它也會每分鐘執行一次。若要讓警示運作，Lambda 函數必須能夠傳回從任何一分鐘開始的時間戳記清單，而不僅是週期長度的倍數。這些時間戳記必須相隔一個週期長度。

  因此，如果 Lambda 查詢的資料來源只能傳回週期長度倍數的時間戳記，則函數應「重新取樣」擷取的資料，以符合 `GetMetricData` 請求所預期的時間戳記。

  例如，使用每次偏移一分鐘的五分鐘時段，每分鐘評估一次週期為五分鐘的警示。在此案例中：
  + 對於 12:15:00 進行的警示評估，CloudWatch 預期資料點的時間戳記為 `12:00:00`、`12:05:00` 和 `12:10:00`。
  + 然後，對於 12:16:00 進行的警示評估，CloudWatch 預期資料點的時間戳記為 `12:01:00`、`12:06:00` 和 `12:11:00`。
+ CloudWatch 評估警示時，Lambda 函數傳回的與預期時間戳記不符的資料點都會被丟棄，並使用剩餘的預期資料點評估警示。例如，在 `12:15:00` 評估警示時，它預期資料具有 `12:00:00`、`12:05:00` 和 `12:10:00` 時間戳記。如果收到時間戳記為 `12:00:00`、`12:05:00`、`12:06:00` 和 `12:10:00` 的資料，則會丟棄來自 `12:06:00` 的資料，CloudWatch 會使用其他時間戳記評估警示。

  然後，對於在 `12:16:00` 進行的下一次評估，它預期資料具有 `12:01:00`、`12:06:00` 和 `12:11:00` 時間戳記。如果它只有時間戳記為 `12:00:00`、`12:05:00` 和 `12:10:00` 的資料，則所有這些資料點都會在 12:16:00 被忽略，並且警示會根據您指定該警示來處理遺失資料的方式轉換為相應狀態。如需詳細資訊，請參閱[警示評估](alarm-evaluation.md)。
+ 建議您建立這些警示，以便在它們轉換為 `INSUFFICIENT_DATA` 狀態時採取動作，因為多個 Lambda 函數失敗使用案例都會將警示轉換為 `INSUFFICIENT_DATA`，無論您設定警示以何種方式處理遺失的資料。
+ 如果 Lambda 函式傳回錯誤：
  + 如果呼叫 Lambda 函數時發生許可問題，警示會開始遺失資料轉換，其依據為您指定該警示在建立時處理遺失資料的方式。
  + 任何來自 Lambda 函數的其他錯誤都會導致警示轉換為 `INSUFFICIENT_DATA`。
+ 如果 Lambda 函數請求的指標有一些延遲，從而導致最後一個資料點永遠遺失，您應採取因應措施。可以建立「N 中取 M」警示，或增加警示的評估時間。如需「N 中取 M」警示的詳細資訊，請參閱 [警示評估](alarm-evaluation.md)。