本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Amazon EC2 Auto Scaling 的预测式扩展
预测性扩展通过分析历史负载数据来检测流量中的每日或每周模式。它使用此信息预测未来的容量需求，以使 Amazon EC2 Auto Scaling 能够主动增加自动扩缩组的容量，以匹配预期的负载。
预测式扩展非常适合以下情况：
+ 周期性流量，例如正常营业时间内的高资源利用率以及晚上和周末的低资源利用率
+ 重复 on-and-off的工作负载模式，例如批处理、测试或定期数据分析
+ 初始化需要很长时间的应用程序，从而在向外扩展事件期间对应用程序性能造成明显的延迟影响
一般来说，如果您有定期的流量增长模式以及需要很长时间才能初始化的应用程序，则应考虑使用预测式扩展。与仅使用动态扩展相比，预测式扩展可以通过在预测负载之前启动容量来帮助您更快地扩展。预测性扩展还可以帮助您避免需要过度预置容量，从而节省 EC2 账单费用。
例如，考虑在营业时间内具有高利用率以及夜间具有低利用率的应用程序。在每个工作日开始时，预测式扩展可以在流量第一次涌入之前增加容量。这有助于您的应用程序在利用率较低的时期内保持高可用性和性能。您不必等待动态扩展来响应不断变化的流量。您也不必花时间查看应用程序的负载模式，并尝试使用计划扩展计划适当的容量。
**Topics**
+ [预测式扩展的工作方式](predictive-scaling-policy-overview.md)
+ [创建预测性扩展策略](predictive-scaling-create-policy.md)
+ [评估预测性扩展策略](predictive-scaling-graphs.md)
+ [覆盖预测](predictive-scaling-overriding-forecast-capacity.md)
+ [使用自定义指标](predictive-scaling-customized-metric-specification.md)
# 预测式扩展的工作方式
本主题说明预测性扩展的工作原理，并描述创建预测性扩展策略时需要考虑的内容。
**Topics**
+ [工作原理](#how-predictive-scaling-works)
+ [最大容量限制](#predictive-scaling-maximum-capacity-limit)
+ [注意事项](#predictive-scaling-considerations)
+ [支持的区域：](#predictive-scaling-regions)
## 工作原理
要使用预测扩展，请创建预测性扩展策略，指定要监控和分析的 CloudWatch 指标。要使预测性扩展开始预测未来值，此指标必须包含至少 24 小时的数据。
创建策略后，预测性扩展将开始分析最多过去 14 天的指标数据，以确定模式。其使用此分析生成未来 48 小时容量需求的每小时预测。使用最新 CloudWatch 数据，预测每 6 小时更新一次。随着新数据的出现，预测性扩展能够不断提高未来预测的准确性。
首次启用预测性扩展时，该功能将在*仅预测*模式下运行。在此模式下，它会生成容量预测，但不会根据这些预测实际扩展自动扩缩组。这使您可以评估预测的准确性和适用性。您可以使用 `GetPredictiveScalingForecast` API 操作或 AWS 管理控制台查看预测数据。
查看预测数据并决定根据该数据开始扩展后，将扩展策略切换到*预测和扩展*模式。在此模式中：
+ 如果预测预计负载会增加，则 Amazon EC2 Auto Scaling 将通过横向扩展来增加容量。
+ 如果预测预计负载会减少，则不会横向缩减以减少容量。如果要移除不再需要的容量，则必须创建动态扩缩策略。
默认情况下，Amazon EC2 Auto Scaling 会在每个小时开始时根据该小时的预测扩展自动扩缩组。您可以选择使用 `PutScalingPolicy` API 操作中的 `SchedulingBufferTime` 属性或 AWS 管理控制台中的**预启动实例**设置来指定更早的开始时间。这会导致 Amazon EC2 Auto Scaling 在预测的需求之前启动新实例，从而使其有时间启动并准备好处理流量。
为了支持在预测的需求之前启动新实例，强烈建议您为自动扩缩组启用*默认实例预热*。这指定了横向扩展活动结束后的一段时间，在此期间，即使动态扩缩策略指示应减少容量，Amazon EC2 Auto Scaling 也不会横向缩减。这可以帮助您确保新启动的实例在考虑进行横向缩减操作之前，有足够的时间开始为增加的流量提供服务。有关更多信息，请参阅 [为 Auto Scaling 组设置原定设置实例预热](ec2-auto-scaling-default-instance-warmup.md)。
## 最大容量限制
自动扩缩组有最大容量设置，限制了可以为该组启动的 EC2 实例的最大数量。默认情况下，设置扩缩策略后，这些策略无法将容量增加到高于最大容量。
或者，您可以允许在预测容量接近或超过自动扩缩组的最大容量时，自动增加组的最大容量。要启用此行为，请使用 `PutScalingPolicy` API 操作中的 `MaxCapacityBreachBehavior` 和 `MaxCapacityBuffer` 属性或 AWS 管理控制台中的**最大容量行为**设置。
**警告**
允许自动增加最大容量时应谨慎行事。如果不对增加的最大容量进行监控和管理，则可能导致启动的实例数量超出预期。然后，增加的最大容量将变为自动扩缩组新的正常最大容量，直到您手动对其进行更新。最大容量不会自动降回到原来的最大值。
## 注意事项
+ 确认预测式扩展是否适合您的工作负载。如果工作负载显示特定于星期几的什么时间的重复负载模式，则工作负载非常适合预测式扩展。若要检查这一点，请在*仅预测*模式下配置预测性扩展策略，然后参考控制台中的建议。Amazon EC2 Auto Scaling 会根据对潜在策略性能的观察提供建议。在允许预测式扩展主动扩展应用程序之前，请评估预测及建议。
+ 预测式扩展至少需要 24 小时的历史数据才能开始预测。但是，如果历史数据跨越整整两周，预测会更有效。如果您通过创建新的 Auto Scaling 组并删除旧组来更新应用程序，则新的 Auto Scaling 组需要 24 小时的历史加载数据，然后预测式扩展才能再次开始生成预测。您可以使用自定义指标来聚合新旧自动扩缩组之间的指标。否则，您可能需要等待几天才能获得更准确的预测。
+ 选择一个负载指标，该指标应准确代表应用程序的全部负载，并且是应用程序中对扩缩最重要的方面。
+ 将动态扩缩与预测性扩展结合使用可帮助您紧密跟踪应用程序的需求曲线，在低流量期间进行横向缩减并在流量高于预期时横向扩展。当多个扩展策略处于活动状态时，每个策略将独立确定所需容量，并将所需容量设置为其中的最大容量。例如，如果要求 10 个实例保持目标跟踪扩展策略中的目标利用率，并且需要 8 个实例保持在预测式扩展策略中的目标利用率，则组的所需容量设置为 10。如果您不熟悉动态扩缩，则建议您使用目标跟踪扩缩策略。有关更多信息，请参阅 [Amazon EC2 Auto Scaling 的动态扩缩](as-scale-based-on-demand.md)。
+ 预测性扩展的核心假设是 Auto Scaling 组是同质的，且所有实例的容量相等。如果您的组不是这样，预测的容量可能不准确。因此，在为[混合实例组](ec2-auto-scaling-mixed-instances-groups.md)创建预测性扩展策略时务必谨慎，因为可以预置容量不相等的不同类型实例。以下是一些预测容量不准确的例子：
+ 您的预测性扩展策略基于 CPU 利用率，但是每个 Auto Scaling 实例CPUs 上的 v 数因实例类型而异。
+ 您的预测性扩缩策略基于网络进入或网络外出，但每个 Auto Scaling 实例的网络带宽吞吐量因实例类型而异。例如，M5 和 M5n 实例类型相似，但 M5n 实例类型显著提高了网络吞吐量。
## 支持的区域：
+ 美国东部（弗吉尼亚州北部）
+ 美国东部（俄亥俄州）
+ 美国西部（北加利福尼亚）
+ 美国西部（俄勒冈州）
+ 非洲（开普敦）
+ 亚太地区（香港）
+ 亚太地区（海得拉巴）
+ 亚太地区（雅加达）
+ 亚太地区（墨尔本）
+ 亚太地区（孟买）
+ 亚太地区（大阪）
+ 亚太地区（首尔）
+ 亚太地区（新加坡）
+ 亚太地区（悉尼）
+ 亚太地区（东京）
+ 加拿大（中部）
+ 加拿大西部（卡尔加里）
+ 中国（北京）
+ 中国（宁夏）
+ 欧洲地区（法兰克福）
+ 欧洲地区（爱尔兰）
+ 欧洲地区（伦敦）
+ 欧洲地区（米兰）
+ 欧洲地区（巴黎）
+ 欧洲（西班牙）
+ 欧洲地区（斯德哥尔摩）
+ 欧洲（苏黎世）
+ 以色列（特拉维夫）
+ Middle East (Bahrain)
+ 中东（阿联酋）：
+ 南美洲（圣保罗）
+ AWS GovCloud （美国东部）
+ AWS GovCloud （美国西部）
# 创建自动扩缩组的预测性扩展策略
以下过程可帮助您使用 AWS 管理控制台 或创建预测性扩展策略 AWS CLI。
如果自动扩缩组为新组，则必须提供至少 24 小时的数据，然后 Amazon EC2 Auto Scaling 才会为其生成预测。
**Topics**
+ [创建预测式扩展策略（控制台）](#predictive-scaling-policy-console)
+ [创建预测式扩展策略 (AWS CLI）](#predictive-scaling-policy-aws-cli)
## 创建预测式扩展策略（控制台）
如果这是您第一次创建预测性扩展策略，则建议您使用控制台在*仅预测*模式下创建多个预测性扩展策略。这样便可测试不同指标和目标值的潜在影响。您可以为每个 Auto Scaling 组创建多个预测式扩展策略，但只能将其中一个策略用于主动扩展。
### 通过控制台创建预测性扩缩策略（预定义指标）
按照以下程序，使用预定义的指标（每个目标的 CPU、网络 I/O 或应用程序负载均衡器请求数）创建预测性扩缩策略。创建预测性扩缩策略的最简单方式，是使用预定义指标。如果您希望使用自定义指标，请参阅 [通过控制台创建预测性扩缩策略（自定义指标）](#create-a-predictive-scaling-policy-in-the-console-custom-metrics)。
**创建预测式扩展策略**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选中您的自动扩缩组旁边的复选框。
这时将在页面底部打开一个拆分窗格。
1. 在**自动扩展**选项卡的**扩展策略**中，选择**创建预测式扩展策略**。
1. 输入策略的名称。
1. 启用**根据预测进行扩展**，授予 Amazon EC2 Auto Scaling 立即开始扩展的权限。
若要将策略保持在*仅预测*模式，请保持**根据预测进行扩展**关闭状态。
1. 对于**指标**，从选项列表中选择指标。选项包括 **CPU**、**网络输入**、**网络输出**、**Application Load Balancer 请求计数**和**自定义指标对**。
如果您选择**每目标的 Application Load Balancer 请求计数**，请在**目标组**中选择目标组。**每目标的 Application Load Balancer 请求计数**仅在您已将 Application Load Balancer 目标组附加到 Auto Scaling 组时才支持。
如果您选择**自定义指标对**，请从**负载指标**和**扩展指标**的下拉列表中选择单个指标。
1. 对于**目标利用率**，请输入 Amazon EC2 Auto Scaling 应维护的目标值。Amazon EC2 Auto Scaling 可向外扩展您的容量直到平均利用率达到目标利用率，或直到达到您指定的最大实例数。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/autoscaling/ec2/userguide/predictive-scaling-create-policy.html)
1. （可选）对于**预启动实例**，请选择您希望在预测调用增加负载之前启动实例的距离。
1. （可选）对于 **Max capacity behavior**（最大容量行为），请选择当预测容量超过定义的最大值时，是否允许 Amazon EC2 Auto Scaling 横向扩展至高于该组最大容量的水平。通过开启此设置，您将可以在预测您的流量会触及最大值期间进行横向扩展。
1. （可选）对于**高于预测容量的缓冲区最大容量**，选择在预测容量接近或超过最大容量时要使用的附加容量。该值是作为相对于预测容量的百分比指定的。例如，如果缓冲区为 10，这意味着 10% 的缓冲区。因此，如果预测容量为 50，最大容量为 40，则有效的最大容量是 55。
如果设置为 0，Amazon EC2 Auto Scaling 可以将容量扩展到高于最大容量，直至等于但不能超过预测容量的水平。
1. 选择**创建预测式扩展策略**。
### 通过控制台创建预测性扩缩策略（自定义指标）
按照以下程序，使用自定义指标创建预测性扩缩策略。自定义指标可以包括提供的其他指标 CloudWatch 或您发布到的指标 CloudWatch。要使用每个目标的 CPU、网络 I/O 或应用程序负载均衡器请求数指标，请参阅 [通过控制台创建预测性扩缩策略（预定义指标）](#create-a-predictive-scaling-policy-in-the-console)。
要使用自定义指标创建预测性扩缩策略，您必须执行以下操作：
+ 您必须提供原始查询，让 Amazon EC2 Auto Scaling 与中的指标进行交互 CloudWatch。有关更多信息，请参阅 [使用自定义指标的高级预测性扩展策略](predictive-scaling-customized-metric-specification.md)。为确保 Amazon EC2 Auto Scaling 可以从中提取指标数据 CloudWatch，请确认每个查询都返回了数据点。使用 CloudWatch 控制台或 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)API 操作进行确认。
**注意**
我们在 Amazon EC2 Auto Scaling 控制台中的 JSON 编辑器中提供了示例 JSON 负载。这些示例为您提供了添加由提供的其他 CloudWatch 指标 AWS 或您之前发布到的指标所需的键值对的参考。 CloudWatch您可以将这些示例负载作为起点，然后根据需要进行自定义。
+ 如果您使用任何指标数学，则必须手动构造适合您的独特应用场景的 JSON。有关更多信息，请参阅 [使用指标数学表达式](using-math-expression-examples.md)。在策略中使用指标数学之前，请确认基于指标数学表达式的指标查询有效并返回了单个时间序列。使用 CloudWatch 控制台或 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)API 操作进行确认。
如果因提供的数据错误（例如自动扩缩组名称出错），您的查询出现错误，则预测将没有任何数据。要排查自定义指标问题，请参阅 [预测性扩展策略中自定义指标的注意事项](custom-metrics-troubleshooting.md)。
**创建预测式扩展策略**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选中您的自动扩缩组旁边的复选框。
这时将在页面底部打开一个拆分窗格。
1. 在**自动扩展**选项卡的**扩展策略**中，选择**创建预测式扩展策略**。
1. 输入策略的名称。
1. 启用**根据预测进行扩展**，授予 Amazon EC2 Auto Scaling 立即开始扩展的权限。
若要将策略保持在*仅预测*模式，请保持**根据预测进行扩展**关闭状态。
1. 对于 **Metrics**（指标），选择 **Custom metric pair**（自定义指标对）。
1. 对于**加载指标**，选择**自定义 CloudWatch 指标**以使用自定义指标。构造包含策略的负载指标定义的 JSON 负载，然后将其粘贴到 JSON 编辑器框中，替换其中已有的内容。
1. 对于**缩放指标**，请选择**自定义 CloudWatch 指标**以使用自定义指标。构造包含策略的扩缩指标定义的 JSON 负载，然后将其粘贴到 JSON 编辑器框中，替换其中已有的内容。
1. （可选）要添加自定义容量指标，请选中 **Add custom capacity metric**（添加自定义容量指标）复选框。构造包含策略的容量指标定义的 JSON 负载，然后将其粘贴到 JSON 编辑器框中，替换其中已有的内容。
如果您的容量指标数据跨越多个自动扩缩组，则只需启用此选项即可创建新的容量时间序列。在这种情况下，必须使用指标数学将数据聚合成单个时间序列。
1. 对于**目标利用率**，请输入 Amazon EC2 Auto Scaling 应维护的目标值。Amazon EC2 Auto Scaling 可向外扩展您的容量直到平均利用率达到目标利用率，或直到达到您指定的最大实例数。
1. （可选）对于**预启动实例**，请选择您希望在预测调用增加负载之前启动实例的距离。
1. （可选）对于 **Max capacity behavior**（最大容量行为），请选择当预测容量超过定义的最大值时，是否允许 Amazon EC2 Auto Scaling 横向扩展至高于该组最大容量的水平。通过开启此设置，您将可以在预测您的流量会触及最大值期间进行横向扩展。
1. （可选）对于**高于预测容量的缓冲区最大容量**，选择在预测容量接近或超过最大容量时要使用的附加容量。该值是作为相对于预测容量的百分比指定的。例如，如果缓冲区为 10，这意味着 10% 的缓冲区。因此，如果预测容量为 50，最大容量为 40，则有效的最大容量是 55。
如果设置为 0，Amazon EC2 Auto Scaling 可以将容量扩展到高于最大容量，直至等于但不能超过预测容量的水平。
1. 选择**创建预测式扩展策略**。
## 创建预测式扩展策略 (AWS CLI）
使用以下方法为您 AWS CLI 的 Auto Scaling 组配置预测性扩展策略。将每个 *user input placeholder* 替换为您自己的信息。
有关您可以指定的 CloudWatch 指标的更多信息，请参阅[PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)《*Amazon EC2 Auto Scaling API 参考*》。
### 示例 1：创建预测但不扩展的预测式扩展策略
以下示例策略显示了完整的策略配置，该配置使用 CPU 利用率指标进行预测式扩展，其中目标利用率为 `40`。默认使用 `ForecastOnly` 模式，除非您明确指定要使用的模式。将此配置保存在名为 `config.json` 的文件中。
```
{
"MetricSpecifications": [
{
"TargetValue": 40,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"
}
}
]
}
```
要从命令行创建策略，请在指定配置文件的情况下运行该[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令，如以下示例所示。
```
aws autoscaling put-scaling-policy --policy-name cpu40-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
```
如果成功，此命令将返回策略的 Amazon Resource Name (ARN)。
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/cpu40-predictive-scaling-policy",
"Alarms": []
}
```
### 示例 2：预测和扩展的预测式扩展策略
对于允许 Amazon EC2 Auto Scaling 预测和扩展的策略，请添加值为 `ForecastAndScale` 的属性 `Mode`。以下示例显示了使用 Application Load Balancer 请求计数指标的策略配置。目标利用率是 `1000`，并且预测式扩展设置为 `ForecastAndScale` 模式。
```
{
"MetricSpecifications": [
{
"TargetValue": 1000,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ALBRequestCount",
"ResourceLabel": "app/my-alb/778d41231b141a0f/targetgroup/my-alb-target-group/943f017f100becff"
}
}
],
"Mode": "ForecastAndScale"
}
```
要创建此策略，请使用指定的配置文件运行[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令，如以下示例所示。
```
aws autoscaling put-scaling-policy --policy-name alb1000-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
```
如果成功，此命令将返回策略的 Amazon 资源名称（ARN）。
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:19556d63-7914-4997-8c81-d27ca5241386:autoScalingGroupName/my-asg:policyName/alb1000-predictive-scaling-policy",
"Alarms": []
}
```
### 示例 3：可扩展大于最大容量的预测式扩展策略
以下示例显示如何创建一个策略，该策略可以在您需要它来处理高于正常负载时扩展高于组的最大大小限制。预设情况下，Amazon EC2 Auto Scaling 的 EC2 扩展容量不会超过您定义的最大容量。但是，如果让它扩展更高，容量稍微增加以避免性能或可用性问题，可能会有所帮助。
要为 Amazon EC2 Auto Scaling 提供空间，以便在容量预计达到或非常接近组的最大大小时配置额外容量，请指定 `MaxCapacityBreachBehavior` 和 `MaxCapacityBuffer` 属性，如以下示例所示。您必须指定值为 `IncreaseMaxCapacity` 的 `MaxCapacityBreachBehavior`。您的组可以具有的最大实例数取决于 `MaxCapacityBuffer` 值。
```
{
"MetricSpecifications": [
{
"TargetValue": 70,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"
}
}
],
"MaxCapacityBreachBehavior": "IncreaseMaxCapacity",
"MaxCapacityBuffer": 10
}
```
在本示例中，该策略配置为使用 10% 缓冲区 (`"MaxCapacityBuffer": 10`)，因此如果预测容量为 50 并且最大容量为 40，则实际的最大容量为 55。如果策略可以将容量扩展到高于最大容量以等于但不超过预测容量，则缓冲区为 0 (`"MaxCapacityBuffer": 0`)。
要创建此策略，请使用指定的配置文件运行[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令，如以下示例所示。
```
aws autoscaling put-scaling-policy --policy-name cpu70-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
```
如果成功，此命令将返回策略的 Amazon 资源名称（ARN）。
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:d02ef525-8651-4314-bf14-888331ebd04f:autoScalingGroupName/my-asg:policyName/cpu70-predictive-scaling-policy",
"Alarms": []
}
```
# 评估预测性扩展策略
在使用预测性扩展策略扩展您的自动扩缩组之前，请在 Amazon EC2 Auto Scaling 控制台中查看您策略的建议和其他数据。这很重要，因为在确定预测准确之前，您不希望使用预测扩展策略来扩展实际容量。
如果自动扩缩组是新的，则需要 24 小时的时间让 Amazon EC2 Auto Scaling 创建第一个预测。
当 Amazon EC2 Auto Scaling 创建预测时，它使用历史数据。如果您的自动扩缩组还没有太多最近的历史数据，Amazon EC2 Auto Scaling 可能会使用从当前可用的历史聚合中创建的聚合数据临时回填预测。预测会在策略创建日期前最多回填两周。
**Topics**
+ [查看建议](#view-predictive-scaling-recommendations)
+ [查看监控图表](#review-predictive-scaling-monitoring-graphs)
+ [使用监控指标 CloudWatch](monitor-predictive-scaling-cloudwatch.md)
## 查看您的预测性扩展建议
为了进行有效的分析，Amazon EC2 Auto Scaling 应至少有两个预测性扩展策略可供比较。（但您仍可以查看单个策略的调查结果。） 创建多个策略时，您可以对使用一个指标的策略和使用另一个指标的策略进行评估。您还可以评估不同目标值和指标组合的影响。创建预测性扩展策略后，Amazon EC2 Auto Scaling 会立即开始评估哪种策略可以更好地扩展您的组。
**在 Amazon EC2 Auto Scaling 控制台中查看您的建议**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选中 Auto Scaling 组旁边的复选框。
这时将在页面底部打开一个拆分窗格。
1. 在 **Auto Scaling** 选项卡的**预测性扩展策略**下，您可以查看有关策略的详细信息以及我们的建议。该建议告诉您预测性扩展策略是否比不使用预测性扩展策略做得更好。
如果您不确定预测性扩展策略是否适合您的组，请查看**可用性影响**和**成本影响**列以选择正确的策略。每列的信息告诉您该策略的影响。
+ **可用性影响**：描述与不使用策略相比，该策略是否可以通过预置足够的实例来处理工作负载，从而避免对可用性的负面影响。
+ **成本影响**：描述与不使用策略相比，该策略是否可以通过不过度预置实例而避免对您的成本产生负面影响。过度预置会导致您的实例未得到充分利用或处于闲置状态，这只会增加对成本的影响。
如果您有多个策略，则在以较低成本提供最大可用性优势的策略名称旁边显示**最佳预测**标签。对可用性的影响给予了更多的重视。
1. （可选）要为建议结果选择所需的时间段，请从**评估期**下拉列表中选择您的首选值：**2 天**、**1 周**、**2 周**、**4 周**、**6 周**或 **8 周**。默认情况下，评估期为过去两周。更长的评估期可为建议结果提供更多的数据点。但是，如果您的负载模式发生了变化，例如在需求异常之后，添加更多数据点可能不会改善结果。在这种情况下，您可以通过查看最新数据来获得更有针对性的建议。
**注意**
仅为处于**仅预测**模式的策略生成建议。当策略在整个评估期内处于**仅预测**模式时，建议功能的效果会更好。如果您在**预测和扩展**模式下启动策略，稍后将其切换为**仅预测**模式，则该策略的调查结果可能会有偏差。这是因为该策略已经为实际容量做出了贡献。
## 查看预测性扩展监控图表
在 Amazon EC2 Auto Scaling 控制台中，您可以查看前几天、几周或几个月的预测，以便可视化策略在一段时间内的表现如何。在决定是否让策略扩展您的实际容量时，您还可以使用这些信息来评估预测的准确性。
**在 Amazon EC2 Auto Scaling 控制台中查看预测性扩展监控图表**
1. 从**预测性扩展策略**列表中选择一个策略。
1. 在**监控**部分中，您可以根据实际值查看策略对过去和未来负载和容量的预测。**负载**图表显示所选负载指标的负载预测和实际值。**容量**图表显示策略预测的实例数量。它还包括启动实例的实际数量。垂直线将历史值与未来预测分开。创建策略后不久，这些图表可用。
1. （可选）要更改图表中显示的历史数据量，请从页面顶部的**评估期**下拉列表中选择您的首选值。评估期不会以任何方式转换此页面上的数据。它只会更改显示的历史数据量。
下图显示了多次应用预测时的**负载**和**容量**图表。预测性扩展会根据您的历史负载数据来预测负载。应用程序生成的负载由自动扩缩组中每个实例的 CPU 利用率、网络输入/输出、收到的请求或自定义指标的总和来表示。预测性扩展会根据负载预测和您希望扩展指标达到的目标利用率来计算未来的容量需求。
![\[预测性扩展图表\]](http://docs.aws.amazon.com/zh_cn/autoscaling/ec2/userguide/images/predictive-scaling-graphs.png)
**比较**负载**图表中的数据**
每条水平线代表一小时间隔内报告的一组不同的数据点：
1. **实际观测负载**使用所选负载指标的 SUM 统计数据来显示过去每小时的总负载。
1. **策略预测的负载**显示每小时的负载预测。该预测基于前两周的实际负载观测结果。
**比较**容量**图表中的数据**
每条水平线代表一小时间隔内报告的一组不同的数据点：
1. **实际观察到的容量**显示了启用该[GroupTotalInstances](ec2-auto-scaling-metrics.md#as-group-metrics)指标时您的 Auto Scaling 组过去的实际容量。该容量取决于其他扩缩策略以及所选时间段内的最小组大小。
1. **策略预测的容量**显示当策略处于**预测和扩展**模式时，您在每个小时开始时期望拥有的基准容量。
1. **推断的所需容量**显示将扩展指标维持在您所选择目标值的理想容量。
1. **最小容量**显示自动扩缩组的最小容量。
1. **最大容量**显示自动扩缩组的最大容量。
为了计算推断的所需容量，我们首先假设每个实例在指定目标值下的利用率相等。实际上，实例的利用率并不均等。但是，通过假设实例之间的利用率分布均匀，我们可以对所需的容量进行可能的估计。然后计算容量需求与您在预测性扩展策略中使用的扩展指标成反比。换句话说，随着容量的增加，扩展指标会以相同的速率减少。例如，如果容量翻倍，则扩展指标必定会减少一半。
推断的所需容量的公式：
`sum of (actualCapacityUnits*scalingMetricValue)/(targetUtilization)`
例如，我们在给定一小时内使用 `actualCapacityUnits`（`10`）和 `scalingMetricValue`（`30`）。然后，我们采用您在预测扩展策略（`60`）中指定的 `targetUtilization`，计算同一小时的推断所需容量。这会返回值 `5`。这意味着 5 是推断出的维持容量所需的容量，与扩展指标的目标值成反比。
**注意**
您可以使用各种杠杆来调整和提高应用程序的成本节约和可用性。
您可以使用预测性扩展来计算基准容量，使用动态扩展来处理额外的容量。动态扩展独立于预测性扩展，会根据当前的利用率向内和向外扩展。首先，Amazon EC2 Auto Scaling 计算每个动态扩展策略的建议实例数。然后，它会根据提供最多实例的策略进行扩展。
要允许在负载减少时进行横向缩减，您的自动扩缩组应始终至少有一个启用了横向缩减部分的动态扩展策略。
您可以通过确保最小和最大容量不太严格来提高扩展性能。如果策略中包含的推荐实例数不在最小和最大容量范围内，则将阻止横向缩减和横向扩展。
# 使用监控预测性扩展指标 CloudWatch
根据您的需求，您可能更愿意从亚马逊访问用于预测性扩展的监控数据， CloudWatch 而不是 Amazon EC2 Auto Scaling 控制台。创建预测性扩缩策略后，该策略将收集用于预测未来负载和容量的数据。收集这些数据后，系统会定期自动将其存储。 CloudWatch 然后，您可以使用可视 CloudWatch 化策略在一段时间内的执行情况。您还可以创建 CloudWatch 警报，以便在绩效指标变化超出您在中定义的限制时通知您 CloudWatch。
**Topics**
+ [可视化显示历史预测数据](#visualize-historical-forecast-data)
+ [使用指标数学创建准确度指标](#create-accuracy-metrics)
## 可视化显示历史预测数据
您可以在中查看预测性扩展策略的负载和容量预测数据 CloudWatch。在单个图表中根据其他 CloudWatch指标对预测进行可视化时，这可能很有用。您还可以查看更大的时间范围，以了解长期的趋势，这也非常有益。您可以访问长达 15 个月的历史指标，以更好地了解您的策略性能。
有关更多信息，请参阅 [预测性扩缩指标和维度](ec2-auto-scaling-metrics.md#predictive-scaling-metrics)。
**使用 CloudWatch 控制台查看历史预测数据**
1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。
1. 在导航窗格中，选择 **Metrics**（指标），然后选择 **All metrics**（所有指标）。
1. 选择 **Auto Scaling**（自动扩缩）指标命名空间。
1. 选择下面的一个选项，以查看负载预测或容量预测指标：
+ **Predictive Scaling Load Forecasts**（预测性扩缩负载预测）
+ **Predictive Scaling Capacity Forecasts**（预测性扩缩容量预测）
1. 在搜索字段中，输入预测性扩缩策略的名称或自动扩缩组的名称，然后按 Enter 键以筛选结果。
1. 要为指标绘制图表，请选中该指标旁的复选框。要更改图表的名称，请选择铅笔图标。要更改时间范围，请选择某个预定义的值或选择 **custom**。有关更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[绘制指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html)图表。
1. 要更改统计数据，请选择 **Graphed metrics**（已绘制图表指标）选项卡。选择列标题或单个值，然后选择其他统计数据。尽管您可以为每个指标选择任何统计数据，但并非所有统计数据都对**PredictiveScalingLoadForecast**和**PredictiveScalingCapacityForecast**指标有用。例如，**平均**、**最小**和**最大**统计数据非常有用，但**总和**统计数据用处不大。
1. 要在图表中添加其他指标，请在 **All**（全部）下选择 **Browse**（浏览），找到特定的指标，然后选中它旁边的复选框。您最多可以添加 10 个指标。
例如，要将 CPU 利用率的实际值添加到图表中，请选择 **EC2** 命名空间，然后选择 **By Auto Scaling Group**（按自动扩缩组）。然后，选中该**CPUUtilization**指标和特定的 Auto Scaling 组对应的复选框。
1. （可选）要将图表添加到 CloudWatch 仪表板，请选择**操作**，然后选择**添加到仪表板**。
## 使用指标数学创建准确度指标
使用指标数学，您可以查询多个 CloudWatch 指标，并使用数学表达式根据这些指标创建新的时间序列。您可以在 CloudWatch 控制台上可视化生成的时间序列并将其添加到仪表板中。有关指标数学的更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[使用指标数学](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。
借助指标数学，您能够以不同方式绘制 Amazon EC2 Auto Scaling 为预测性扩缩而生成的数据。这可帮助您监控随时间变化的策略性能，并帮助您了解是否可以改进指标组合。
例如，您可以使用指标数学表达式来监控[平均绝对百分比误差](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error)（MAPE）。MAPE 指标可帮助监控在给定预测时段内预测值与实际观测值之间的差异。MAPE 值的变化可能表明随着应用性质的变化，策略的性能是否会随着时间的推移而下降。MAPE 增加说明着预测值和实际值之间的差异加大。
**示例：指标数学表达式**
要开始使用此类图表，您可以创建一个与下例中类似的指标数学表达式。
```
{
"MetricDataQueries": [
{
"Expression": "TIME_SERIES(AVG(ABS(m1-m2)/m1))",
"Id": "e1",
"Period": 3600,
"Label": "MeanAbsolutePercentageError",
"ReturnData": true
},
{
"Id": "m1",
"Label": "ActualLoadValues",
"MetricStat": {
"Metric": {
"Namespace": "AWS/EC2",
"MetricName": "CPUUtilization",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Period": 3600,
"Stat": "Sum"
},
"ReturnData": false
},
{
"Id": "m2",
"Label": "ForecastedLoadValues",
"MetricStat": {
"Metric": {
"Namespace": "AWS/AutoScaling",
"MetricName": "PredictiveScalingLoadForecast",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
},
{
"Name": "PolicyName",
"Value": "my-predictive-scaling-policy"
},
{
"Name": "PairIndex",
"Value": "0"
}
]
},
"Period": 3600,
"Stat": "Average"
},
"ReturnData": false
}
]
}
```
这不是单个指标，而是一组针对 `MetricDataQueries` 的指标数据查询结构。`MetricDataQueries` 中的每一项都会获取一个指标或执行一个数学表达式。第一项 `e1` 是一个数学表达式。指定的表达式将 `ReturnData` 参数设置为 `true`，这最终会生成单个时间序列。对于所有其他指标，`ReturnData` 值为 `false`。
在示例中，指定的表达式使用实际值和预测值作为输入，并返回新的指标 (MAPE)。 `m1`是包含实际负载值的 CloudWatch指标（假设 CPU 利用率是最初为名为的策略指定的负载指标`my-predictive-scaling-policy`）。 `m2`是包含预测负荷值的 CloudWatch指标。MAPE 指标的数学语法如下所示：
*（（实际值：预测值）/（实际值）的绝对值）的平均值*
### 可视化显示准确度指标并设置警报
要可视化准确度指标数据，请在 CloudWatch 控制台中选择**指标**选项卡。您可以在此处绘制数据图表。有关更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[向 CloudWatch 图表添加数学表达式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console)。
您还可以在 **Metrics**（指标）部分为您监控的指标设置警报。在 **Graphed metrics**（绘制的指标）选项卡中，选择 **Actions**（操作）列下的 **Create alarm**（创建警报）。**Create alarm**（创建警报）图标用一个小铃铛表示。有关更多信息和通知选项，请参阅《*Amazon 用户指南》中的[基于指标数学表达式创建](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html)警报和通知 CloudWatch 用户*[警报更改](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html)。 CloudWatch
或者，您可以使用[GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)和[PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)使用公制数学进行计算，并根据输出创建警报。
# 使用计划操作覆盖预测值
有时，您可能会获得有关未来应用程序需求的其他信息，预测计算无法考虑这些信息。例如，预测计算可能会低估即将举行的市场营销活动所需的容量。您可以使用计划操作在未来时段内临时覆盖预测。计划操作可以循环运行，也可以在出现一次性需求波动的特定日期和时间运行。
例如，您可以创建具有高于预测容量的最小容量的计划操作。运行时，Amazon EC2 Auto Scaling 会更新 Auto Scaling 组的最小容量。由于预测式扩展可针对容量进行优化，因此执行最小容量高于预测值的计划操作。这样可以防止容量低于预期。要停止覆盖预测，请使用第二个计划操作将最小容量恢复到其原始设置。
以下过程概述了在将来期间覆盖预测的步骤。
**Topics**
+ [步骤 1：（可选）分析时间序列数据](#analyzing-time-series-data)
+ [步骤 2：创建两个计划操作](#scheduling-capacity)
**重要**
本主题假设您尝试覆盖预测，以扩展到比预测更高的容量。如果您需要在不受预测性扩展策略干扰的情况下暂时减少容量，则请改用*仅预测*模式。在仅预测模式下，预测性扩展将继续生成预测，但不会自动增加容量。然后，您可以监控资源利用率，并根据需要手动缩减组大小。有关手动扩缩的更多信息，请参阅[Amazon EC2 Auto Scaling 的手动扩缩](ec2-auto-scaling-scaling-manually.md)。
## 步骤 1：（可选）分析时间序列数据
首先分析预测时间序列数据。这是一个可选步骤，但如果您想了解预测的详细信息，它会很有帮助。
1. **检索预测**
创建预测后，您可以查询预测中的特定时间段。查询的目的是获得特定时间段的时间序列数据的完整视图。
您的查询最多可以包含两天的未来预测数据。如果您已经使用了一段时间预测式扩展，您还可以访问过去的预测数据。但是，开始和结束时间之间的最长持续时间为 30 天。
要使用命令获取预测，[get-predictive-scaling-forecast](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI 请在命令中提供以下参数：
+ 在 `--auto-scaling-group-name` 参数中输入 Auto Scaling 组的名称。
+ 在 `--policy-name` 参数中输入策略的名称。
+ 在 `--start-time` 参数中输入开始时间以仅返回在指定时间或之后的预测数据。
+ 在 `--end-time` 参数中输入结束时间以仅返回在指定时间之前的预测数据。
```
aws autoscaling get-predictive-scaling-forecast --auto-scaling-group-name my-asg \
--policy-name cpu40-predictive-scaling-policy \
--start-time "2021-05-19T17:00:00Z" \
--end-time "2021-05-19T23:00:00Z"
```
如果成功，该命令将返回类似于以下示例的数据。
```
{
"LoadForecast": [
{
"Timestamps": [
"2021-05-19T17:00:00+00:00",
"2021-05-19T18:00:00+00:00",
"2021-05-19T19:00:00+00:00",
"2021-05-19T20:00:00+00:00",
"2021-05-19T21:00:00+00:00",
"2021-05-19T22:00:00+00:00",
"2021-05-19T23:00:00+00:00"
],
"Values": [
153.0655799339254,
128.8288551285919,
107.1179447150675,
197.3601844551528,
626.4039934516954,
596.9441277518481,
677.9675713779869
],
"MetricSpecification": {
"TargetValue": 40.0,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"
}
}
}
],
"CapacityForecast": {
"Timestamps": [
"2021-05-19T17:00:00+00:00",
"2021-05-19T18:00:00+00:00",
"2021-05-19T19:00:00+00:00",
"2021-05-19T20:00:00+00:00",
"2021-05-19T21:00:00+00:00",
"2021-05-19T22:00:00+00:00",
"2021-05-19T23:00:00+00:00"
],
"Values": [
2.0,
2.0,
2.0,
2.0,
4.0,
4.0,
4.0
]
},
"UpdateTime": "2021-05-19T01:52:50.118000+00:00"
}
```
此响应包括两个预测：`LoadForecast` 和 `CapacityForecast`。`LoadForecast` 显示每小时负载预测。`CapacityForecast` 显示每小时处理预测负载所需的容量的预测值，同时保持 `TargetValue` 为 40.0（平均 CPU 利用率为 40%）。
1. **确定目标时间段**
确定应发生一次性需求波动的小时数。请记住，预测中显示的日期和时间以 UTC 为单位。
## 步骤 2：创建两个计划操作
接下来，在应用程序的负载高于预测负载的特定时间段内创建两个计划操作。例如，如果您的营销活动会在有限时间段内使网站的流量增加，则可计划一个一次性操作以在其启动时更新最小容量。然后，安排另一个操作，以便在事件结束时将最小容量返回到原始设置。
**为一次性事件创建两个计划操作（控制台）**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选中您的自动扩缩组旁边的复选框。
这时将在页面底部打开一个拆分窗格。
1. 在 **Automatic scaling**（自动扩展）选项卡上的 **Scheduled actions**（计划操作）中，选择 **Create scheduled action**（创建计划操作）。
1. 填写以下计划操作设置：
1. 为计划操作输入**名称**。
1. 对于**最小值**，输入 Auto Scaling 组的最小新容量。**最小值**必须小于或等于组的最大大小。如果**最小值**大于该组的最大大小，则必须更新**最大值**。
1. 对于**循环**，选择**一次**。
1. 对于**时区**，请选择时区。如果未选择任何时区，预设情况下使用 `ETC/UTC`。
1. 定义**特定开始时间**。
1. 选择**创建**。
控制台将显示 Auto Scaling 组的计划操作。
1. 配置第二个计划操作，以在事件结束时将最小容量返回原始设置。预测式扩展只能在设置**最小值**小于预测值时扩展容量。
**为一次性事件创建两个计划操作 (AWS CLI）**
要使用创建计划操作，请使用 [put-scheduled-update-group-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scheduled-update-group-action.html) 命令。 AWS CLI
例如，让我们定义一个时间表，在 5 月 19 日下午 5:00 时保持最少三个实例的容量，持续 8 小时。以下命令显示如何实现此方案。
第一个[put-scheduled-update-group操作](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scheduled-update-group-action.html)命令指示亚马逊 EC2 Auto Scaling 在世界标准时间 2021 年 5 月 19 日下午 5:00 更新指定 Auto Scaling 组的最小容量。
```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \
--auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3
```
第二个命令指示 Amazon EC2 Auto Scaling 将该组的最小容量设置为 2021 年 5 月 20 日 UTC 上午 1:00。
```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \
--auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1
```
将这些计划操作添加到自动扩缩组后，Amazon EC2 Auto Scaling 将执行以下操作：
+ 2021 年 5 月 19 日下午 5:00，第一个计划的操作将运行。如果组中当前已少于三个实例，则该组会扩展到三个实例。在此期间和接下来的八小时内，如果预测容量高于实际容量，或者如果有动态扩展策略生效，Amazon EC2 Auto Scaling 可以继续横向扩展。
+ 2021 年 5 月 20 日上午 1:00，将运行第二个计划的操作。这将在事件结束时将最小容量恢复为其原始设置。
### 根据重复性计划进行扩展
要覆盖每周相同时间段的预测，请创建两个计划操作，并使用 cron 表达式提供时间和日期逻辑。
此 cron 表达式格式包含五个空格分隔的字段：[Minute] [Hour] [Day\$1of\$1Month] [Month\$1of\$1Year] [Day\$1of\$1Week]。字段可以包含任何允许的值，包括特殊字符。
例如，下面的 cron 表达式在每周二上午 6:30 运行操作。星号用作通配符，以匹配字段的所有值。
```
30 6 * * 2
```
### 另请参阅
有关如何创建、列出、编辑和删除计划操作的更多信息，请参阅 [Amazon EC2 Auto Scaling 的计划扩缩](ec2-auto-scaling-scheduled-scaling.md)。
# 使用自定义指标的高级预测性扩展策略
在预测性扩展策略中，您可以使用预定义指标或自定义指标。当预定义指标（CPU、网络 I/O 和 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)
## 最佳实践
以下最佳实践可帮助您更有效地使用自定义指标：
+ 对于负载指标规范，最有用的指标是作为一个整体表示 Auto Scaling 组负载的指标，而不管该组的容量如何。
+ 对于扩展指标规范，要扩展的最有用指标是每个实例的平均吞吐量或利用率指标。
+ 扩展指标必须与容量成反比。也就是说，如果 Auto Scaling 组中的实例数量增加，则扩展指标应该减少大致相同的比例。为确保预测性扩展按预期采取行动，负载指标和扩展指标还必须彼此之间密切关联。
+ 目标利用率必须与扩展指标的类型匹配。对于使用 CPU 利用率的策略配置，这是目标百分比。对于使用吞吐量（例如请求数或消息数）的策略配置，这是在任何一分钟间隔内每个实例的目标请求数或目标消息数。
+ 如果未遵循这些建议，那么时间序列的预测未来值可能会不正确。要验证数据是否正确，您可以在 Amazon EC2 Auto Scaling 控制台中查看预测值。或者，在创建预测性扩展策略后，检查调用 [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_GetPredictiveScalingForecast.html)API 返回的`LoadForecast`和`CapacityForecast`对象。
+ 我们强烈建议您在仅预测模式下配置预测式扩展，以便在预测式扩展开始主动扩展容量之前对预测进行评估。
## 先决条件
要将自定义指标添加到预测性扩缩策略，您必须具有 `cloudwatch:GetMetricData` 权限。
要指定自己的指标而不是 AWS 提供的指标，必须先将指标发布到 CloudWatch。有关更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。
如果发布自己的指标，请确保以至少五分钟的频率发布数据点。Amazon EC2 Auto Scaling 会 CloudWatch 根据所需的时间段长度从中检索数据点。例如，负载指标规范使用每小时指标来衡量应用程序的负载。 CloudWatch 使用您发布的指标数据，通过将所有数据点与每个一小时内的时间戳聚合在一起，为任何一小时的时间段提供单个数据值。
# 构造自定义指标的 JSON
以下部分包含有关如何配置预测缩放以从中查询数据的示例 CloudWatch。配置此选项有两种不同的方法，您选择的方法会影响您为预测性扩缩策略构造 JSON 时使用的格式。使用指标数学时，JSON 格式会根据所执行的指标数学进一步变化。
1. 要创建可直接从提供的其他 CloudWatch 指标 AWS 或您发布到的指标中获取数据的策略 CloudWatch，请参阅[包含自定义负载和扩缩指标的预测性扩缩策略示例（AWS CLI）](#custom-metrics-ex1)。
1. 要创建可查询多个 CloudWatch 指标并使用数学表达式根据这些指标创建新时间序列的策略，请参阅[使用指标数学表达式](using-math-expression-examples.md)。
## 包含自定义负载和扩缩指标的预测性扩缩策略示例（AWS CLI）
要使用创建带有自定义负载和扩展指标的预测性扩展策略 AWS CLI，请将的参数存储`--predictive-scaling-configuration`在名为的 JSON 文件中`config.json`。
您可以将以下示例中的可替换值替换为您的指标和目标利用率值，从而开始添加自定义指标。
```
{
"MetricSpecifications": [
{
"TargetValue": 50,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Id": "scaling_metric",
"MetricStat": {
"Metric": {
"MetricName": "MyUtilizationMetric",
"Namespace": "MyNameSpace",
"Dimensions": [
{
"Name": "MyOptionalMetricDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}
]
},
"Stat": "Average"
}
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_metric",
"MetricStat": {
"Metric": {
"MetricName": "MyLoadMetric",
"Namespace": "MyNameSpace",
"Dimensions": [
{
"Name": "MyOptionalMetricDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}
]
},
"Stat": "Sum"
}
}
]
}
}
]
}
```
有关更多信息，请参阅[MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)《*亚马逊 EC2 Auto Scaling API 参考*》。
**注意**
以下是一些其他资源，可以帮助您查找指标名称、命名空间、维度和指标 CloudWatch 统计信息：
有关 AWS 服务的可用指标的信息，请参阅《*亚马逊 CloudWatch 用户指南*》中[发布 CloudWatch 指标的AWS 服务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)。
要使用获取指标的确切指标名称、命名空间和维度（如果适用） AWS CLI，请参阅[列表 CloudWatch ](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/list-metrics.html)指标。
要创建此策略，请使用 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 my-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
```
如果成功，此命令将返回策略的 Amazon 资源名称（ARN）。
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy",
"Alarms": []
}
```
# 使用指标数学表达式
以下部分提供了预测性扩缩策略的信息和示例，这些示例演示了如何在策略中使用指标数学。
**Topics**
+ [了解指标数学](#custom-metrics-metric-math)
+ [使用指标数学组合指标的预测性扩缩策略示例（AWS CLI）](#custom-metrics-ex2)
+ [blue/green 部署场景中使用的预测性扩展策略示例 (AWS CLI)](#custom-metrics-ex3)
## 了解指标数学
如果您只想汇总现有指标数据，那么公 CloudWatch 制数学可以为您节省向其发布另一个指标的工作量和成本 CloudWatch。您可以使用 AWS 提供的任何指标，也可以使用在应用程序中定义的指标。例如，您可能想要计算每个实例的 Amazon SQS 队列积压。您可以从队列中获取用于检索的可用消息的大约数量，然后将该数量除以 Auto Scaling 组的运行容量来实现这一点。
有关更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[使用公制数学](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。
如果您选择在预测性扩展策略中使用指标数学表达式，请考虑以下几点：
+ 指标数学运算使用指标名称、命名空间和维度键/值对指标的唯一组合的数据点。
+ 您可以使用任何算术运算符 (\$1-\$1/^)、统计函数（例如 AVG 或 SUM）或其他支持的函数。 CloudWatch
+ 您可以在数学表达式的公式中同时使用指标和其他数学表达式的结果。
+ 指标数学表达式可以由不同的聚合组成。但是，得到最终聚合结果的最佳实践是针对扩展指标使用 `Average` 以及针对负载指标使用 `Sum`。
+ 指标规范中使用的任何表达式最终都必须返回一个单个时间序列。
要使用指标数学，请执行以下操作：
+ 选择一个或多个 CloudWatch 指标。然后，创建表达式。有关更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[使用公制数学](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。
+ 使用 CloudWatch控制台或 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)API 验证指标数学表达式是否有效。
## 使用指标数学组合指标的预测性扩缩策略示例（AWS CLI）
有时，您可能需要首先以某种方式处理其数据，而不是直接指定指标。例如，您可能有一个从 Amazon SQS 队列中提取工作的应用程序，并且可能希望使用队列中的项目数作为预测性扩展的标准。队列中的消息数不仅仅定义您需要的实例数。因此，需要执行更多工作来创建可用于计算每个实例的积压的指标。有关更多信息，请参阅 [基于 Amazon SQS 的扩缩策略](as-using-sqs-queue.md)。
以下示例是适用于此场景的预测扩展策略示例。它指定了基于 Amazon SQS `ApproximateNumberOfMessagesVisible` 指标的扩展和负载指标，即可从队列中获取的用于检索的消息数量。它还使用 Amazon EC2 Auto Scaling `GroupInServiceInstances` 指标和数学表达式，计算扩展指标的每个实例的积压。
```
aws autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
{
"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": []
}
```
## blue/green 部署场景中使用的预测性扩展策略示例 (AWS CLI)
搜索表达式提供了一个高级选项，您可以在其中查询多个 Auto Scaling 组中的指标并对其执行数学表达式。这对于 blue/green 部署特别有用。
**注意**
*蓝/绿部署*是一种部署方法，您可以在其中创建两个独立但相同的 Auto Scaling 组。只有其中一个组接收生产流量。用户流量最初定向到较早的Auto Scaling 组（“蓝色”），而新组（“绿色”）用于测试和评估应用程序或服务的新版本。测试并接受新部署后，用户流量将转移到“绿色”的 Auto Scaling 组。然后，您可以在部署成功后删除“蓝色”组。
在 blue/green 部署过程中创建新的 Auto Scaling 组时，每个组的指标历史记录可以自动包含在预测性扩展策略中，而无需更改其指标规范。有关更多信息，请参阅 [C AWS ompute 博客上的 “将 EC2 Auto Scaling 预测性扩展策略用于蓝/绿部署](https://aws.amazon.com/blogs/compute/retaining-metrics-across-blue-green-deployment-for-predictive-scaling/)”。
以下示例策略说明了如何执行此操作。在此示例中，策略使用 Amazon EC2 发出的 `CPUUtilization` 指标。它使用 Amazon EC2 Auto Scaling `GroupInServiceInstances` 指标和数学表达式，计算每个实例的扩展指标的值。它还指定了一个容量指标规范来获取 `GroupInServiceInstances` 指标。
根据指定的搜索条件，搜索表达式查找多个 Auto Scaling 组中实例的 `CPUUtilization`。如果您稍后创建了匹配相同搜索条件的新 Auto Scaling 组，则自动包含新 Auto Scaling 组中实例的 `CPUUtilization`。
```
aws autoscaling put-scaling-policy --policy-name my-blue-green-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
{
"MetricSpecifications": [
{
"TargetValue": 25,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_sum",
"Expression": "SUM(SEARCH('{AWS/EC2,AutoScalingGroupName} MetricName=\"CPUUtilization\" ASG-myapp', 'Sum', 300))",
"ReturnData": false
},
{
"Id": "capacity_sum",
"Expression": "SUM(SEARCH('{AWS/AutoScaling,AutoScalingGroupName} MetricName=\"GroupInServiceInstances\" ASG-myapp', 'Average', 300))",
"ReturnData": false
},
{
"Id": "weighted_average",
"Expression": "load_sum / capacity_sum",
"ReturnData": true
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_sum",
"Expression": "SUM(SEARCH('{AWS/EC2,AutoScalingGroupName} MetricName=\"CPUUtilization\" ASG-myapp', 'Sum', 3600))"
}
]
},
"CustomizedCapacityMetricSpecification": {
"MetricDataQueries": [
{
"Id": "capacity_sum",
"Expression": "SUM(SEARCH('{AWS/AutoScaling,AutoScalingGroupName} MetricName=\"GroupInServiceInstances\" ASG-myapp', 'Average', 300))"
}
]
}
}
]
}
```
该示例返回策略的 ARN。
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-blue-green-predictive-scaling-policy",
"Alarms": []
}
```
# 预测性扩展策略中自定义指标的注意事项
如果在使用自定义指标时出现问题，建议您执行以下操作：
+ 如果提供了错误消息，请阅读该消息并解决其报告的问题（如果可能）。
+ 如果您在 blue/green 部署场景中尝试使用搜索表达式时出现问题，请首先确保您了解如何创建搜索表达式来查找部分匹配项而不是完全匹配项。此外，请检查您的查询是否只查找运行特定应用程序的 Auto Scaling 组。有关搜索表达式语法的更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[CloudWatch 搜索表达式语法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html)。
+ 如果您未事先验证表达式，则该[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令会在您创建扩展策略时对其进行验证。但是，此命令有可能无法识别所检测错误的确切原因。要修复这些问题，请对您在[get-metric-data](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/get-metric-data.html)命令请求的响应中收到的错误进行故障排除。您也可以从 CloudWatch 控制台对表达式进行故障排除。
+ 查看控制台中的 **Load** (负载) 和 **Capacity** (容量) 图表时，**Capacity** (容量) 图表可能不显示任何数据。为确保图表具有完整的数据，请确保始终为 Auto Scaling 组启用组指标。有关更多信息，请参阅 [启用 Auto Scaling 组指标（控制台）](ec2-auto-scaling-metrics.md#as-enable-group-metrics)。
+ 只有具备在其生命周期内于不同的 Auto Scaling 组中运行的应用程序时，容量指标规范才适用于蓝色/绿色部署。此自定义指标允许您提供多个 Auto Scaling 组的总容量。预测性扩展使用此功能在控制台中的 **Capacity** (容量) 图表内显示历史数据。
+ 如果 `MetricDataQueries` 自行指定 SEARCH () 函数，而没有像 SUM () 这样的数学函数，则必须为 `ReturnData` 指定 `false`。原因在于搜索表达式可能返回多个时间序列，而基于表达式的指标规范仅可以返回一个时间序列。
+ 搜索表达式中涉及的所有指标均应该具有相同的分辨率。
## 限制
+ 您可以在一个指标规范中查询最多 10 个指标的数据点。
+ 为满足此限制，一个表达式算作一个指标。