ECS容量提供程序（Capacity Provider）未按需扩容排查求助

1. 核对Capacity Provider核心配置与扩容触发逻辑 #

• 确认目标容量值（Target Capacity）：若为百分比模式，计算集群已分配的任务预留内存总和与总可用预留内存的比例，是否真的达到了扩容阈值。注意ECS是基于任务预留内存而非实际使用量计算容量的。
• 检查扩容冷却时间：若近期刚触发过扩容，冷却时间内不会再次执行扩容操作，确认冷却时长是否设置过长导致无法及时响应调度需求。
• 验证容量提供者权重：如果集群关联多个Capacity Provider，权重会影响扩容优先级，确保当前ASG对应的CP权重配置正确，未被其他CP抢占扩容机会。

2. 排查ASG的扩容限制与配置冲突 #

• 检查ASG最大实例数上限：确认是否已达到ASG设置的Max Size，导致无法继续扩容。
• 验证ASG启动模板/配置：确认模板中的实例类型是否匹配ECS任务的资源需求，若任务需要大内存实例但ASG模板是小规格实例，即使扩容也无法调度任务，CP可能因此不触发扩容。
• 核对ASG扩容策略：查看ASG自动生成的CloudWatch告警策略（由Capacity Provider创建），确认触发扩容的指标（如ECSServiceAverageMemoryUtilization）阈值是否合理，是否存在手动修改导致的逻辑冲突。
• 检查ASG权限与配额：确认ASG关联的IAM角色有足够权限创建EC2实例，同时排查EC2实例配额、子网IP配额、安全组规则等是否限制了实例创建。

3. 分析ECS集群调度细节与任务约束 #

• 查看任务调度失败事件：在ECS控制台的事件页面，找到具体的调度失败原因，区分是实例数量不足，还是现有实例的资源/标签/端口等约束无法满足任务需求。
• 验证binpack放置策略的实际影响：binpack会尽量将任务打包到现有实例，需确认当前所有实例的预留内存是否已接近上限，且集群确实存在容量缺口，而非单个实例资源耗尽但集群仍有剩余容量。
• 检查任务的额外约束：除内存预留外，任务是否有GPU需求、特定实例标签、端口占用等限制，导致即使扩容实例也无法满足调度条件，CP因此判断无需扩容。
• 确认CP与集群的关联状态：在ECS控制台检查Capacity Provider是否处于ACTIVE状态，且已正确关联集群，同时确认Managed scaling已开启。

4. 查看日志与指标定位问题 #

• 查看Capacity Provider的CloudWatch指标：重点关注CapacityProviderReservation、CapacityProviderTargetCapacity，确认这些指标是否显示集群已达到扩容阈值。
• 检查ASG活动历史：在EC2控制台的ASG页面查看活动记录，是否有扩容请求被拒绝的记录，以及具体拒绝原因（如配额不足、启动模板错误）。
• 查看ECS代理日志：登录现有ECS实例，检查/var/log/ecs/ecs-agent.log，确认实例是否正确向集群上报资源状态，是否存在资源上报延迟或错误。

5. 验证Managed Scaling的精细配置 #

• 确认Managed scaling是否开启：Capacity Provider的该选项必须设为ENABLED，否则不会自动触发ASG扩容。
• 检查扩容步长设置：若Minimum Scaling Step Size设置过大，可能导致CP判断当前容量缺口不需要扩容（比如仅需1台实例但最小步长是3台，且ASG已接近最大实例数）。
• 核对目标容量类型：若为PERCENT模式，确认百分比计算逻辑是否符合预期；若为TARGET_TRACKING模式，检查跟踪的指标是否匹配实际调度需求。

内容的提问来源于stack exchange，提问作者Andrea