几个月来，我一直在 Amazon 上的负载均衡器后面运行两个相同的中型 CPU 实例。我注意到负载均衡器有一个习惯，即定期声明实例不健康，将实例关闭并替换为已定义 AMI 的新实例。
从技术上讲，这是正确的做法，我只是不明白为什么它偶尔会认为实例不健康。在过去 3 天里，我一直在监视运行状况检查端口，并且在使用两个实例的公共(public) DNS 时每 60 秒检查一次。负载均衡器在此期间已 3 次声明实例运行状况不佳并替换了它。这些实例有目的地为我所需要的东西提供了强大的支持，所以我可以排除这个问题。
对于 ELB 架构，我知道这在技术上并不重要，但不健康的比率已经从每周 1 次上升到每天 1 次以上。启动的每个实例都要花费我一个小时的实例成本。如果情况变得更糟，成本将变得非常重要，但更重要的是，它不会让我对 ELB 内部结构产生信心。
这与 this one 不同，我的问题是偶尔失败。有关信息，我正在使用欧盟/爱尔兰数据中心，我的不健康标准是我的端口 (8080) 在 5 分钟内出现 10 次故障(这比我真正想设置的时间长，我不想要流向实例的流量在 5 分钟内未能获得响应)。
我知道有人会建议联系亚马逊，但我没有支持契约(Contract)，任何尝试过这个的人都知道我会得到什么样的答案，如果我得到一个答案。我真的很喜欢这个东西的想法，它对我来说似乎不太稳定。
最佳答案
实例处于不健康状态的唯一原因是健康检查失败。确保您的应用程序没有负载峰值，使用一些第三方工具(如 nagios、cacti、monit)监控性能并在此峰值期间检查系统。
关于amazon-ec2 - 亚马逊负载均衡器稳定运行的标准是什么？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/8473184/