我已经在负载均衡器后面的亚马逊上运行了两个相同的中型CPU实例几个月。我注意到负载均衡器习惯在相当规律的基础上声明一个不健康的实例，将实例关闭并替换为定义的AMI的新实例。
从技术上讲，这是正确的做法，我只是不明白为什么它认为实例有时是不健康的。我在过去3天内一直在监视健康检查端口，并且在使用两个实例的公共DNS时，每60秒检查一直有效。在此期间，负载均衡器已声明实例不健康3次并替换它。这些实例因我需要而有目的地大量制服，因此我可以将其排除在问题之外。
使用ELB架构，我知道这在技术上并不重要，但不健康的比率从每周一次变为每天一次以上。旋转的每个实例都需要额外花费一小时的实例成本。如果情况变得更糟，成本将变得非常重要，但更重要的是，它并没有让我相信ELB的内部。
这与this one不是同一个问题，我的偶然失败。有关信息，我正在使用欧盟/爱尔兰数据中心，我的不健康标准是我的端口（8080）在5分钟内出现10次故障（这比我真正想设置的时间长，我不想要进入实例的流量未能在5分钟内得到响应。）
我知道有人建议联系亚马逊，但是我没有支持合同，任何试过这个的人知道我会得到的答案，如果我得到一个答案。我真的很喜欢这个东西的想法，它对我来说似乎并不稳定。
答案 0 :(得分：1)
使实例处于不健康状态的唯一原因是健康检查失败。确保您的应用程序没有负载峰值，使用nagios，cacti，monit等一些第三方工具监控性能，并在此峰值期间检查系统。