AWS CLIautoscaling describe-scaling-activities完全指南查询 Auto Scaling 伸缩活动与排障【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-clidescribe-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这条记录有两个显著区别StatusCode为Failed且多出了StatusMessage字段。模型 service-2.json#L1186-L1193 中定义StatusCode表示活动当前状态StatusMessage提供更详细的失败原因描述。本例的失败原因是“Spot 请求出价 0.001 低于该 Spot 请求履约所需的最低价格 0.0031”即竞价型实例出价过低导致启动失败。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 的定义该命令支持的参数与约束如下参数CLI 选项说明与约束ActivityIds--activity-ids指定活动 ID 列表最多 50 个未知 ID 会被静默忽略不报错。仅能返回最近 6 周内开始的活动AutoScalingGroupName--auto-scaling-group-name伸缩组名称最大 255 字符。省略该参数将进行全账号查询可能变慢或超时IncludeDeletedGroups--include-deleted-groups布尔值是否包含已删除伸缩组的活动MaxRecords--max-items单次最大返回条数默认 100最大 100NextToken--starting-token上一次调用返回的分页令牌用于获取后续数据Filters--filters过滤条件列表支持StartTimeLowerBound、StartTimeUpperBound、Status三类过滤器其中Filters的约束值得注意StartTimeLowerBound/StartTimeUpperBound分别限定活动开始时间的最早与最晚边界接受 ISO 8601 时间戳如2000-01-18T08:15:00Z或2000-01-18T16:15:0008:00未带时区偏移的视为 UTC同样受“仅保留 6 周内活动”的限制Status过滤器按StatusCode筛选只能与AutoScalingGroupName参数组合使用单独使用无效。返回字段详解与状态码枚举每条活动记录对应模型中的Activity结构见 service-2.json#L1152-L1211必填字段为ActivityId、AutoScalingGroupName、Cause、StartTime与StatusCode其余字段按情况出现字段含义ActivityId活动唯一 IDAutoScalingGroupName所属伸缩组名称Description活动的可读描述如“正在启动实例 i-xxxx”Cause活动发起的原因通常完整记录了触发伸缩的配置变更过程StartTime/EndTime活动的开始/结束时间ISO 8601StatusCode当前状态取值见下方枚举StatusMessage失败时的详细原因说明Progress0100 的进度值100 表示活动已完成Details活动详情通常为 JSON 字符串如子网 ID、可用区AutoScalingGroupState伸缩组状态InService或DeletedAutoScalingGroupARN伸缩组的 ARNStatusCode的完整取值定义在 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 组出现“该扩没扩”“该缩没缩”或实例启动失败时可以按如下流程排查限定范围使用--auto-scaling-group-name只查询目标组避免全账号慢查询查看失败活动结合--filters与Status过滤器配合组名使用筛选出Failed或Cancelled的活动读取StatusMessage——常见的失败原因包括 Spot 出价过低、子网/可用区资源不足、AMI 或启动模板配置错误等理解触发原因阅读Cause字段还原触发链路例如“desired capacity 从 0 调整到 16”是由用户请求还是扩缩容策略触发核对详情解析Details字段中的子网与可用区信息确认实例被调度到哪个可用区分页拉全数据活动较多时用--max-items控制批次用--starting-token继续翻页直到响应中不再出现NextToken追溯已删组若需要审计已被删除的组加上--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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考