Nginx的HTTP运行时健康检查

Nginx的HTTP运行时健康检查

 

本文介绍如何在NGINX Plus和NGINX Open Source中配置和使用HTTP运行状况检查。

• 介绍
• 先决条件
• 被动健康检查
  • 服务器缓慢启动
• 主动健康检查
  • 指定请求的URI
  • 定义自定义条件

 

介绍

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，或307，并没有Refresh头。

match not_redirect {
    status ! 301-303 307;
    header ! Refresh;
}

还可以为非HTTP协议（例如FastCGI，memcached，SCGI，uwsgi）以及TCP和UDP启用运行状况检查。