基于SQS队列大小的EC2自定义自动扩缩容配置疑问：自定义指标是否推送至CloudWatch？

嗨，我来帮你理清这个问题～

首先明确一点：你配置的这个目标追踪策略里，通过Metric Math计算出来的每实例待处理消息数（也就是表达式e1的结果），默认是不会自动作为独立指标发布到CloudWatch的。这个计算值只是自动扩缩容策略内部用来判断是否触发扩缩容动作的依据，不会直接出现在CloudWatch的指标列表中——这就是你看不到这个自定义指标数据的原因。

至于你遇到的“没有扩缩容动作发生”的问题，可以从这几个方向排查：

• 检查基础指标是否正常上报：
  先确认两个用来计算的原始指标有没有数据：

  • 去CloudWatch的AWS/SQS命名空间下，查看你的my-queue的ApproximateNumberOfMessagesVisible指标，确认队列的消息数在正常上报；
  • 再去AWS/AutoScaling命名空间下，查看你的my-asg的GroupInServiceInstances指标，确认ASG的在服务实例数数据正常。
    如果其中任意一个指标没有数据，那计算出来的e1就会失效，扩缩容自然无法触发。

• 检查扩缩容告警的状态：
  你创建的两个告警（扩缩入、扩缩出）需要进入ALARM状态才会触发扩缩容动作。你可以手动给my-queue发送一批测试消息，看看当m1/m2的结果超过或低于TargetValue=100时，告警是否会切换状态。如果告警一直处于OK状态，说明当前的队列负载和实例数的比例还没达到触发阈值。

• 确认ASG的扩缩容限制：
  检查你的ASG的最小/最大实例数设置，如果当前实例数已经达到最大值，就算触发扩缩出告警也不会有新实例启动；同理，如果已经到最小值，扩缩入告警也不会生效。

如果确实需要把这个“每实例待处理消息数”作为独立指标保存到CloudWatch，你需要额外做一些配置：比如通过Lambda函数定期拉取两个原始指标，计算出结果后上报到自定义的CloudWatch命名空间；或者利用CloudWatch告警的Metric Math功能，配合Lambda动作来推送指标。不过对于自动扩缩容本身来说，这一步不是必须的，只要原始指标正常，策略就能正常工作。

备注：内容来源于stack exchange，提问作者Sunil