How to configure Nginx http health check

Passive Checks

For passive health checks, nginx and nginx plus monitor events as they occur and attempt to recover failed connections. If that still doesn't work, nginx open source and nginx plus will mark the server as unavailable and temporarily stop sending requests to it until it is marked active again.

The conditions under which an upstream server is marked as unavailable are defined for each upstream server with the parameter upstream of the server directive in the block:

• fail_timeout - sets the server mark The time that multiple failed attempts must be made if unavailable, and the time that the server is marked as unavailable (default is 10 seconds).

• max_fails - Sets the number of failed attempts that must occur before the fail_timeout server is marked as unavailable (default is 1 attempt). In the following example, if nginx fails to send a request to the server or does not receive a response 3 times within 30 seconds, it means that the server is unavailable within 30 seconds:

upstream backend {
  server backend1.example.com;
  server backend2.example.com max_fails=3 fail_timeout=30s;
}

Things to note Yes, if there is only a single server group, the fail_timeout and max_fails parameters are ignored and the server is never marked as unavailable.

Server Slow Start

Recently restored servers can easily be flooded with connections, which may cause the server to be marked as unavailable again. Slow start allows an upstream server to gradually restore its weight from zero to its nominal value after it recovers or becomes available. This can be done by specifying the slow_start parameter of upstream's server module:

upstream backend {
  server backend1.example.com slow_start=30s;
  server backend2.example.com;
  server 192.0.0.1 backup;
}

Note: If there is only one server in the group, the slow_start parameter will be ignored and the server will never be marked as unavailable. Slow start is a proprietary feature of nginx plus

nginx plus's active check

nginx plus can do this by sending a special health check request to each server and Periodically check upstream server health by verifying correct responses.

To enable active health check:

1. In the process of passing requests (proxy_pass) to the upstream group in the location block, include the health_check directive:

server {
 location / {
   proxy_pass http://backend;
   health_check;
 }
}

This code snippet defines a server that matches all requests to the location / passed to the upstream group called backend. It also enables advanced health monitoring using the health_check directive: By default, nginx plus sends a "/" request to each server in the group backend every five seconds.

The health check fails if any communication error or timeout occurs (the status code returned by the server is outside the range of 200-399). The server is marked as unhealthy and nginx plus will not send client requests to it until it passes the health check again.

Another optional option: You can specify another port for health checks, for example, to monitor the health of many services on the same host. Use the port parameter of the directive to specify a new port health_check:

server {
 location / {
   proxy_pass  http://backend;
   health_check port=8080;
 }
}

2. In the upstream server group, use the zone directive to define a shared memory area:

http {
 upstream backend {
   zone backend 64k;
   server backend1.example.com;
   server backend2.example.com;
   server backend3.example.com;
   server backend4.example.com;
 }
}

This area is between all worker processes shared among the upstream group and stores the configuration of the upstream group. This enables worker processes to use the same set of counters to track responses from servers in the group.

The default value for active health checks can be overridden using the argument to the health_check directive:

location / {
  proxy_pass http://backend;
  health_check interval=10 fails=3 passes=2;
}

Here, the interval parameter increases the delay between health checks from the default 5 seconds to 10 Second. The fails parameter requires the server to fail three health checks in order to mark it as unhealthy (starting from the default value). Finally, the passes parameter means that the server must pass two consecutive checks before it can be marked healthy again, instead of the default value.

Specify the requested url

Specify the uri parameter in the health_check directive to set the route of the health check request:

location / {
  proxy_pass http://backend;
  health_check uri=/some/path;
}

Specified uri Will be appended to the server domain name or IP address set for the server in the upstream block. For the first server in the backend sample group declared above, the health check requests the uri http://backend1.example.com/some/path.

Define Custom Conditions

You can set custom conditions that a response must meet in order for the server to pass the health check. The conditions are defined in a match block, which is referenced in the argument to the health_check directive.

1.At the http {} level, specify the match {} block and name it, for example: 'server_ok'

http {
 #... 
 match server_ok {
   # tests are here     
 }
}

2.health_check by specifying the block's match parameter and match Name of the parameter block:

http {
 #... 
 match server_ok {
   status 200-399;
   body !~ "maintenance mode";
 }
 server {
   #...     
   location / {
     proxy_pass http://backend;
     health_check match=server_ok;
   }
 }
}

Health checks are passed if the response's status code is in the range 200-399 and its body does not contain the string: 'maintenance mode'

The match directive enables nginx plus to check the status code, header fields and response body. Use this directive to verify that the status is within the specified range, that the response contains headers, or that the headers or body match a regular expression. The match directive can contain a status condition, a body condition, and multiple title conditions. The response must meet all conditions defined in the match block in order for the server to pass the health check.

例如，下面的 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, , scgi,  甚至 tcp 和 udp。

很多很好的特性，就是需要 nginx plus 才能使用。

The above is the detailed content of How to configure Nginx http health check. For more information, please follow other related articles on the PHP Chinese website!