什么可能导致 EC2 实例无法添加到 Elastic Load Balancer/运行状况检查失败？答案

【问题标题】：What could cause an EC2 instance to fail to be added to an Elastic Load Balancer/fail the Health Check?什么可能导致 EC2 实例无法添加到 Elastic Load Balancer/运行状况检查失败？
【发布时间】：2016-10-11 11:53:12
【问题描述】：

我会尽我所能提供一个 MCVE，而不会让你沉浸在细节中。

我最近启动了两个 EC2 实例来充当 Tomcat，它们是作为现有实例的克隆启动的。我还创建了一个弹性负载均衡器 (ELB) 来放置在这些 Tomcat 实例的前面，以管理对我的 Web 应用程序的请求。据我所知，这两个 EC2 实例基本相同。他们都共享一个安全组，监听 8080 端口等。

当我将实例添加到 ELB 时，一个成功，一个没有。显示的错误是：

Instance has failed at least the UnhealthyThreshold number of HealthChecks consecutively.

在 EC2 实例列表中，两个 Tomcat 的个人运行状况报告都很好，我可以通过 ssh 访问它们。我已经确认 Tomcat 服务正在两者上运行，并且 netstat -alnt 显示两者都在监听 8080 端口。重新启动问题实例并将其重新添加到 ELB 并没有帮助。

以下是适用于这两个实例的运行状况检查设置：

Ping Target HTTP:8080/
Timeout      5 seconds
Interval    30 seconds
Unhealthy threshold 5
Healthy threshold   10

延长超时时间似乎没有帮助。我确信一定有一些微妙的设置/差异阻止了 ELB 发现问题实例，但我已经用谷歌搜索过，对于我的具体案例的任何建议都没有成功。

如果有任何其他信息对诊断问题有用，请告诉我。

【问题讨论】：

是否有相同的安全grp？是否有任何实例级防火墙正在运行？您可以直接从另一个实例中访问 heathcheck 端点吗？
在 ELB 中将“Ping Target HTTP:8080/”更改为“Ping Target TCP:8080/”，或者简而言之，使用 TCP 协议而不是 HTTP 它将起作用
@error2007s 哇，成功了！我很好奇，为什么使用 HTTP 会导致一个被接受而不是另一个？根本原因是什么？无论如何，如果您发表评论作为答案，我很乐意接受！

标签： tomcat amazon-web-services amazon-ec2 load-balancing

【解决方案1】：

在 ELB 中将 "Ping Target HTTP:8080/" 更改为 "Ping Target TCP:8080/" 或简而言之使用 TCP 协议而不是 HTTP 它将起作用。

如果您使用 HTTP 方法，请务必提及“/test.html”之类的测试文件，而不仅仅是“/”。

在此处为我的问题添加更多信息。

运行状况检查的工作原理是通过 ping 端口和 ping 路径 [1] 向实例发出 HTTP 或 HTTPS GET 请求。如果负载均衡器在响应超时时间内收到“200 OK”以外的任何响应，则认为该实例不健康。对于仅包含 '/' 路径的请求，由您的网络服务器处理所谓的“尾部斜杠”重定向。例如，Apache 会将尾部斜杠重定向到其 DirectoryIndex 指令 [2] 指定的资源。

文件： [1]http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-healthchecks.html [2]https://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryindex

【讨论】：

很抱歉，但 -1 表示危险建议。您现在可能已将一个实际上不健康的实例声明为健康实例——例如，如果它因为无法连接到数据库以呈现GET / 的响应而未能通过健康检查怎么办？几乎可以肯定，这种变化将掩盖的潜在问题。 “如果您使用 HTTP 方法，请务必提及“/test.html”之类的测试文件，而不仅仅是“/”。” 过于宽泛。如果实例的“健康状况”应根据其执行更复杂操作的能力来确定，您不想测试静态文件。
@Michael-sqlbot 这不是一个危险的建议，这是正确的建议。如果此人不打算使用“test.html”，他应该始终使用 TCP Ping 协议连接端口。当 ELB 使用 HTTP Ping 协议进行运行状况检查时，它只会查找“HTTP 200”，它并不关心 EC2 实例是否连接到数据库，所以如果我们保留路径“/”，有时 Web 服务器会给出“ HTTP 200”（99% 的时间实例由于“/”而无法通过健康检查，并且它会将健康实例标记为不健康）。
@Michael-sqlbot 添加文件可确保 ELB 定期获取“HTTP 200”，用户不必担心 ELB 和 EC2 实例之间的连接。因此，以防万一自动缩放组由于应用程序流量过大而启动 4-5 个实例，并且如果用户在路径中使用“/”而不是“test.html”，并且只有一个通过测试（如上述情况），其他实例被标记为不健康，并且整个流量仅定向到一个实例，这将使整个应用程序停机。
确保 ELB 定期获得 200 OK 是错误的目标...这就像为考试而学习而不是学习材料。 ELB 永远不会获得 200 OK，除非实例已准备好、愿意并且能够服务于新的应用程序请求，所有内容都已加载、正在运行、所有外部资源（如数据库）可访问且可用。检查应该是有意义的——不仅仅是“有某物在端口 x 上监听，所以大概我们可以开始向它抛出请求”——这是 TCP 检查完成的唯一事情。他们不评估 Web 应用程序服务器的实际运行状况。
为什么要调出 EC2 实例所连接的外部资源？你知道的，即使 EC2 实例无法连接到数据库，当我们使用 HTTP Ping 协议时，它仍然会给 ELB 200 OK。