Nginx http health check configuration process analysis

Passive Check

With passive health checks, NGINX and NGINX Plus monitor events as they occur and attempt to recover failed connections. If it still cannot recover, NGINX Open Source and NGINX Plus 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 upstream parameter of the server directive in the include block:

• fail_timeout - Sets the number of failed attempts that must occur before the server is marked as unavailable, and the time it takes for the server to be marked unavailable (default is 10 seconds).
• max_fails - Sets the number of failed attempts that must occur during the fail_timeout period for the server to be marked 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 three times within 30 seconds, the server is considered unavailable for 30 seconds:

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

Note that if there is only a single server in the group, the fail_timeout and max_fails parameters are ignored and the server will never be marked as unavailable.

Server slow start

A recently restored server can easily be overwhelmed with connections, which can cause the server to be marked 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 the upstream 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 feature exclusive to NGINX Plus.

Active Checks for NGINX Plus

NGINX Plus can periodically check the health of upstream servers by sending special health check requests to each server and verifying the correct responses.

To enable active health checks:

1. Include the health_check directive in the location block that passes requests (proxy_pass) to the upstream group:

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

This snippet defines a server that passes all requests matching location / 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 for the “/” backend every five seconds.

If any communication error or timeout occurs (the server returns a status code outside the range 200-399) the health check fails. The server is marked as unhealthy, and NGINX Plus does not send client requests to it until it passes health checks again.

Optional: You can specify a different port to use for the health check, for example to monitor the health of many services on the same host. Specify the new port using the port parameter of the health_check directive:

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

2. In the upstream server group, define a shared memory zone using the zone directive:

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 shared between all worker processes and stores the configuration of the upstream group. This enables the worker processes to use the same set of counters to track responses from the servers in the group.

The default values ​​for active health checks can be overridden using the health_check directive's parameters:

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 of 5 seconds to 10 seconds. The fails parameter requires a server to fail three health checks in order to mark it as unhealthy (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 for health check requests:

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

The 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 sample backend group declared above, the health check would request the URI http://backend1.example.com/some/path.

Defining custom conditions

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

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

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

2. health_check by specifying the match parameter of the block and the name of the match parameter block:

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

A health check is passed if the response has a status code in the range 200-399 and its body does not contain the string: 'maintenance mode'

The match directive enables NGINX Plus to examine the status code, header fields, and response body. Use this directive to verify that the status is within a 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.

For example, the following match directive matches responses with status code 200, a Content-Type header with the exact value text/html, and the text in the page: 'Welcome to nginx!'.

match welcome {
  status 200;
  header Content-Type = text/html;
  body ~ "Welcome to nginx!";
}

The following example uses an exclamation point (!) to define characteristics of a response that must not pass a health check. In this case, the health check will pass with a status code other than 301, 302, 303, or 307 and without a Refresh header.

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

Health checks can be enabled on other non-HTTP protocols, such as FastCGI, memcached, SCGI, uwsgi and even TCP and UDP.

Many good features require Nginx Plus to use.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.