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。

Nginx HTTP 健康检查相关推荐

nginx upstream 健康检查
使用 nginx_upstream_check_module 模块来对来专门提供负载均衡器内节点的健康检查的,这个模块是淘宝开发的,在tengine中这个模块是默认自带的,这个模块的作用就是用来检测后 ...
nginx限流健康检查
Nginx原生限流模块: ngx_http_limit_conn_module模块根据前端请求域名或ip生成一个key,对于每个key对应的网络连接数进行限制. 配置如下: http模块 serve ...
consul集群搭建，配合nginx完成服务动态发现和健康检查
1.概述 1.1 介绍 consul是一个服务发现和配置共享的服务软件,结合nginx的主动健康检查模块nginx_upstream_check_module和服务发现模块nginx-upsync-m ...
nginx patch补丁方式添加 nginx_upstream_check_module 模块，并测试健康检查
原创博客地址:陈帅同学-nginx patch补丁方式添加 nginx_upstream_check_module 模块,并测试健康检查我的测试环境 contos:6.7nginx:1.63 che ...
apisix健康检查测试
健康检查简介健康检查的目的是动态地将上游服务器标记为健康或不健康的状态.开启健康检查功能后,当后端某台上游服务器健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的上游服务器上:而当 ...
nginx后端节点健康检查
一.nginx健康检查的三种方式 1.ngx_http_proxy_module 模块和ngx_http_upstream_module模块(自带)官网地址:http://nginx.org/en/d ...
Nginx的UDP健康检查
Nginx的UDP健康检查本章介绍如何为负载平衡的上游服务器组中的UDP服务器配置不同类型的运行状况检查. 先决条件被动UDP健康检查主动UDP运行状况检查微调UDP运行状况检查 " ...
Nginx的TCP运行时健康检查
Nginx的TCP运行时健康检查本章介绍如何配置TCP的运行状况检查. 介绍先决条件被动TCP运行状况检查服务器缓慢启动活动TCP运行状况检查微调TCP运行状况检查 "匹配&qu ...
Nginx的HTTP运行时健康检查
Nginx的HTTP运行时健康检查本文介绍如何在NGINX Plus和NGINX Open Source中配置和使用HTTP运行状况检查. 介绍先决条件被动健康检查服务器缓慢启动主动健康检查 ...

Nginx HTTP 健康检查

Nginx HTTP 健康检查相关推荐

最新文章

热门文章