企业官网建设流程全解析

AWS CLIautoscaling describe-scaling-activities完全指南：查询 Auto Scaling 伸缩活动与排障

【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli

describe-scaling-activities是 AWS CLI 中用于查询 Auto Scaling 组伸缩活动（Scaling Activity）记录的常用命令。每当实例启动、终止或替换等伸缩事件发生时，Amazon EC2 Auto Scaling 都会生成一条带有状态码、时间戳与原因说明的活动记录，本指南将基于 AWS CLI 仓库中的官方示例文档 awscli/examples/autoscaling/describe-scaling-activities.rst，结合仓库内 service-2.json 与 paginators-1.json 的底层模型定义，为你系统讲解该命令的典型用法、返回字段含义、分页机制与故障排查思路。读完本文，你将能够熟练查询指定伸缩组的活动、追溯已删除组的伸缩历史、按数量与时间范围筛选结果，并借助NextToken完成全量数据遍历。

命令概览与底层模型

describe-scaling-activities对应 EC2 Auto Scaling 服务中的DescribeScalingActivitiesAPI。在仓库的服务模型 service-2.json 中，该操作定义如下要点：

• HTTP 方法：POST，请求 URI 为/（即所有参数都编码进请求体，而不是 URL 路径）；
• 输入结构：DescribeScalingActivitiesType（见 service-2.json#L2726-L2754）；
• 输出结构：ActivitiesType，其中包含Activities活动列表；
• 可能错误：InvalidNextToken（传入的分页令牌无效）与ResourceContentionFault（服务端资源争用导致失败）。

从源码模型看，该操作一次最多返回 100 条活动（MaxRecords的默认值和最大值均为 100），并且只保留最近 6 周内开始的伸缩活动——无论是按ActivityIds精确指定还是按时间过滤，都无法突破这一保留窗口。

示例 1：查询指定伸缩组的所有伸缩活动

最常用的场景是查看某个 Auto Scaling 组的全部伸缩活动，通过--auto-scaling-group-name参数指定组名：

aws autoscaling describe-scaling-activities \ --auto-scaling-group-name my-asg

响应示例（来自 describe-scaling-activities.rst）：

{ "Activities": [ { "ActivityId": "f9f2d65b-f1f2-43e7-b46d-d86756459699", "Description": "Launching a new EC2 instance: i-0d44425630326060f", "AutoScalingGroupName": "my-asg", "Cause": "At 2020-10-30T19:35:51Z a user request update of AutoScalingGroup constraints to min: 0, max: 16, desired: 16 changing the desired capacity from 0 to 16. At 2020-10-30T19:36:07Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 16.", "StartTime": "2020-10-30T19:36:09.766Z", "EndTime": "2020-10-30T19:36:41Z", "StatusCode": "Successful", "Progress": 100, "Details": "{\"Subnet ID\":\"subnet-5ea0c127\",\"Availability Zone\":\"us-west-2b\"}" } ] }

该示例展示了一次由“用户请求将 desired capacity 从 0 调整到 16”触发的扩容活动：Auto Scaling 服务检测到期望容量与实际容量存在差异，于是启动了一个新实例i-0d44425630326060f来补齐容量。通过Cause字段可以完整还原事件触发链，这在排查“为什么自动扩容/缩容了”时非常关键。

关于--auto-scaling-group-name的重要提示：该参数的最大长度为 255 个字符。若省略此参数，命令将对当前账号与区域执行全账号级查询。服务模型 service-2.json#L2733-L2736 明确指出，这种全账号操作可能导致请求变慢甚至超时，因此在实际使用中，只要可能就应优先携带组名。

示例 2：查询已删除伸缩组的活动记录

Auto Scaling 组被删除后，其历史伸缩活动默认不会出现在查询结果中。若要追溯已删除组的活动，只需附加--include-deleted-groups选项：

aws autoscaling describe-scaling-activities \ --auto-scaling-group-name my-asg \ --include-deleted-groups

响应示例：

{ "Activities": [ { "ActivityId": "e1f5de0e-f93e-1417-34ac-092a76fba220", "Description": "Launching a new EC2 instance. Status Reason: Your Spot request price of 0.001 is lower than the minimum required Spot request fulfillment price of 0.0031. Launching EC2 instance failed.", "AutoScalingGroupName": "my-asg", "Cause": "At 2021-01-13T20:47:24Z a user request update of AutoScalingGroup constraints to min: 1, max: 5, desired: 3 changing the desired capacity from 0 to 3. At 2021-01-13T20:47:27Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 3.", "StartTime": "2021-01-13T20:47:30.094Z", "EndTime": "2021-01-13T20:47:30Z", "StatusCode": "Failed", "StatusMessage": "Your Spot request price of 0.001 is lower than the minimum required Spot request fulfillment price of 0.0031. Launching EC2 instance failed.", "Progress": 100, "Details": "{\"Subnet ID\":\"subnet-5ea0c127\",\"Availability Zone\":\"us-west-2b\"}", "AutoScalingGroupState": "Deleted", "AutoScalingGroupARN": "arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:283179a2-f3ce-423d-93f6-66bb518232f7:autoScalingGroupName/my-asg" } ] }

对比示例 1，这条记录有两个显著区别：

1. StatusCode为Failed，且多出了StatusMessage字段。模型 service-2.json#L1186-L1193 中定义：StatusCode表示活动当前状态，StatusMessage提供更详细的失败原因描述。本例的失败原因是“Spot 请求出价 0.001 低于该 Spot 请求履约所需的最低价格 0.0031”，即竞价型实例出价过低导致启动失败。
2. AutoScalingGroupState为Deleted，同时携带AutoScalingGroupARN。这两个字段分别表示伸缩组当前状态（InService或Deleted，见 service-2.json#L1202-L1208）以及该组的 ARN。因此，--include-deleted-groups是删除组之前做“事后审计”的关键手段——你可以在组被删除后依然查明它最后一次伸缩失败的原因。

示例 3：控制返回数量与分页遍历

当活动记录很多时，可用--max-items限制单次返回条数：

aws autoscaling describe-scaling-activities \ --max-items 1

只返回一条活动记录（输出与示例 1 的单条记录结构相同）。注意，CLI 层面的--max-items对应 API 参数MaxRecords，其默认值为 100、最大值也是 100。

如果返回结果中带有NextToken字段，说明还有更多活动尚未返回。此时需要用--starting-token携带该令牌发起后续请求，从而实现分页遍历：

aws autoscaling describe-scaling-activities \ --starting-token Z3M3LMPEXAMPLE

这里的令牌机制在仓库的分页器定义 paginators-1.json#L33-L38 中有完整映射：

"DescribeScalingActivities": { "input_token": "NextToken", "output_token": "NextToken", "limit_key": "MaxRecords", "result_key": "Activities" }

也就是说：请求的NextToken参数（输入令牌）对应响应中的NextToken（输出令牌），条数上限参数为MaxRecords，结果集合位于Activities键下。若你传入的令牌已过期或无效，服务会返回InvalidNextToken错误（见 service-2.json#L546-L549），此时重新发起不带令牌的查询即可。

实用提示：除了手工处理--starting-token，更推荐直接依赖 AWS CLI 的自动分页能力——在命令中追加--output json之外再加--page-size与全局参数--no-cli-pager，或直接省略令牌参数让 CLI 自动翻页。日常脚本中最稳妥的写法是结合--query与--output text提取关键字段（如ActivityId、StatusCode、StartTime），例如：

aws autoscaling describe-scaling-activities \ --auto-scaling-group-name my-asg \ --query "Activities[*].[ActivityId,StatusCode,StartTime]" \ --output text

完整输入参数速查

根据输入结构 service-2.json#L2726-L2754 的定义，该命令支持的参数与约束如下：

其中Filters的约束值得注意：

• StartTimeLowerBound/StartTimeUpperBound分别限定活动开始时间的最早与最晚边界，接受 ISO 8601 时间戳（如2000-01-18T08:15:00Z或2000-01-18T16:15:00+08:00），未带时区偏移的视为 UTC；同样受“仅保留 6 周内活动”的限制；
• Status过滤器按StatusCode筛选，只能与AutoScalingGroupName参数组合使用，单独使用无效。

返回字段详解与状态码枚举

每条活动记录对应模型中的Activity结构（见 service-2.json#L1152-L1211），必填字段为ActivityId、AutoScalingGroupName、Cause、StartTime与StatusCode，其余字段按情况出现：

StatusCode的完整取值定义在 service-2.json#L5389-L5408 的ScalingActivityStatusCode枚举中，共 16 种，按生命周期大致分为：

• 启动阶段：PendingSpotBidPlacement、WaitingForSpotInstanceRequestId、WaitingForSpotInstanceId、WaitingForInstanceId、PreInService；
• 进行中阶段：InProgress、InPlaceUpdateInProgress、WaitingForELBConnectionDraining、WaitingForConnectionDraining、MidLifecycleAction、WaitingForInstanceWarmup、WaitingForInPlaceUpdateToStart、WaitingForInPlaceUpdateToFinalize；
• 终态：Successful、Failed、Cancelled。

正如操作文档（service-2.json#L550）所述：伸缩事件成功时StatusCode为Successful；若启动实例失败，StatusCode为Failed或Cancelled，且StatusMessage会指出失败原因。因此，快速定位伸缩异常的最佳实践是：按Failed或Cancelled状态过滤活动记录，再读取StatusMessage与Cause结合分析。

典型排障工作流

综合以上内容，当你的 Auto Scaling 组出现“该扩没扩”“该缩没缩”或实例启动失败时，可以按如下流程排查：

1. 限定范围：使用--auto-scaling-group-name只查询目标组，避免全账号慢查询；
2. 查看失败活动：结合--filters与Status过滤器（配合组名使用）筛选出Failed或Cancelled的活动，读取StatusMessage——常见的失败原因包括 Spot 出价过低、子网/可用区资源不足、AMI 或启动模板配置错误等；
3. 理解触发原因：阅读Cause字段还原触发链路（例如“desired capacity 从 0 调整到 16”是由用户请求还是扩缩容策略触发）；
4. 核对详情：解析Details字段中的子网与可用区信息，确认实例被调度到哪个可用区；
5. 分页拉全数据：活动较多时用--max-items控制批次，用--starting-token继续翻页，直到响应中不再出现NextToken；
6. 追溯已删组：若需要审计已被删除的组，加上--include-deleted-groups，并通过AutoScalingGroupState与AutoScalingGroupARN确认记录归属。

仓库中还有大量相关示例可供组合参考，例如 set-desired-capacity.rst（手动调整期望容量以触发伸缩活动）、describe-auto-scaling-groups.rst（查看组当前状态与容量）以及 terminate-instance-in-auto-scaling-group.rst（终止组内实例以触发替换活动），将它们与describe-scaling-activities搭配使用，可以完整覆盖“变更 → 观察活动 → 定位问题”的日常运维闭环。

【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli