本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon EC2 Auto Scaling 的目标跟踪扩缩策略
<a name="as-scaling-target-tracking"></a>

目标跟踪扩缩策略根据目标指标值自动扩缩自动扩缩组的容量。可自动适应各个应用程序的独特使用模式。这使您的应用程序无需人工干预即可保持最佳性能，并保持 EC2 实例高使用率以提高成本效益。

通过目标跟踪，您可以选择一个指标和一个目标值，目标值用来表示应用程序的理想平均利用率或吞吐量水平。Amazon EC2 Auto Scaling 创建并管理在指标偏离目标时调用扩展事件的 CloudWatch 警报。举例来说，这与恒温器保持目标温度的方式类似。

例如，假设您当前有一个在两个实例上运行的 Web 应用程序，并希望在应用程序负载变化时将自动扩缩组的 CPU 利用率保持在 50% 左右。这为您提供额外容量以处理流量高峰，而无需维护过多的空闲资源。

创建一个将目标平均 CPU 利用率设置为 50% 的目标跟踪扩缩策略即可满足此需求。然后，当 CPU 使用率超过 50% 时，自动扩缩组将横向扩展或增加容量，以处理增加的负载。当 CPU 利用率降至 50% 以下时，该组将横向缩减或减少容量，以便在利用率低的时期优化成本。

**Topics**
+ [多个目标跟踪扩缩策略](#target-tracking-multiple-policies)
+ [选择指标](#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)

## 多个目标跟踪扩缩策略
<a name="target-tracking-multiple-policies"></a>

为帮助优化扩缩性能，您可以将多个目标跟踪扩缩策略组合使用，但前提是其中的每个策略都各自使用不同的指标。例如，利用率和吞吐量可能会相互影响。每当其中一个指标发生变化时，通常意味着其他指标也将受到影响。因此，使用多个指标可以提供有关自动扩缩组所承担负载的额外信息。这可以帮助 Amazon EC2 Auto Scaling 在确定要向组中添加多少容量时做出更明智的决策。

Amazon EC2 Auto Scaling 的目的是始终优先考虑可用性。如果任何目标跟踪策略已准备好横向扩展，则它将横向扩展自动扩缩组。仅在所有目标跟踪策略（已启用横向缩减部分）都准备好横向缩减时，才会进行横向缩减。

## 选择指标
<a name="target-tracking-choose-metrics"></a>

您可以使用预定义的指标或自定义指标，创建目标跟踪扩展策略。预定义指标可让您更轻松地访问最常用的扩缩指标。自定义指标允许您根据其他可用 CloudWatch 指标进行扩展，包括以更精细的间隔发布[的高分辨率指标](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Resolution_definition)，这些指标在几秒钟左右的时间间隔内发布。您可以发布自有的高精度指标，也可以发布其他 Amazon 服务发布的指标。

有关使用高精度指标创建目标跟踪策略的更多信息，请参阅[使用高精度指标创建目标跟踪策略以加快响应速度](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 请求数等[ CloudWatch 指标的其他有价值的信息，可分别在 *Amazon EC2 用户指南*中的列出您的实例的可用CloudWatch ](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)[指标主题和应用程序负载均衡器](https://docs.amazonaws.cn/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)用户指南中的应用程序负载均衡*器指标主题中找到。

您可以 CloudWatch 通过指定自定义 CloudWatch 指标来选择其他可用指标或您自己的指标。有关使用为目标跟踪扩展策略指定自定义指标规范的示例 Amazon CLI，请参阅[的扩展策略示例 Amazon CLI](examples-scaling-policies.md)。

选择指标时请记住原则：
+ 我们建议您仅使用每隔一分钟或更短时间可用的指标，以帮助您更快地扩展以响应利用率变化。借助以较小间隔发布的指标，目标跟踪策略可检测自动扩缩组利用率的变化并更快地进行响应。
+ 如果选择 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 亚马逊 SQS 队列指标。`ApproximateNumberOfMessagesVisible`队列中的消息数可能不会随着处理队列中的消息的 Auto Scaling 组的大小按比例发生变化。但是，用于测量消息数（自动扩缩组的每个 EC2 实例的队列中）的自定义指标能够正常工作。有关更多信息，请参阅 [基于 Amazon SQS 的扩缩策略](as-using-sqs-queue.md)。
+ 要使用 `ALBRequestCountPerTarget` 指标，您必须指定 `ResourceLabel` 参数以标识与该指标关联的负载均衡器目标组。有关使用为目标跟踪扩展策略指定`ResourceLabel`参数的示例 Amazon CLI，请参阅[的扩展策略示例 Amazon CLI](examples-scaling-policies.md)。
+ 当某个指标向 CloudWatch （例如`ALBRequestCountPerTarget`）发出实数 0 值时，当您的应用程序持续一段时间内没有流量时，Auto Scaling 组可以缩减到 0。要在没有请求路由时将自动扩缩组横向缩减至 0，组的最小容量必须设置为 0。
+ 您可以使用指标数学组合现有指标，而不必发布要在扩缩策略中使用的新指标。有关更多信息，请参阅 [使用指标数学创建目标跟踪扩缩策略](ec2-auto-scaling-target-tracking-metric-math.md)。

## 定义目标值
<a name="target-tracking-define-target-value"></a>

创建目标跟踪扩缩策略时，必须指定一个目标值。目标值表示自动扩缩组的最佳平均利用率或吞吐量。为了经济高效地使用资源，目标值的设置应尽可能高，并为流量的意外增加提供合的理缓冲。当应用程序针对正常流量进行最佳横向扩展时，实际指标值应等于或略低于目标值。

当扩缩策略基于吞吐量（例如，每目标的应用程序负载均衡器请求计数、网络 I/O 或其他计数指标）时，目标值表示单个实例在一分钟内的最佳平均吞吐量。

## 定义实例预热时间
<a name="as-target-tracking-scaling-warmup"></a>

您可以指定新启动实例的预热时间（单位为秒）。在指定的预热时间过期前，实例不会计入自动扩缩组的聚合 EC2 实例指标。

当实例处于预热时间时，仅当未预热实例的指标值大于策略的目标利用率时，您的扩缩策略才会横向扩展。

如果组再次横向扩展，则仍在预热的实例将计算为下一横向扩展活动所需容量的一部分。旨在持续 (但不过度) 扩大。

当横向扩展活动正在进行时，通过扩缩策略启动的所有横向缩减活动都将被阻止，直到实例完成预热。当实例完成预热后，如果发生横向缩减事件，那么在计算新的所需容量时，当前正在终止的任何实例都将计入该组的当前容量。因此不会从 Auto Scaling 组中删除更多实例。

**默认 值**  
如果未设置任何值，则扩缩策略将使用默认值，即为该组定义的[默认实例预热](ec2-auto-scaling-default-instance-warmup.md)值。如果默认实例预热为空，则将回退到[默认冷却时间](ec2-auto-scaling-scaling-cooldowns.md#set-default-cooldown)值。建议使用默认实例预热，以便在预热时间发生变化时更轻松地更新所有扩缩策略。

## 注意事项
<a name="target-tracking-considerations"></a>

使用目标跟踪扩缩策略时，需要注意以下事项：
+ 请勿创建、编辑或删除与目标跟踪扩展策略一起使用的 CloudWatch 警报。Amazon EC2 Auto Scaling 创建和管理与您的目标跟踪扩展策略关联的 CloudWatch警报，并且可以在必要时对其进行编辑、替换或删除，以便为您的应用程序及其不断变化的利用模式自定义扩展体验。
+ 在流量波动时，目标跟踪扩缩策略会优先考虑可用性，在流量减少时以更缓步的方式横向缩减。若想获得更大的控制权，步进扩缩策略可能是一种更好的选择。您可以临时禁用目标跟踪策略的横向缩减部分。这有助于保持成功部署所需的最小实例数量。
+ 如果指标缺少数据点，则会导致 CloudWatch 警报状态更改为`INSUFFICIENT_DATA`。发生这种情况时，在找到新的数据点之前，Amazon EC2 Auto Scaling 无法扩展您的组。
+ 如果设计为很少报告指标，则指标数学可能会很有帮助。例如，要使用最新的值，则使用 `FILL(m1,REPEAT)` 函数，其中 `m1` 是指标。
+ 您可能会看到目标值与实际指标数据点之间存在差距。这是因为我们在确定需要添加或删除多少个实例时通过向上或向下取整来保守地进行操作，以免添加的实例数量不足或删除的实例数量过多。但是，对于实例较少的 Auto Scaling 组，组的使用率可能偏离目标值较远。

  例如，假设您将 CPU 使用率的目标值设置为 50%，然后自动扩缩组超过了该目标。我们可以确定，添加 1.5 个实例会将 CPU 使用率降低到接近 50%。由于不可能添加 1.5 个实例，我们将该值向上取整，添加两个实例。这可能会将 CPU 使用率降至 50% 以下，但可确保应用程序具有充足的支持资源。类似地，如果我们确定移除 0.5 个实例可将 CPU 利用率提高到 50% 以上，那么在指标降低到我们认为横向缩减不会导致振荡之前，我们不会选择进行横向缩减。

  对于包含更多实例的更大 Auto Scaling 组，使用率分布在更多实例上，在这种情况下，添加或删除实例会导致目标值与实际指标数据点之间的差距缩小。
+ 目标跟踪扩缩策略假设它应该在指定指标高于目标值时扩展 Auto Scaling 组。在指定指标低于目标值时，不能使用目标跟踪扩缩策略来横向扩展自动扩缩组。