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

# 使用自訂指標的進階預測擴展政策
<a name="predictive-scaling-customized-metric-specification"></a>

在預測擴展政策中，您可以使用預先定義或自訂的指標。當預先定義指標 (CPU、網路輸入/輸出和 Application Load Balancer 請求計數) 未充分描述您的應用程式負載時，自訂指標會非常實用。

使用自訂指標建立預測擴展政策時，您可以指定 提供的其他 CloudWatch 指標 AWS，也可以指定您自己定義和發佈的指標。您也可以使用指標數學來彙總現有指標，並將其轉換為 AWS 不會自動追蹤的新時間序列。當您合併資料中的值時 (例如，透過計算新的總和或平均值)，它稱為*執行彙總*。產生的資料稱為*彙總*。

下一節包含如何建構政策的 JSON 結構的最佳實務和範例。

**Topics**
+ [最佳實務](#custom-metrics-best-practices)
+ [先決條件](#custom-metrics-prerequisites)
+ [建構自訂指標的 JSON](construct-json-custom-metrics.md)
+ [預測擴展政策中自訂指標的考量事項](custom-metrics-troubleshooting.md)
+ [限制](#custom-metrics-limitations)

## 最佳實務
<a name="custom-metrics-best-practices"></a>

以下最佳實務可協助您更有效地使用自訂指標：
+ 對於負載規範，最實用的指標是以 Auto Scaling 群組作為整體 (而不考慮該群組的容量) 來表示負載的指標。
+ 對於擴展指標規範，要擴展的最實用指標是每個執行個體指標的平均輸送量或使用率。
+ 擴展指標必須與容量成反比。也就是說，如果 Auto Scaling 群組中的執行個體數量增加，則擴展指標應減少大致相同的比例。為確保預測擴展按預期進行，負載指標和擴展指標還必須彼此密切關聯。
+ 目標使用率必須與擴展指標的類型相符。對於使用 CPU 使用率的政策組態，這是一個目標百分比。對於使用輸送量 (如請求或訊息數量) 的政策組態，這是在任何一分鐘間隔內每個執行個體的請求或訊息的目標數量。
+ 如果不遵循這些建議，則時間序列的預測未來值可能不正確。要驗證資料是否正確，您可以在 Amazon EC2 Auto Scaling 主控台中檢視預測值。或者，在建立預測擴展政策後，檢查 [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_GetPredictiveScalingForecast.html) API 呼叫傳回的 `LoadForecast` 和 `CapacityForecast` 物件。
+ 強烈建議您在 forecast only (僅預測) 模式中設定預測擴展，以便在預測擴展主動擴展容量之前評估預測。

## 先決條件
<a name="custom-metrics-prerequisites"></a>

若要在預測擴展政策中新增自訂指標，您必須擁有 `cloudwatch:GetMetricData` 許可。

若要指定自己的指標，而不是 AWS 提供的指標，您必須先將指標發佈至 CloudWatch。如需詳細資訊，請參閱《Amazon CloudWatch 使用者指南》**中的[發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。

如果您發佈自己的指標，應確保以至少五分鐘的頻率發佈資料點。Amazon EC2 Auto Scaling 根據需要的時段長度從 CloudWatch 擷取資料點。例如，負載指標規範使用每小時指標來衡量應用程式的負載。CloudWatch 使用您發佈的指標資料，透過將時間戳記落於同一小時週期內的所有資料點彙總，為任何一小時週期提供單一資料值。

## 限制
<a name="custom-metrics-limitations"></a>
+ 您可以在一個指標規範中查詢最多 10 個指標的資料點。
+ 在此限制之下，一個表達式計為一個指標。