本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Amazon EC2 Auto Scaling 的目標追蹤擴展政策 目標追蹤擴展政策會根據目標指標值自動擴展 Auto Scaling 群組的容量。它會自動適應個別應用程式的獨特使用模式。這可讓您的應用程式維持 EC2 執行個體的最佳效能和高使用率，以提高成本效益，而無需手動介入。 如果使用目標追蹤，您必須選取指標和目標值，以代表應用程式理想的平均使用率或輸送量。Amazon EC2 Auto Scaling 會建立和管理 CloudWatch 警示，在指標偏離目標時調用擴展事件。例如，這類似於調溫器如何維持目標溫度。 例如，假設您目前有一個應用程式在兩個執行個體上執行，而且您希望當應用程式的負載變更時，Auto Scaling 群組的 CPU 使用率保持在 50% 左右。這樣可以給予您額外的容量處理流量尖峰，而不會維持過多的閒置資源數。 您可以透過建立以 50% 的平均 CPU 利用率為目標的目標追蹤擴展政策來滿足此需求。然後，當 CPU 超過 50% 來處理增加的負載時，Auto Scaling 群組將橫向擴展或增加容量。當 CPU 低於 50% 時，它會縮減或減少容量，以在低使用率期間最佳化成本。 **Topics** + [多個目標追蹤擴展政策](#target-tracking-multiple-policies) + [選擇 Metrics (指標)](#target-tracking-choose-metrics) + [定義目標值](#target-tracking-define-target-value) + [定義執行個體暖機時間](#as-target-tracking-scaling-warmup) + [考量事項](#target-tracking-considerations) + [建立目標追蹤擴展政策](policy_creating.md) + [使用高解析度指標建立目標追蹤政策，以加快回應速度](policy-creating-high-resolution-metrics.md) + [使用指標數學建立目標追蹤擴展政策](ec2-auto-scaling-target-tracking-metric-math.md) ## 多個目標追蹤擴展政策 為協助最佳化擴展效能，您可使用多個目標追蹤擴展政策，但前提是各政策使用不同的指標。例如，使用率和輸送量可能會相互影響。每當這些指標之一發生變化時，通常意味著其他指標也會受到影響。因此，使用多個指標可提供有關 Auto Scaling 群組所承受負載的其他資訊。這有助於 Amazon EC2 Auto Scaling 在判斷要新增至群組的容量時，做出更明智的決策。 Amazon EC2 Auto Scaling 的目的是一律優先考慮可用性。如果任何目標追蹤政策已準備好向外擴展，則會向外擴展 Auto Scaling 群組。只有在所有目標追蹤政策 （已啟用縮減部分） 都準備好縮減時，才會縮減。 ## 選擇 Metrics (指標) 您可以使用預先定義的指標或自訂指標建立目標追蹤擴展政策。預先定義的指標可讓您更輕鬆地存取最常用於擴展的指標。自訂指標可讓您擴展其他可用的 CloudWatch 指標，包括[以幾秒鐘的間隔更精細發佈的高解析度指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Resolution_definition)。您可以發佈自己的高解析度指標或其他 服務發佈的 AWS 指標。 如需使用高解析度指標建立目標追蹤政策的詳細資訊，請參閱 [使用高解析度指標建立目標追蹤政策，以加快回應速度](policy-creating-high-resolution-metrics.md)。 目標追蹤支援下列預先定義的指標： + `ASGAverageCPUUtilization`：Auto Scaling 群組的 CPU 平均使用率。 + `ASGAverageNetworkIn`：Auto Scaling 群組在所有網路介面上收到的平均位元組數量。 + `ASGAverageNetworkOut`：Auto Scaling 群組在所有網路介面上傳送出去的平均位元組數量。 + `ALBRequestCountPerTarget` — Auto Scaling 群組每個目標的平均 Application Load Balancer 請求計數。 **重要** 有關每個目標的 CPU 使用率、網路 I/O 和 Application Load Balancer 請求計數指標的其他寶貴資訊，請參閱《*Amazon EC2 使用者指南*》中的[列出執行個體主題的可用 CloudWatch 指標](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)，以及《Application [ Application Load Balancer 使用者指南》中的 Application Load Balancer 主題的 CloudWatch 指標](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)。 ** 您可以在 CloudWatch 中透過指定自訂指標，選擇其他可用的 CloudWatch 指標或自己的指標。如需使用 為目標追蹤擴展政策指定自訂指標規格的範例 AWS CLI，請參閱 [的範例擴展政策 AWS CLI](examples-scaling-policies.md)。 選擇指標時請謹記以下事項： + 我們建議您只使用一分鐘或更低間隔可用的指標，以協助您更快地擴展以回應使用率變更。以較低間隔發佈的指標可讓目標追蹤政策更快地偵測和回應 Auto Scaling 群組使用率的變化。 + 如果您選擇 Amazon EC2 發佈的預先定義指標，例如 CPU 使用率，建議您啟用詳細監控。根據預設，所有 Amazon EC2 指標會以五分鐘的間隔發佈，但可透過啟用詳細監控，將其設定為較低的一分鐘間隔。如需如何啟用詳細監控的資訊，請參閱 [設定 Auto Scaling 執行個體的監控](enable-as-instance-metrics.md)。 + 並非所有的自訂指標都適用於目標追蹤。指標必須是有效的使用率指標，而且能夠表示執行個體的忙碌程度。指標值必須與 Auto Scaling 群組中的執行個體數成比例增加或減少。如此，指標資料便可依比例依執行個體數量擴增或縮減。例如，如果 Auto Scaling 群組的負載分佈於各執行個體之間，則 Auto Scaling 群組的 CPU 使用率是有效的 (也就是具有指標維度 `AutoScalingGroupName` 的 Amazon EC2 指標 `CPUUtilization`)。 + 以下指標不適用於目標追蹤： + 面對 Auto Scaling 群組的負載平衡器所收到的請求數量 (也就是 Elastic Load Balancing 指標 `RequestCount`)。負載平衡器收到的請求數量不會根據 Auto Scaling 群組的使用率而改變。 + 負載平衡器請求延遲 (也就是 Elastic Load Balancing 指標 `Latency`)。請求延遲會隨使用率提高而增加，但不一定會依比例變動。 + CloudWatch Amazon SQS 佇列指標 `ApproximateNumberOfMessagesVisible`。佇列中的訊息數量可能不會隨處理佇列訊息之 Auto Scaling 群組的大小成比例地變更。然而，測量 Auto Scaling 群組中每個 EC2 執行個體佇列中訊息數量的自訂指標是可行的。如需詳細資訊，請參閱[以 Amazon SQS 為基礎的擴展政策](as-using-sqs-queue.md)。 + 若要使用 `ALBRequestCountPerTarget` 指標，您必須指定 `ResourceLabel` 參數來識別與指標相關聯的負載平衡器目標群組。如需使用 指定目標追蹤擴展政策`ResourceLabel`參數的範例 AWS CLI，請參閱 [的範例擴展政策 AWS CLI](examples-scaling-policies.md)。 + 當指標向 CloudWatch 真的發出 0 值時 (例如 `ALBRequestCountPerTarget`)，如果應用程式持續一段時間沒有流量，Auto Scaling 群組可能縮減到 0。若要讓 Auto Scaling 群組在沒有請求傳送到它時縮減為 0，該群組的容量下限必須設定為 0。 + 您可以使用指標數學來合併現有的指標，而不是發布新的指標來用於您的擴展政策。如需詳細資訊，請參閱[使用指標數學建立目標追蹤擴展政策](ec2-auto-scaling-target-tracking-metric-math.md)。 ## 定義目標值 建立目標追蹤擴展政策時，您必須指定目標值。目標值代表 Auto Scaling 群組的最佳平均使用率或輸送量。若要以符合成本效益的方式使用資源，請盡可能高地設定目標值，並為非預期的流量增加提供合理的緩衝區。當您的應用程式進行最佳橫向擴展以達到正常流量時，實際指標值應等於或略低於目標值。 擴展政策以輸送量為基礎時 (例如 Application Load Balancer 每個目標的要求計數、網路 I/O 或其他計數指標)，目標值代表一分鐘期間單一執行個體的最佳平均輸送量。 ## 定義執行個體暖機時間 您可以選擇性指定新啟動的執行個體暖機所需的秒數。在指定的暖機時間結束之前，執行個體不會計入 Auto Scaling 群組的彙總 EC2 執行個體指標。 當執行個體處於暖機期間時，只有在未暖機的執行個體指標值大於政策的目標使用率時，擴展政策才會向外擴展。 如果群組再次水平擴展，則仍在暖機的執行個體將計為下次水平擴展活動所需的容量一部分。這種做法的目的是連續的向外擴展 (但並非過度)。 當向外擴展活動正在進行時，所有由擴展政策啟動的向內擴展活動都會遭到封鎖，直到執行個體完成暖機。當執行個體完成暖機時，如果發生擴展事件，則在計算新的所需容量時，目前正在終止的任何執行個體都會計入群組的目前容量。所以，我們不會從 Auto Scaling 群組移除超過必要數量的執行個體。 **預設值** 如果未設定任何值，擴展政策將使用預設值，這是為群組定義之[預設執行個體暖機](ec2-auto-scaling-default-instance-warmup.md)期的值。如果預設執行個體暖機期為 null，則會回到[預設冷卻時間](ec2-auto-scaling-scaling-cooldowns.md#set-default-cooldown)的值。我們建議您使用預設執行個體暖機期，以便在暖機期變更時更輕鬆地更新所有擴展政策。 ## 考量事項 使用目標追蹤擴展政策時，下列考量適用： + 請勿建立、編輯或刪除用於目標追蹤擴展政策的 CloudWatch 警示。Amazon EC2 Auto Scaling 會建立和管理與您的目標追蹤擴展政策相關聯的 CloudWatch 警示，並視需要編輯、取代或刪除它們，以自訂應用程式的擴展體驗及其不斷變化的使用率模式。 + 目標追蹤擴展政策會在流量減少時逐漸縮減，在流量水平波動期間排定可用性優先順序。如果您想要更好的控制，步驟擴展政策可能是更好的選項。您可以暫時停用目標追蹤政策的縮減部分。這有助於維持成功部署的執行個體數量下限。 + 如果指標缺少資料點，這會導致 CloudWatch 警示狀態變更為 `INSUFFICIENT_DATA`。發生這種情況時，Amazon EC2 Auto Scaling 無法擴展您的群組，直到找到新的資料點為止。 + 如果指標在設計上是以稀疏的方式來報告，指標數學可能會有所幫助。例如，若要使用最新的值，請使用指標為 `m1` 的 `FILL(m1,REPEAT)` 函數。 + 您可能會看到目標值和實際指標資料點之間有些差距。原因我們會在決定新增或移除多少執行個體時，透過向上或向下四捨五入保守地行動。如此一來，防止我們新增不足數量的執行個體，或移除太多的執行個體。然而，對於較小的 Auto Scaling 群組使用較少的執行個體，該群組的使用率可能與目標值相差甚遠。 例如，假設您為 CPU 使用率設定了 50% 的目標值，然後 Auto Scaling 群組就會超過目標。我們可能會判斷新增 1.5 執行個體使 CPU 使用率降低接近 50%。由於不可能新增 1.5 執行個體，我們四捨五入而新增兩個執行個體。這可能會降低 CPU 使用率低於 50%，但可確保有足夠的資源來支援您的應用程式。同樣地，如果我們判斷移除 0.5 個執行個體會將您的 CPU 使用率提高到 50% 以上，我們將選擇不縮減，直到指標降低到我們認為縮減不會造成振盪的程度為止。 對於具有較多執行個體的大型 Auto Scaling 群組，使用率會分佈於較多的執行個體，在這種情況下，新增或移除執行個體所導致目標值和實際指標資料點之間的差距會比較小。 + 目標追蹤擴展政策假設在指定的指標超過目標值時，應擴增您的 Auto Scaling 群組。當指定的指標低於目標值時，您無法使用目標追蹤擴展政策來橫向擴展 Auto Scaling 群組。 # 建立目標追蹤擴展政策 若要為您的 Auto Scaling 群組建立目標追蹤擴展政策，請使用下列其中一種方法。 開始之前，請確認您偏好的指標每隔 1 分鐘可用 (相比之下，Amazon EC2 指標的預設間隔為 5 分鐘)。 ------ #### [ Console ] **建立新的 Auto Scaling 群組的目標追蹤擴展政策** 1. 前往網址 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台，然後從導覽窗格中選擇 **Auto Scaling 群組**。 1. 選擇 **Create Auto Scaling group** (建立 Auto Scaling 群組)。 1. 在步驟 1、2 和 3 中，視需要選擇選項，並繼續進行 **Step 4: Configure group size and scaling policies** (步驟 4：設定群組大小和擴展政策)。 1. 在**擴展**下，透過更新**所需容量下限**和**所需容量上限**，指定要在兩者之間擴展的範圍。這兩個設定可讓您的 Auto Scaling 群組進行動態擴展。如需詳細資訊，請參閱[設定 Auto Scaling 群組的擴展限制](asg-capacity-limits.md)。 1. 在**自動擴展**下，選擇**目標追蹤擴展政策**。 1. 若要定義政策，請執行下列的動作： 1. 指定政策的名稱。 1. 為 **Metric type** (指標類型) 選擇指標。 如果選擇了 **Application Load Balancer request count per target** (每個目標的 Application Load Balancer 請求計數)，則在 **Target group** (目標群組) 中選擇目標群組。 1. 指定指標的 **Target value** (目標值)。 1. （選用） 對於**執行個體暖機**期，視需要更新執行個體暖機期值。 1. (選用) 選取 **Disable scale in to create only a scale-out policy** (停用縮減以僅建立擴增政策)。這可讓您建立所需不同類型的單獨縮減政策。 1. 繼續建立 Auto Scaling 群組。您的擴展政策會在建立 Auto Scaling 群組之後建立。 **建立現有 Auto Scaling 群組的目標追蹤擴展政策** 1. 前往網址 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) 開啟 Amazon EC2 主控台，然後從導覽窗格中選擇 **Auto Scaling 群組**。 1. 選取 Auto Scaling 群組旁的核取方塊。 頁面底部會開啟一個分割窗格。 1. 確認已將擴展限制設定妥當。例如，如果群組已達到所需容量上限，則需要指定新的上限，以便進行橫向擴展。如需詳細資訊，請參閱[設定 Auto Scaling 群組的擴展限制](asg-capacity-limits.md)。 1. 在 **Automatic scaling** (自動擴展) 索引標籤的 **Dynamic scaling policies** (動態擴展政策) 中，選擇 **Create dynamic scaling policy** (建立動態擴展政策)。 1. 若要定義政策，請執行下列的動作： 1. 對於**政策類型**，請保持**目標追蹤擴展**的預設值。 1. 指定政策的名稱。 1. 為 **Metric type** (指標類型) 選擇指標。您只能選擇一種指標類型。若要使用多個指標，請建立多個政策。 如果選擇了 **Application Load Balancer request count per target** (每個目標的 Application Load Balancer 請求計數)，則在 **Target group** (目標群組) 中選擇目標群組。 1. 指定指標的 **Target value** (目標值)。 1. （選用） 對於**執行個體暖機**期，視需要更新執行個體暖機期值。 1. (選用) 選取 **Disable scale in to create only a scale-out policy** (停用縮減以僅建立擴增政策)。這可讓您建立所需不同類型的單獨縮減政策。 1. 選擇**建立**。 ------ #### [ AWS CLI ] 若要建立目標追蹤擴展政策，您可以使用下列範例來協助您開始使用。將每個*使用者輸入預留位置*替換為自己的資訊。 **注意** 如需更多範例，請參閱[的範例擴展政策 AWS CLI](examples-scaling-policies.md)。 **建立目標追蹤擴展政策 (AWS CLI)** 1. 使用下列`cat`命令，將擴展政策的目標值和預先定義的指標規格存放在主目錄中名為 `config.json`的 JSON 檔案中。以下是將平均 CPU 使用率保持在 50% 的目標追蹤組態範例。 ``` $ cat ~/config.json { "TargetValue": 50.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" } } ``` 如需詳細資訊，請參閱《Amazon EC2 Auto Scaling API 參考》**中的 [PredefinedMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredefinedMetricSpecification.html)。 1. 使用 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 命令與先前步驟中建立的 `config.json` 檔案來建立您的擴展政策。 ``` aws autoscaling put-scaling-policy --policy-name cpu50-target-tracking-scaling-policy \ --auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \ --target-tracking-configuration file://config.json ``` 如果成功，此命令會傳回代表您建立的兩個 CloudWatch 警示的 ARN 和名稱。 ``` { "PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:228f02c2-c665-4bfd-aaac-8b04080bea3c:autoScalingGroupName/my-asg:policyName/cpu50-target-tracking-scaling-policy", "Alarms": [ { "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e", "AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e" }, { "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2", "AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2" } ] } ``` ------ # 使用高解析度指標建立目標追蹤政策，以加快回應速度 目標追蹤支援高解析度 CloudWatch 指標，並以低於一分鐘的間隔發佈秒級資料點。設定目標追蹤政策，透過高解析度 CloudWatch 指標監控具有波動需求模式的應用程式使用率，例如用戶端服務 APIs、即時串流服務、電子商務網站和隨需資料處理。為了在符合容量與需求時達到更高的精確度，目標追蹤會使用這種精細的監控，更快速地偵測和回應不斷變化的 EC2 執行個體需求和使用率。 如需如何以高解析度發佈指標的詳細資訊，請參閱《*Amazon CloudWatch 使用者指南*》中的[發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。若要存取和發佈 EC2 指標，例如高解析度 CPU 使用率，您可能想要使用 [CloudWatch 代理程式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)。 ## AWS 區域 除了 AWS 區域 之外，所有 都可以使用高解析度指標進行目標追蹤 AWS GovCloud (US) Regions。 ## 具有高解析度指標的目標追蹤政策如何運作 您可以透過定義要追蹤的指標和要為指標維護的目標值，來建立目標追蹤政策。若要擴展高解析度指標，請指定指標的名稱，並將目標追蹤觀察此指標的指標期間設定為低於 60 秒的值。目前支援的最低間隔為 10 秒。您可以比此更低的間隔發佈指標。 **注意** 不支援大於 60 的指標期間。 您可以在單一 CloudWatch 指標上設定目標追蹤，或查詢多個 CloudWatch 指標，並使用數學表達式根據這些指標建立新的單一時間序列。這兩個選項都可讓您定義指標期間。 ## 範例 **範例 1** 下列範例會根據高解析度 CloudWatch 指標建立目標追蹤政策。指標會以 10 秒解析度發佈。透過定義期間，您可以啟用目標追蹤，以 10 秒精細程度監控此指標。將每個*使用者輸入預留位置*替換為自己的資訊。 ``` $ cat ~/config.json { "TargetValue": 100.0, "CustomizedMetricSpecification": { "MetricName": "MyHighResolutionMetric", "Namespace": "MyNamespace", "Dimensions": [ { "Name": "MyOptionalDimensionName", "Value": "MyOptionalMetricDimensionValue" } ], "Statistic": "Average", "Unit": "None" "Period": "10 } } ``` **範例 2** 您可以使用指標數學表達式，將多個指標合併為單一時間序列以進行擴展。指標數學在將現有指標轉換為平均每個執行個體時特別有用。轉換指標至關重要，因為目標追蹤假設指標與 Auto Scaling 群組的容量成反比。因此，當容量增加時，指標應該會減少近乎相同的比例。 例如，假設您的指標代表應用程式要處理的待處理任務。您可以使用指標數學，將待定任務除以 Auto Scaling 群組的執行容量。Auto Scaling 會以 1 分鐘的精細程度發佈容量指標，因此此指標在一分鐘間隔內不會有任何值。如果您想要使用更高的解析度進行擴展，這可能會導致容量與待定任務指標之間的期間不相符。為了避免此不相符，建議您使用 FILL 表達式，以上一分鐘時間戳記中記錄的容量編號填入缺少的值。 下列範例使用指標數學將待定任務指標除以容量。在這段期間，我們會將這兩個指標設定為 10 秒。由於指標是以 1 分鐘的間隔發佈，因此我們在容量指標上使用 FILL 操作。 使用指標數學來修改多個指標 ``` { "CustomizedMetricSpecification": { "Metrics": [ { "Label": "Pending jobs to be processed", "Id": "m1", "MetricStat": { "Metric": { "MetricName": "MyPendingJobsMetric", "Namespace": "Custom", }, "Stat": "Sum" "Period": 10 }, "ReturnData": false }, { "Label": "Get the running instance capacity (matching the period to that of the m1)", "Id": "m2", "MetricStat": { "Metric": { "MetricName": "GroupInServiceInstances", "Namespace": "AWS/AutoScaling", "Dimensions": [ { "Name": "AutoScalingGroupName", "Value": "my-asg" } ] }, "Stat": "Average" "Period": 10 }, "ReturnData": false }, { "Label": "Calculate the pending job per capacity (note the use of the FILL expression)", "Id": "e1", "Expression": "m1 / FILL(m2,REPEAT)", "ReturnData": true } ] }, "TargetValue": 100 } ``` ## 考量事項 使用目標追蹤和高解析度指標時，請考慮下列事項。 + 為了確保您沒有可能導致不需要的自動擴展結果的遺失資料點，您的 CloudWatch 指標必須以與您指定期間相同的或更高解析度發佈。 + 將目標值定義為您要為 Auto Scaling 群組維護per-instance-per-minute指標值。如果您使用的指標值可以根據指標的期間進行乘以，則設定適當的目標值至關重要。例如，任何以計數為基礎的指標，例如使用 SUM 統計資料的請求計數或待定任務，都會有不同的指標值，取決於所選的期間。您仍應假設您要根據每分鐘平均值設定目標。 + 雖然使用 Amazon EC2 Auto Scaling 無需額外費用，但您必須支付 資源，例如 Amazon EC2 執行個體、CloudWatch 指標和 CloudWatch 警示。上述範例中建立的高解析度警示定價與標準 CloudWatch 警示不同。如需 CloudWatch 定價的詳細資訊，請參閱 [Amazon CloudWatch 定價](https://aws.amazon.com/cloudwatch/pricing/)。 + 目標追蹤需要指標代表 EC2 執行個體的每個執行個體平均使用率。若要達成此目的，您可以使用[指標數學操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)做為目標追蹤政策組態的一部分。將指標除以 Auto Scaling 群組的執行容量。請務必為您用來建立單一時間序列的每個指標定義相同的指標期間。如果這些指標以不同的間隔發佈，請在具有較高間隔的指標上使用 FILL 操作來填入遺失的資料點。 # 使用指標數學建立目標追蹤擴展政策 利用指標數學，可查詢多個 CloudWatch 指標，並使用數學表達式根據這些指標來建立新的時間序列。您可以在 CloudWatch 主控台視覺化產生的時間序列，並將其新增至儀表板。如需有關指標數學的詳細資訊，請參閱《Amazon CloudWatch 使用者指南》中的[使用指標數學](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。 指標數學運算式有下列考量： + 您可以查詢任何可用的 CloudWatch 指標。每個指標都是指標名稱、命名空間以及零個或多個維度的唯一組合。 + 您可以使用任何算術運算子 (\$1-\$1/^)、統計函數 (如 AVG 或 SUM) 或 CloudWatch 支援的其他函數。 + 您可以在數學運算式的公式中同時使用其他數學運算式的指標和結果。 + 在指標規範中使用的任何運算式都必須最終傳回單一的時間序列。 + 您可以透過使用 CloudWatch 主控台或 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API 驗證指標數學表達式是否有效。 ## 範例：每個執行個體的 Amazon SQS 佇列待辦項目 若要計算每個執行個體的 Amazon SQS 佇列待辦項目，請獲取佇列中可擷取的大致訊息數量，然後將該數字除以 Auto Scaling 群組的執行中容量 (即處於 `InService` 狀態的執行個體數量)。如需詳細資訊，請參閱[以 Amazon SQS 為基礎的擴展政策](as-using-sqs-queue.md)。 運算式的邏輯如下所示： `sum of (number of messages in the queue)/(number of InService instances)` 那麼，您的 CloudWatch 指標資訊如下。 | ID | CloudWatch 指標 | 統計數字 | Period | | --- | --- | --- | --- | | m1 | ApproximateNumberOfMessagesVisible | 總和 | 1 分鐘 | | m2 | GroupInServiceInstances | 平均數 | 1 分鐘 | 您的指標數學 ID 和表達式如下。 | ID | 表達式 | | --- | --- | | e1 | (m1)/(m2) | 下圖說明此指標的架構： ![\[Amazon EC2 Auto Scaling 使用佇列架構圖表\]](http://docs.aws.amazon.com/zh_tw/autoscaling/ec2/userguide/images/sqs-as-custom-metric-diagram.png) **使用此指標數學建立目標追蹤擴展政策 (AWS CLI)** 1. 將指標數學運算式作為自訂指標規格的一部分儲存在名為 `config.json` 的 JSON 檔案中。 使用以下範例協助您開始使用。將每個*使用者輸入預留位置*替換為自己的資訊。 ``` { "CustomizedMetricSpecification": { "Metrics": [ { "Label": "Get the queue size (the number of messages waiting to be processed)", "Id": "m1", "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 InService instances)", "Id": "m2", "MetricStat": { "Metric": { "MetricName": "GroupInServiceInstances", "Namespace": "AWS/AutoScaling", "Dimensions": [ { "Name": "AutoScalingGroupName", "Value": "my-asg" } ] }, "Stat": "Average" }, "ReturnData": false }, { "Label": "Calculate the backlog per instance", "Id": "e1", "Expression": "m1 / m2", "ReturnData": true } ] }, "TargetValue": 100 } ``` 如需詳細資訊，請參閱*《Amazon EC2 Auto Scaling API 參考》*中的 [TargetTrackingConfiguration](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TargetTrackingConfiguration.html)。 **注意** 以下是一些其他資源，可協助您尋找 CloudWatch 指標的指標名稱、命名空間、維度和統計資料： 如需 AWS 服務的可用指標相關資訊，請參閱《Amazon CloudWatch 使用者指南》**中的[發佈 CloudWatch 指標的AWS 服務](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)。 要使用 AWS CLI取得 CloudWatch 指標的確切指標名稱、命名空間和維度 (如果適用)，請參閱 [list-metrics](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/list-metrics.html)。 1. 若要建立此政策，執行使用 JSON 檔案作為輸入 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 命令，如以下範例所示。 ``` aws autoscaling put-scaling-policy --policy-name sqs-backlog-target-tracking-scaling-policy \ --auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \ --target-tracking-configuration file://config.json ``` 如果成功，則此命令會傳回政策的 Amazon Resource Name (ARN) 和代表您建立的兩個 CloudWatch 警示的 ARN。 ``` { "PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:228f02c2-c665-4bfd-aaac-8b04080bea3c:autoScalingGroupName/my-asg:policyName/sqs-backlog-target-tracking-scaling-policy", "Alarms": [ { "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e", "AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e" }, { "AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2", "AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2" } ] } ``` **注意** 如果此命令擲回錯誤，請確定您已在 AWS CLI 本機將 更新為最新版本。