内容简介:原文链接:翻译自对于被动健康检查,NGINX 和 NGINX Plus 会在事件发生时对其进行监控,并尝试恢复失败的连接。如果仍然无法恢复正常,NGINX 开源版和 NGINX Plus 会将服务器标记为不可用,并暂时停止向其发送请求,直到它再次标记为活动状态。
原文链接: 何晓东 博客
翻译自 官方文档
被动检查
对于被动健康检查,NGINX 和 NGINX Plus 会在事件发生时对其进行监控,并尝试恢复失败的连接。如果仍然无法恢复正常,NGINX 开源版和 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
参数被忽略,服务器永远不会标记为不可用。
服务器慢启动
最近恢复的服务器很容易被连接淹没,这可能导致服务器再次被标记为不可用。慢启动允许上游服务器在恢复或变得可用之后逐渐将其权重从零恢复到其标称值。这可以指定 upstream 的 server
模块的 slow_start
参数来完成:
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的主动检查
NGINX Plus 可以通过向每个服务器发送特殊的健康检查请求并验证正确的响应来定期检查上游服务器的运行状况。
要启用活动运行状况检查:
-
在
location
区块将 requests(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; } }
-
在上游服务器组,使用
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
参数意味着服务器必须通过两次连续检查才能再次标记为健康,而不是默认值。
指定请求的URL
在 health_check
指令中指定 uri 参数来设置健康检查请求的路由:
location / { proxy_pass http://backend; health_check uri=/some/path; }
指定的 URI 将附加到为 upstream
块中的服务器设置的服务器域名或IP地址。对于backend 上面声明的样本组中的第一个服务器,运行状况检查会请求URI http://backend1.example.com/s...
。
定义自定义条件
您可以设置响应必须满足的自定义条件,以便服务器通过运行状况检查。条件在match块中定义,该块match在health_check指令的参数中引用。
-
在
http {}
级别,指定match {}
块并为其命名,例如:'server_ok'
http { #... match server_ok { # tests are here } }
-
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,或 307状态码,同时并没有 Refresh 头信息时将通过检查,。
match not_redirect { status ! 301-303 307; header ! Refresh; }
健康检查可以在其他非 HTTP 协议中启用, 例如 FastCGI , memcached , SCGI , uwsgi 甚至 TCP 和 UDP 。
很多很好的特性,就是需要 Nginx Plus 才能使用。
顺道推荐几个质量不错的小册 →去看看
以上所述就是小编给大家介绍的《Nginx http运行状况健康检查配置》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 使用jconsole监控JVM运行状况
- 敏捷教练市场发展状况
- 检查Unix系统的负载状况
- SQL语句实现查询Index使用状况
- 报告:后疫情时期产业区块链发展状况
- 网络安全状况月度报告-2019年3月
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Web 2.0 Heroes
Bradley L. Jones / Wiley / 2008-04-14 / USD 24.99
Web 2.0 may be an elusive concept, but one thing is certain: using the Web as merely a means of retrieving and displaying information is history. Today?s Web is immediate, interactive, innovative. It ......一起来看看 《Web 2.0 Heroes》 这本书的介绍吧!