A health check is a scheduled rule used to send the same request to each member. A health check sends a request to each member of the load balancer group to establish the availability of each member server to accept the client requests. For some types of health checks, the response from the server is calculated to determine the health status of each member server. The successful completion of the health check needs that the server passes normal TCP and HTTP connection criteria.
In the TCP mode, a health check is performed with a TCP connection request. And in the HTTP mode which is the standard health check type, a health check is performed with an HTTP GET or HTTP POST method.
HTTP Health Checks
Nginx Plus and Nginx open source can continually test our upstream servers, avoid the servers that have failed, and gracefully add the recovered servers into the load-balanced group.
Passive Health Check
For passive health checks, Nginx Plus and Nginx monitor the transaction as they happen, and try to resume the failed connections. If the transaction still cannot be resumed, Nginx Plus and Nginx open-source 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 parameters to the server directive in the upstream block.
Example:
In the following example, if Nginx will fail to send a request to a server or if will not receive a response from it 3 times in 30 seconds, it will mark the server as unavailable for 30 seconds:
upstream backend {
server backend1
server backend2.example.com max_fails=3 fail_timeout=30s;
}
Active Health Check
Nginx Plus periodically checks the health of upstream servers by sending special health check requests to each server and verifying the correct response.
To enable active health checks:
1) The location which passes requests to an upstream group, include the health_check directive:
server {
location / {
proxy_pass http://backend;
health_check;
}
}
2) In the upstream server group, specify a shared memory zone with the zone directive:
http {
upstream backend {
zone backend 64k;
server backend1;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
}
We can override the default for active health checks with parameters to the health_check directive:
location / {
proxy_pass http://backend;
health_check interval=10 fails=3 passes=2;
}
Specifying the Requested URI
We can use the uri parameter of the health_check directive to set the URI to request in a health check:
location / {
proxy_pass http://backend;
health_check uri=/some/path;
}
The specified URI (Uniform Resource Identifier) is appended to the server domain name or IP address set for the server in the upstream block. In the above example, for the first server in the sample backend group, a health check requests the URI
Defining Custom Conditions
We can specify the custom conditions that the response must satisfy 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) On the http { } level, define the match {} block and give the name to it, for example, server_ok:
http {
#...
match server_ok {
# tests are here
}
}
2) Refer the block from the health_check directive by defining the match parameter and the name of the match block:
http {
#...
match server_ok {
status 200-399;
body !~ "maintenance mode";
}
server {
#...
location / {
proxy_pass http://backend;
health_check match=server_ok;
}
}
}
In the above example, the health check is passed if the status code of the response is in the range 200-399, and its body does not contain the string maintenance mode.
