我们已经在亚马逊 AWS 基础设施上运行了几个网站大约两年了，大约两天前，网络服务器开始每天停机一两次，我发现的唯一错误是：
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
CloudWatch 不会触发任何警报（CPU/磁盘 IO/DB Conn）。我尝试通过弹性 IP 访问该站点以跳过 ELB 并得到以下信息：
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.
我在 apache 日志中没有看到任何异常，并确认它们被正确轮换。当我通过 SSH“关闭”并查看进程列表时，我没有问题访问机器，我看到 151 个 apache2 进程对我来说是正常的。重新启动 apache 暂时解决了这个问题。这台机器仅作为 ELB 后面的网络服务器运行。任何建议将不胜感激。
CPU 利用率平均值：7.45%，最小值：0.00%，最大值：25.82%
内存利用率平均值：11.04%，最小值：8.76%，最大值：13.84%
掉期利用率平均值：N/A，最小值：N/A，最大值：N/A
/dev/xvda1 的磁盘空间利用率/平均值：62.18%，最小值：53.39%，最大值：65.49%
让我澄清一下，我认为问题在于单个 EC2 实例而不是 ELB，即使我无法访问弹性 IP，我也不想排除这一点。我怀疑 ELB 只是返回命中实际 EC2 实例的结果。
更新：2014-08-26 我应该早点更新这个，但“修复”是拍摄“坏”实例的快照并启动生成的 AMI。从那以后它就没有下降过。当我仍然遇到问题时，我确实查看了运行状况检查，curl http://localhost/page.html即使我从负载均衡器中收到容量问题，也可以进入运行状况检查页面 ( )。我不相信这是一个健康检查问题，但由于没有人，包括亚马逊，可以提供更好的答案，我将其标记为答案。谢谢你。
更新：2015-05-06 我以为我会回到这里并说我现在坚信的问题的一部分是健康检查设置。我不想排除它们是 AMI 的问题，因为在替换 AMI 启动后它肯定会变得更好，但我发现我们的运行状况检查对每个负载均衡器都是不同的，并且是最麻烦的那个有一个非常激进的不健康阈值和响应超时。我们的流量往往不可预测地激增，我认为在激进的健康检查设置和流量高峰之间，这是一场完美的风暴。