Nginx HTTP 健康检查
通过发送定期健康检查（包括 NGINX Plus 中可自定义的主动健康检查）来监控上游组中 HTTP 服务器的健康状况。
介绍
NGINX 和 NGINX Plus 可以持续测试您的上游服务器，避免出现故障的服务器，并将恢复的服务器优雅地添加到负载均衡组中。
先决条件
- 对于被动健康检查，NGINX Open Source或NGINX Plus
- 对于主动健康检查和实时活动监控仪表板，NGINX Plus
- 一组负载均衡的HTTP 上游服务器
被动健康检查
对于被动健康检查，NGINX 和 NGINX Plus 会在事务发生时对其进行监控，并尝试恢复失败的连接。如果事务仍然无法恢复，NGINX Open Source 和 NGINX Plus 将服务器标记为不可用并暂时停止向其发送请求，直到它再次标记为活动状态。
上游服务器被标记为不可用的条件是为每个上游服务器定义的，并带有块中server指令的参数upstream：
- fail_timeout – 设置必须发生多次失败尝试才能将服务器标记为不可用的时间，以及将服务器标记为不可用的时间（默认为 10 秒）。
- max_fails – 设置在fail_timeout将服务器标记为不可用期间必须发生的失败尝试次数（默认为 1 次尝试）。
在以下示例中，如果 NGINX 无法向服务器发送请求或在 30 秒内没有收到 3 次响应，它将服务器标记为不可用 30 秒：
upstream backend {
server backend1.example.com;
server backend2.example.com max_fails=3 fail_timeout=30s;
}
请注意，如果只有一个单一的服务器组中，将fail_timeout和max_fails参数被忽略，服务器永远不会标记为不可用。
服务器慢启动
最近恢复的服务器很容易被连接淹没，这可能会导致服务器再次被标记为不可用。慢启动允许上游服务器在恢复或可用后逐渐从零恢复其权重到其标称值。这可以通过slow_start上游server指令的参数来完成：
upstream backend {
server backend1.example.com slow_start=30s;
server backend2.example.com;
server 192.0.0.1 backup;
}
请注意，如果组中只有一个服务器，slow_start则忽略该参数并且该服务器永远不会标记为不可用。慢启动是 NGINX Plus 独有的。
主动健康检查
NGINX Plus 可以通过向每个服务器发送特殊的健康检查请求并验证正确响应来定期检查上游服务器的健康状况。
要启用主动健康检查：
1.在location将请求 ( proxy_pass)传递给上游组的 中，包含health_check指令：
server {
location / {
proxy_pass http://backend;
health_check;
}
}
此代码段定义了一个服务器，它将所有请求 ( location /)传递到名为 的上游组backend。它还通过health_check指令启用高级健康监控：默认情况下，NGINX Plus 每五秒向组中的每个服务器发送一个“ / ”请求backend。如果任何通信错误或发生超时（与范围之外的状态代码从服务器响应200通过399）的健康检查失败。服务器被标记为不健康，并且 NGINX Plus 不会向它发送客户端请求，直到它再次通过健康检查。您可以选择为健康检查指定另一个端口，例如，用于监视同一主机上许多服务的健康状况。使用指令的port参数指定一个新端口health_check：
server {
location / {
proxy_pass http://backend;
health_check port=8080;
}
}
2.在上游服务器组中，使用zone指令定义共享内存区域：
http {
upstream backend {
zone backend 64k;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
}
该区域在所有工作进程之间共享，并存储上游组的配置。这使工作进程能够使用相同的一组计数器来跟踪来自组中服务器的响应。
可以使用health_check指令的参数覆盖主动健康检查的默认值：
location / {
proxy_pass http://backend;
health_check interval=10 fails=3 passes=2;
}
这里，该interval参数将健康检查之间的延迟从默认的 5 秒增加到 10 秒。该fails参数要求服务器未通过三项健康检查才能被标记为不健康（从默认的一项开始）。最后，该passes参数意味着服务器必须通过两次连续检查才能再次被标记为健康，而不是默认的一次。
指定请求的 URI
使用指令的uri参数health_check设置要在健康检查中请求的 URI：
location / {
proxy_pass http://backend;
health_check uri=/some/path;
}
指定的 URI 附加到为upstream块中的服务器设置的服务器域名或 IP 地址。对于backend上面声明的示例组中的第一个服务器，健康检查请求 URI http://backend1.example.com/some/path。
定义自定义条件
您可以设置响应必须满足的自定义条件，服务器才能通过健康检查。条件在一个match块中定义，该块match在health_check指令的参数中被引用。
1.在http {}级别上，指定match {}块并为其命名，例如server_ok：
http {
#... match server_ok {
# tests are here }
}
2.health_check通过指定match参数和match块的名称来引用指令中的块：
http {
#... match server_ok {
status 200-399;
body !~ "maintenance mode";
}
server {
location / {
proxy_pass http://backend;
health_check match=server_ok;
}
}
}
这里如果响应的状态码范围内的健康检查获得通过200-399和它的身体不包含字符串maintenance mode。
该match指令使 NGINX Plus 能够检查状态代码、标头字段和响应正文。使用此指令可以验证状态是否在指定范围内，响应是否包含标头，或者标头或正文是否与正则表达式匹配。该match指令可以包含一个状态条件，一个身体状况，和多个头的条件。响应必须满足match块中定义的所有条件，服务器才能通过健康检查。
例如，下面的match指令匹配有状态代码响应200，精确值text/html的Content-Type标题，文字Welcome to nginx!的身体：
match welcome {
status 200;
header Content-Type = text/html;
body ~ "Welcome to nginx!";
}
以下示例使用感叹号 ( !) 来定义响应不必通过运行状况检查的特征。在这种情况下，当状态代码不是301, 302, 303, or307并且没有Refresh标头时，健康检查通过。
match not_redirect {
status ! 301-303 307;
header ! Refresh;
}
强制性健康检查
默认情况下，当一个新服务器被添加到上游组时，NGINX Plus 认为它是健康的并立即向它发送流量。但是对于某些服务器，特别是如果它们是通过 API 接口或通过 DNS 解析添加的，最好先进行健康检查，然后再允许它们处理流量。
该mandatory参数要求每个新添加的服务器在 NGINX Plus 向其发送流量之前通过所有配置的健康检查。
与 结合使用时slow start，它可以让新服务器有更多时间连接到数据库并在被要求处理全部流量之前“预热”。
强制健康检查可以标记为持久性，以便在重新加载配置时记住之前的状态。与persistent参数一起指定mandatory参数：
upstream my_upstream {
zone my_upstream 64k;
server backend1.example.com slow_start=30s;
}server {
location / {
proxy_pass http://my_upstream;
health_check mandatory persistent;
}
}
在这里，mandatory与persistent该参数的health_check指令和slow_start该参数server指定指令。使用 API 或 DNS 接口添加到上游组的服务器被标记为不健康，并且在它们通过健康检查之前不会收到任何流量；那时，他们开始在 30 秒内收到逐渐增加的流量。如果 NGINX Plus 配置被重新加载并且在重新加载之前服务器被标记为健康，则不会执行强制健康检查并且服务器状态被认为是up。
还可以为非 HTTP 协议启用健康检查，例如FastCGI、memcached、SCGI、uwsgi以及TCP 和 UDP。