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

# 使用自訂指標的 Amazon ECS 進階預測性擴展政策
<a name="predictive-scaling-custom-metrics"></a>

您可以在預測性擴展政策中使用預先定義或自訂的指標。當預先定義的指標 (例如 CPU、記憶體等) 不足以充分描述應用程式負載時，自訂指標會非常有用。

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

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

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

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

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

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

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

以下最佳實務可協助您更有效地使用自訂指標：
+ 對於負載指標規格，最實用的指標是以 Auto Scaling 群組作為整體來表示負載的指標。
+ 對於擴展指標規格，最實用的擴展指標是每項任務指標的平均輸送量或使用率。
+ 目標使用率必須與擴展指標的類型相符。例如，對於使用 CPU 使用率的政策組態，這是一個目標百分比。
+ 如果不遵循這些建議，則時間序列的預測未來值可能不正確。要驗證資料是否正確，您可以在 主控台中檢視預測值。或者，在建立預測性擴展政策後，檢查 [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html) API 呼叫傳回的 `LoadForecast` 物件。
+ 強烈建議在僅預測模式下設定預測性擴展，以便在預測性擴展開始主動擴展之前評估預測。

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

## 對使用自訂指標的預測性擴展政策進行疑難排解
<a name="predictive-scaling-custom-metrics-troubleshooting"></a>

如果使用自訂指標時出現問題，建議您執行以下操作：
+ 如果您在使用搜尋表達式時在藍/綠部署中遇到問題，請確定所建立的搜尋表達式是在查找部分相符，而不是完全相符。此外，還應檢查查詢是否僅尋找在特定應用程式中執行的 Auto Scaling 群組。如需搜尋表達式語法的詳細資訊，請參閱《Amazon CloudWatch 使用者指南》**中的 [CloudWatch 搜尋表達式語法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html)。
+ [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) 命令會在您建立擴展政策時驗證表達式。但是，此命令可能無法識別偵測到之錯誤的確切原因。若要修正這些問題，請對您收到之 [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) 命令請求回應中的錯誤進行疑難排解。您也可以從 CloudWatch 主控台對表達式進行疑難排解。
+ 如果 `MetricDataQueries` 自己指定了 SEARCH() 函數 (在無需 SUM() 等數學函數的狀況下)，則您必須為 `ReturnData` 指定 `false`。這是因為搜尋表達式可能會傳回多個時間序列，並且基於表達式的指標規範只能傳回一個時間序列。
+ 搜尋表達式中涉及的所有指標均應具有相同的解析度。

## 使用指標數學組合指標的預測擴展政策範例 (AWS CLI)
<a name="custom-metrics-ex2"></a>

有時，您可能需要首先以某種方式處理其資料，而不是直接指定指標。例如，您可能有一個從 Amazon SQS 佇列中提取工作的應用程式，並且您可能想要使用佇列中的項目數量作為預測擴展的條件。佇列中的訊息數量並不僅僅定義所需的執行個體數量。因此，需要更多的工作來建立可用於計算每個執行個體待處理項目的指標。

以下是此案例的預測擴展政策範例。它指定了基於 Amazon SQS `ApproximateNumberOfMessagesVisible` 指標的擴展和負載指標，即可從佇列中擷取的訊息數量。它還使用 Amazon EC2 Auto Scaling `GroupInServiceInstances` 指標和數學表達式來計算每個執行個體的待處理項目，以擴展指標。

```
aws application-autoscaling put-scaling-policy --policy-name {{my-sqs-custom-metrics-policy}} \
  --policy-type PredictiveScaling \
  --predictive-scaling-configuration {{file://config.json}}
  --service-namespace ecs \
  --resource-id service/MyCluster/test \
  "MetricSpecifications": [
    {
      "TargetValue": {{100}},
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Label": "Get the queue size (the number of messages waiting to be processed)",
            "Id": "{{queue_size}}",
            "MetricStat": {
              "Metric": {
                "MetricName": "{{ApproximateNumberOfMessagesVisible}}",
                "Namespace": "{{AWS/SQS}}",
                "Dimensions": [
                  {
                    "Name": "{{QueueName}}",
                    "Value": "{{my-queue}}"
                  }
                ]
              },
              "Stat": "{{Sum}}"
            },
            "ReturnData": false
          },
          {
            "Label": "Get the group size (the number of running instances)",
            "Id": "{{running_capacity}}",
            "MetricStat": {
              "Metric": {
                "MetricName": "{{GroupInServiceInstances}}",
                "Namespace": "{{AWS/AutoScaling}}",
                "Dimensions": [
                  {
                    "Name": "{{AutoScalingGroupName}}",
                    "Value": "{{my-asg}}"
                  }
                ]
              },
              "Stat": "{{Sum}}"
            },
            "ReturnData": false
          },
          {
            "Label": "Calculate the backlog per instance",
            "Id": "{{scaling_metric}}",
            "Expression": "{{queue_size / running_capacity}}",
            "ReturnData": true
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "{{load_metric}}",
            "MetricStat": {
              "Metric": {
                "MetricName": "{{ApproximateNumberOfMessagesVisible}}",
                "Namespace": "{{AWS/SQS}}",
                "Dimensions": [
                  {
                    "Name": "{{QueueName}}",
                    "Value": "{{my-queue}}"
                  }
                ],
              },
              "Stat": "{{Sum}}"
            },
            "ReturnData": true
          }
        ]
      }
    }
  ]
}
```

該範例會傳回政策的 ARN。

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy",
  "Alarms": []
}
```