Nginx http运行状况健康检查配置过程解析
被动检查
对于被动健康检查，NGINX和NGINXPlus会在事件发生时对其进行监控，并尝试恢复失败的连接。如果仍然无法恢复正常，NGINX开源版和NGINXPlus会将服务器标记为不可用，并暂时停止向其发送请求，直到它再次标记为活动状态。
上游服务器标记为不可用的条件是为每个上游服务器定义的，其中包含块中server指令的参数upstream：
- fail_timeout-设置服务器标记为不可用时必须进行多次失败尝试的时间，以及服务器标记为不可用的时间（默认为10秒）。
- max_fails-设置在fail_timeout服务器标记为不可用期间必须发生的失败尝试次数（默认为1次尝试）。在以下示例中，如果NGINX未能在30秒内向服务器发送请求或未收到响应3次，则表示服务器在30秒内不可用：
upstreambackend{
serverbackend1.example.com;
serverbackend2.example.commax_fails=3fail_timeout=30s;
}
需要注意的是如果只有一个单一的服务器组中，将fail_timeout和max_fails参数被忽略，服务器永远不会标记为不可用。
服务器慢启动
最近恢复的服务器很容易被连接淹没，这可能导致服务器再次被标记为不可用。慢启动允许上游服务器在恢复或变得可用之后逐渐将其权重从零恢复到其标称值。这可以指定upstream的server模块的slow_start参数来完成：
upstreambackend{
serverbackend1.example.comslow_start=30s;
serverbackend2.example.com;
server192.0.0.1backup;
}
注意：如果组中只有一台服务器，则slow_start参数将被忽略，而服务器永远不会被标记位不可用状态。慢启动是NGINXPlus的专有功能
NGINXPlus的主动检查
NGINXPlus可以通过向每个服务器发送特殊的健康检查请求并验证正确的响应来定期检查上游服务器的运行状况。
要启用活动运行状况检查：
1.在location区块将requests（proxy_pass）传递给上游组的过程中，包含health_check指令：
server{
location/{
proxy_passhttp://backend;
health_check;
}
}
此代码段定义了一个服务器，它将所有请求匹配到location/传递给调用的上游组backend。它还使用该health_check指令启用高级运行状况监视：默认情况下，NGINXPlus每五秒向组中的每个服务器发送一个“/”请求backend。
如果任何通信错误或发生超时（在服务器返回的状态码超出200-399的范围）的健康检查失败。服务器被标记为不健康，并且NGINXPlus在再次通过运行状况检查之前不会向其发送客户端请求。
另一个可选项：您可以指定另一个用于运行状况检查的端口，例如，用于监视同一主机上的许多服务的运行状况。使用指令的port参数指定新端口health_check：
server{
location/{
proxy_passhttp://backend;
health_checkport=8080;
}
}
2.在上游服务器组，使用zone指令定义一个共享内存区域：
http{
upstreambackend{
zonebackend64k;
serverbackend1.example.com;
serverbackend2.example.com;
serverbackend3.example.com;
serverbackend4.example.com;
}
}
该区域在所有工作进程之间共享，并存储上游组的配置。这使工作进程能够使用同一组计数器来跟踪组中服务器的响应。
可以使用health_check指令的参数覆盖活动运行状况检查的默认值：
location/{
proxy_passhttp://backend;
health_checkinterval=10fails=3passes=2;
}
此处，该interval参数将运行状况检查之间的延迟从默认的5秒增加到10秒。该fails参数要求服务器三次运行状况检查失败时，以将其标记为运行状况不佳（从默认值开始）。最后，passes参数意味着服务器必须通过两次连续检查才能再次标记为健康，而不是默认值。
指定请求的URL
在health_check指令中指定uri参数来设置健康检查请求的路由：
location/{
proxy_passhttp://backend;
health_checkuri=/some/path;
}
指定的URI将附加到为upstream块中的服务器设置的服务器域名或IP地址。对于backend上面声明的样本组中的第一个服务器，运行状况检查会请求URIhttp://backend1.example.com/some/path。
定义自定义条件
您可以设置响应必须满足的自定义条件，以便服务器通过运行状况检查。条件在match块中定义，该块match在health_check指令的参数中引用。
1.在http{}级别，指定match{}块并为其命名，例如：'server_ok'
http{
#...
matchserver_ok{
#testsarehere
}
}
2.health_check通过指定块的match参数和match参数块的名称：
http{
#...
matchserver_ok{
status200-399;
body!~"maintenancemode";
}
server{
#...
location/{
proxy_passhttp://backend;
health_checkmatch=server_ok;
}
}
}
如果响应的状态代码在范围中，则传递运行状况检查200-399并且其正文不包含字符串:‘maintenancemode'
该match指令使NGINXPlus能够检查状态代码，标题字段和响应正文。使用此指令可以验证状态是否在指定范围内，响应是否包含标头，或者标头或正文是否与正则表达式匹配。该match指令可以包含一个状态条件，一个正文条件和多个标题条件。响应必须满足match块中定义的所有条件，以便服务器通过运行状况检查。
例如，下面的match指令匹配有状态代码响应200，精确值text/html的Content-Type标题，页面中的文字：'Welcometonginx!'.
matchwelcome{
status200;
headerContent-Type=text/html;
body~"Welcometonginx!";
}
以下示例使用感叹号（!）来定义响应不得通过运行状况检查的特征。在这种情况下，健康检查在非301，302，303，或307状态码，同时并没有Refresh头信息时将通过检查，。
matchnot_redirect{
status!301-303307;
header!Refresh;
}
健康检查可以在其他非HTTP协议中启用,例如FastCGI,memcached,SCGI,uwsgi甚至TCP和UDP。
很多很好的特性，就是需要NginxPlus才能使用。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持毛票票。