本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # Application Auto Scaling 的预测扩展 预测性扩展可以主动扩展您的应用程序。预测性扩展可分析历史负载数据，以检测流量中的每日或每周模式。它使用这些信息来预测未来的容量需求，以主动增加应用程序的容量以匹配预期的负载。 预测式扩展非常适合以下情况： + 周期性流量，例如正常营业时间内的高资源利用率以及晚上和周末的低资源利用率 + 重复 on-and-off的工作负载模式，例如批处理、测试或定期数据分析。 + 初始化需要很长时间的应用程序，从而在向外扩展事件期间对应用程序性能造成明显的延迟影响 **Topics** + [工作原理](aas-predictive-scaling-how-it-works.md) + [创建预测性扩展策略](aas-create-predictive-scaling-policy.md) + [覆盖预测](aas-predictive-scaling-overriding-forecast-capacity.md) + [使用自定义指标](aas-predictive-scaling-customized-metric-specification.md) # Application Auto Scaling 预测缩放的工作原理 要使用预测扩展，请创建预测性扩展策略，指定要监控和分析的 CloudWatch 指标。您可以使用预定义的指标或自定义的指标。要使预测性扩展开始预测未来值，此指标必须包含至少 24 小时的数据。 创建策略后，预测性扩展将开始分析最多过去 14 天的指标数据，以确定模式。其使用此分析生成未来 48 小时容量需求的每小时预测。使用最新 CloudWatch 数据，预测每 6 小时更新一次。随着新数据的出现，预测性扩展能够不断提高未来预测的准确性。 您可以先在 “*仅限预测*” 模式下启用预测缩放。在此模式下，它会生成容量预测，但实际上不会根据这些预测扩展容量。这使您可以评估预测的准确性和适用性。 查看预测数据并决定根据该数据开始扩展后，将扩展策略切换到预测和扩展模式。在此模式中： + 如果预测预计负载会增加，则预测性扩展将增加容量。 + 如果预测预计负载会减少，则预测性扩展不会缩减以减少容量。这样可以确保只有在需求实际下降时才缩减规模，而不仅仅是根据预测。要移除不再需要的容量，您必须创建目标跟踪或步进扩展策略，因为它们会响应实时指标数据。 默认情况下，预测性扩展会根据该小时的预测在每小时开始时缩放您的可扩展目标。您可以选择在 `PutScalingPolicy` API 操作中使用`SchedulingBufferTime`属性来指定更早的开始时间。这使您能够在预测的需求之前启动预测的容量，从而使新容量有足够的时间准备好处理流量。 ## 最大容量限制 默认情况下，设置扩缩策略后，这些策略无法将容量增加到高于最大容量。 或者，如果预测容量接近或超过可扩展目标的最大容量，则可以允许自动增加可扩展目标的最大容量。要启用此行为，请使用 `PutScalingPolicy` API 操作中的 `MaxCapacityBreachBehavior` 和 `MaxCapacityBuffer` 属性或 AWS 管理控制台中的**最大容量行为**设置。 **警告** 允许自动增加最大容量时应谨慎行事。最大容量不会自动降回到原来的最大值。 ## 扩缩策略创建、管理和删除的常用命令 使用预测性扩展策略的常用命令包括： + `register-scalable-target`将资源注册 AWS 或自定义为可扩展目标、暂停扩展和恢复扩展。 + `put-scaling-policy`以创建预测性扩展策略。 + `get-predictive-scaling-forecast`检索预测性扩展策略的预测数据。 + `describe-scaling-activities`返回有关中扩展活动的信息 AWS 区域。 + `describe-scaling-policies`以返回有关扩展策略的信息 AWS 区域。 + `delete-scaling-policy`删除扩展策略。 **自定义指标** 自定义指标可用于预测应用程序所需的容量。当预定义的指标不足以捕获应用程序的负载时，自定义指标很有用。 ## 注意事项 使用预测性缩放时，需要考虑以下注意事项。 + 确认预测性扩展是否适合您的应用程序。如果应用程序表现出特定于一周中的某一天或一天中的时间的重复负载模式，则该应用程序非常适合预测性扩展。在让预测性扩展主动扩展您的应用程序之前，先评估预测。 + 预测式扩展至少需要 24 小时的历史数据才能开始预测。但是，如果历史数据跨越整整两周，预测会更有效。 + 选择一个负载指标，该指标应准确代表应用程序的全部负载，并且是应用程序中对扩缩最重要的方面。 # 为 Application Auto Scaling 创建预测性扩展策略 以下示例策略使用 AWS CLI 为 Amazon ECS 服务配置预测性扩展策略。将每个 *user input placeholder* 替换为您自己的信息。 有关您可以指定的 CloudWatch 指标的更多信息，请参阅[PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)《*Amazon EC2 Auto Scaling API 参考*》。 以下是具有预定义内存配置的策略的示例。 ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 40, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceMemoryUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` 以下示例说明了通过使用指定配置文件运行[put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)命令来创建策略。 ``` aws aas put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` 如果成功，该命令会返回策略的 ARN。 ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` # 使用计划操作覆盖预测值 有时，您可能会获得有关未来应用程序需求的其他信息，预测计算无法考虑这些信息。例如，预测计算可能会低估即将举行的市场营销活动所需的容量。您可以使用计划操作在未来时段内临时覆盖预测。计划操作可以循环运行，也可以在出现一次性需求波动的特定日期和时间运行。 例如，您可以创建具有高于预测容量的最小容量的计划操作。在运行时，Application Auto Scaling 会更新可扩展目标的最小容量。由于预测式扩展可针对容量进行优化，因此执行最小容量高于预测值的计划操作。这样可以防止容量低于预期。要停止覆盖预测，请使用第二个计划操作将最小容量恢复到其原始设置。 以下过程概述了在将来期间覆盖预测的步骤。 **Topics** + [步骤 1：（可选）分析时间序列数据](#analyzing-time-series-data) + [步骤 2：创建两个计划操作](#scheduling-capacity) **重要** 本主题假设您尝试覆盖预测，以扩展到比预测更高的容量。如果您需要在不受预测性扩展策略干扰的情况下暂时减少容量，则请改用*仅预测*模式。在仅预测模式下，预测性扩展将继续生成预测，但不会自动增加容量。然后，您可以监控资源利用率，并根据需要手动缩减组大小。 ## 步骤 1：（可选）分析时间序列数据 首先分析预测时间序列数据。这是一个可选步骤，但如果您想了解预测的详细信息，它会很有帮助。 1. **检索预测** 创建预测后，您可以查询预测中的特定时间段。查询的目的是获得特定时间段的时间序列数据的完整视图。 您的查询最多可以包含两天的未来预测数据。如果您已经使用了一段时间预测式扩展，您还可以访问过去的预测数据。但是，开始和结束时间之间的最长持续时间为 30 天。 要检索预测，请使用[get-predictive-scaling-forecast](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/application-autoscaling/get-predictive-scaling-forecast.html)命令。以下示例获取了 Amazon ECS 服务的预测性扩展预测。 ``` aws application-autoscaling get-predictive-scaling-forecast --service-namespace ecs \ --scalable-dimension ecs:service:DesiredCount \ --resource-id 1234567890abcdef0 --policy-name predictive-scaling-policy \ --start-time "2021-05-19T17:00:00Z" \ --end-time "2021-05-19T23:00:00Z" ``` 响应包括两个预测：`LoadForecast`和`CapacityForecast`。 `LoadForecast`显示每小时负荷预测。 `CapacityForecast`显示按小时计算的容量的预测值，以便在保持指定`TargetValue`负载的同时处理预测的负载。 1. **确定目标时间段** 确定应发生一次性需求波动的小时数。请记住，预测中显示的日期和时间以 UTC 为单位。 ## 步骤 2：创建两个计划操作 接下来，在应用程序的负载高于预测负载的特定时间段内创建两个计划操作。例如，如果您的营销活动会在有限时间段内使网站的流量增加，则可计划一个一次性操作以在其启动时更新最小容量。然后，安排另一个操作，以便在事件结束时将最小容量返回到原始设置。 **为一次性事件创建两个计划操作（AWS CLI）** 要创建计划操作，请使用[ put-scheduled-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/application-autoscaling/put-scheduled-action.html)命令。 以下示例定义了 Amazon EC2 Auto Scaling 的计划，该计划在 5 月 19 日下午 5:00 将至少三个实例的容量保持为八小时。以下命令显示如何实现此方案。 第一个[put-scheduled-update-group操作](https://docs.aws.amazon.com/cli/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 ``` # 使用自定义指标的高级预测性扩展策略 在预测性扩展策略中，您可以使用预定义指标或自定义指标。当预定义的指标不能充分描述您的应用程序负载时，自定义指标会很有用。 使用自定义指标创建预测性扩展策略时，您可以指定由提供的其他 CloudWatch 指标 AWS，也可以指定自己定义和发布的指标。您还可以使用公制数学来汇总现有指标并将其转换为 AWS 不会自动跟踪的新时间序列。例如，通过计算新的总和或平均值来组合数据中的值时，该操作称为*执行聚合*。生成的数据称为*聚合*。 以下部分包含了有关如何为构造策略的 JSON 结构的最佳实践和示例。 **Topics** + [最佳实践](#custom-metrics-best-practices) + [先决条件](#custom-metrics-prerequisites) + [构造自定义指标的 JSON](construct-json-custom-metrics.md) + [预测性扩展策略中自定义指标的注意事项](custom-metrics-troubleshooting.md) ## 最佳实践 以下最佳实践可帮助您更有效地使用自定义指标： + 对于负载指标规范，最有用的指标是表示应用程序负载的指标。 + 扩展指标必须与容量成反比。也就是说，如果可扩展目标增加，则扩展指标的减少比例应大致相同。为确保预测性扩展按预期采取行动，负载指标和扩展指标还必须彼此之间密切关联。 + 目标利用率必须与扩展指标的类型匹配。对于使用 CPU 利用率的策略配置，这是目标百分比。对于使用吞吐量（例如请求数或消息数）的策略配置，这是在任何一分钟间隔内每个实例的目标请求数或目标消息数。 + 如果未遵循这些建议，那么时间序列的预测未来值可能会不正确。要验证数据是否正确，您可以查看预测值。或者，在创建预测性扩展策略后，检查调用 [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html)API 返回的`LoadForecast`和`CapacityForecast`对象。 + 我们强烈建议您在仅预测模式下配置预测式扩展，以便在预测式扩展开始主动扩展容量之前对预测进行评估。 ## 先决条件 要将自定义指标添加到预测性扩缩策略，您必须具有 `cloudwatch:GetMetricData` 权限。 要指定您自己的指标而不是 AWS 提供的指标，您必须先将指标发布到 CloudWatch。有关更多信息，请参阅《*Amazon CloudWatch 用户指南*》中的[发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。 如果发布自己的指标，请确保以至少五分钟的频率发布数据点。Application Auto Scaling CloudWatch 根据所需的周期长度从中检索数据点。例如，负载指标规范使用每小时指标来衡量应用程序的负载。 CloudWatch 使用您发布的指标数据，通过将所有数据点与每个一小时内的时间戳聚合在一起，为任何一小时的时间段提供单个数据值。 # 构造自定义指标的 JSON 以下部分包含有关如何配置预测扩展以查询 Amazon EC2 Auto Scaling 数据的示例。 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://docs.aws.amazon.com/cli/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) + [Amazon EC2 Auto Scaling 的预测性扩展策略示例，该策略使用公制数学组合指标 (AWS CLI)](#custom-metrics-ex2) + [blue/green 部署场景中使用的预测性扩展策略示例 (AWS CLI)](#custom-metrics-ex3) ## 了解指标数学 如果您只想汇总现有指标数据，那么公 CloudWatch 制数学可以为您节省向其发布另一个指标的工作量和成本 CloudWatch。您可以使用 AWS 提供的任何指标，也可以使用在应用程序中定义的指标。 有关更多信息，请参阅 *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 验证指标数学表达式是否有效。 ## Amazon EC2 Auto Scaling 的预测性扩展策略示例，该策略使用公制数学组合指标 (AWS CLI) 有时，您可能需要首先以某种方式处理其数据，而不是直接指定指标。例如，您可能有一个从 Amazon SQS 队列中提取工作的应用程序，并且可能希望使用队列中的项目数作为预测性扩展的标准。队列中的消息数不仅仅定义您需要的实例数。因此，需要执行更多工作来创建可用于计算每个实例的积压的指标。 以下示例是适用于此场景的预测扩展策略示例。它指定了基于 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": [] } ``` # 预测性扩展策略中自定义指标的注意事项 如果在使用自定义指标时出现问题，建议您执行以下操作： + 如果提供了错误消息，请阅读该消息并解决其报告的问题（如果可能）。 + 如果您未事先验证表达式，则该[ put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/application-autoscaling/put-scaling-policy.html)命令会在您创建扩展策略时对其进行验证。但是，此命令有可能无法识别所检测错误的确切原因。要修复这些问题，请对您在[get-metric-data](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/get-metric-data.html)命令请求的响应中收到的错误进行故障排除。您也可以从 CloudWatch 控制台对表达式进行故障排除。 + 如果 `MetricDataQueries` 自行指定 SEARCH() 函数，而没有像 SUM() 这样的数学函数，则必须为 `ReturnData` 指定 `false`。原因在于搜索表达式可能返回多个时间序列，而基于表达式的指标规范仅可以返回一个时间序列。 + 搜索表达式中涉及的所有指标均应该具有相同的分辨率。 **限制** 适用以下限制： + 您可以在一个指标规范中查询最多 10 个指标的数据点。 + 为满足此限制，一个表达式算作一个指标。