我们已经使用 web 和 worker 类(多个集群)为 AWS beanstalk 设置了一个不可变的配置。当我们部署一个新应用程序时,它会创建一个临时的自动缩放组,然后部署到该组,最后切换回旧的自动缩放组。这个过程大约需要 20-30 分钟并且工作正常。
虽然,每次我们部署应用程序时,监控统计信息:CPU 利用率、内存利用率、磁盘空间等都会消失 5-6 小时,然后再返回。似乎是 AWS 问题,但不确定我们是否做错了什么。有没有其他人经历过这种行为?有解决方法吗?
我们已经使用 web 和 worker 类(多个集群)为 AWS beanstalk 设置了一个不可变的配置。当我们部署一个新应用程序时,它会创建一个临时的自动缩放组,然后部署到该组,最后切换回旧的自动缩放组。这个过程大约需要 20-30 分钟并且工作正常。
虽然,每次我们部署应用程序时,监控统计信息:CPU 利用率、内存利用率、磁盘空间等都会消失 5-6 小时,然后再返回。似乎是 AWS 问题,但不确定我们是否做错了什么。有没有其他人经历过这种行为?有解决方法吗?
我尝试通过检查CPUUtilization
.
在不可变部署之后,我观察到了一个小间隙(10 分钟)。这远非5-6小时。
观察到的延迟仅在 EB 控制台中。相应的 CloudWatch (CW) 指标没有延迟。CPUUtilization
因此,我可以在等待 EB 控制台赶上时监控CW 中的内容。
对于我的测试,我执行了两个不可变部署。在 CW 中,指标与部署创建的新实例很好地对齐(没有任何间隙):
您的实例的指标在 CW 中也应该是可行的。因此,当 EB 控制台赶上时,您应该能够在那里查看它们。
要获得所有单个指标的统一视图,可以使用指标数学:
AVG(METRICS())
对于将来发现此问题的任何人-我发现了这个问题。我使用的脚本由 Cloudwatch 提供,它在内部缓存自动缩放组名称 6 小时。通常这不是问题,因为这些值不会定期更改。但是由于不可变部署,在部署期间会创建一个临时自动缩放组,该组会缓存 6 小时。
为了解决这个问题,我替换了 CloudWatchClient 代码中的以下行:
$meta_data_short_ttl = 21600; # 6 hours
和:
meta_data_short_ttl = 600; # 10 mins
.ebextension
如果您使用此脚本,也可以通过更改现有代码来完成:
04-reduce-cache:
command: sed -i 's/meta_data_short_ttl = 21600; # 6 hours/meta_data_short_ttl = 600; # 10 mins/g' /opt/cloudwatch/aws-scripts-mon/CloudWatchClient.pm