Shulou(Shulou.com)06/01 Report--

This article mainly introduces the example analysis of the configuration of http health check in Nginx, which is very detailed and has certain reference value. Friends who are interested must finish it!

Passive inspection

For passive health checks, NGINX and NGINX Plus monitor the event when it occurs and attempt to restore the failed connection. If it still fails to return to normal, NGINX open source and NGINX Plus mark the server as unavailable and temporarily stop sending requests to it until it is marked as active again.

The condition marked as unavailable by the upstream server is defined for each upstream server and contains the parameter upstream of the server directive in the block:

Fail_timeout-sets the time that multiple failed attempts must be made when the server is marked as unavailable, and the time the server is marked as unavailable (the default is 10 seconds).

Max_fails-sets the number of failed attempts that must occur during the time the fail_timeout server is marked as unavailable (the default is 1 attempt). In the following example, if NGINX fails to send a request to the server within 30 seconds or does not receive a response 3 times, the server is unavailable within 30 seconds:

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

It is important to note that if there is only one server group and the fail_timeout and max_fails parameters are ignored, the server will never be marked as unavailable.

The server starts slowly

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

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 with a bit unavailable state. Slow start is a proprietary function of NGINX Plus

Active check of 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 response.

To enable an active health check:

1. The health_check instruction is included in the process of passing requests (proxy_pass) to the upstream group in the location block:

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

This code snippet defines a server that matches all requests to location / to the calling upstream group backend. It also uses this health_check directive to enable advanced health monitoring: by default, NGINX Plus sends a "/" request backend to each server in the group every five seconds.

If any communication errors or timeouts occur (when the status code returned by the server is beyond the range of 200399), the health check fails. The server is marked as unhealthy and NGINX Plus does not send client requests to it until it passes the health check again.

Another option: you can specify another port for health checks, for example, to monitor the health of many services on the same host. Specify the new port health_check using the port parameter of the directive:

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

two。 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 shared among all worker processes and stores the configuration of the upstream group. This enables the worker process to use the same set of counters to track the response of the server in the group.

You can use the parameters of the health_check directive to override the default values for the active health check:

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

Here, this interval parameter increases the delay between health checks from the default of 5 seconds to 10 seconds. This fails parameter requires the server to mark it as unhealthy (starting with the default) when three health checks fail. Finally, the passes parameter means that the server must pass two consecutive checks before it can be marked as healthy again, rather than the default.

Specify the requested URL

Specify the uri parameter in the health_check directive to set the routing of health check requests:

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

The specified URI is appended to the server domain name or IP address set for the server in the upstream block. For the first server in the sample group declared above by backend, the health check requests URI http://backend1.example.com/some/path.

Define custom conditions

You can set custom conditions that the response must meet for the server to pass the health check. The condition is defined in the match block, which match is referenced in the parameters of the health_check instruction.

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 specifies 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;}

If the status code of the response is in range, pass the health check 200399 and its body does not contain the string: 'maintenance mode'

This match instruction enables NGINX Plus to check the status code, title field, and response body. Use this directive to verify that the state is within the specified range, that the response contains a header, or that the header or body matches the regular expression. The match instruction can contain a state condition, a body condition, and a plurality of title conditions. The response must meet all the conditions defined in the match block for the server to pass the health check.

For example, the following match instruction matches the stateful code response 200, the exact value of the Content-Type title of text/html, and the text on the page: 'Welcome to nginxcharacters.

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

The following example uses an exclamation point (!) to define the characteristics that the response does not pass the health check. In this case, the health check will pass the check if it is not 301, 302, or 307 status code, and there is no Refresh header information.

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

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

A lot of good features require Nginx Plus to use.

The above is all the contents of the article "sample Analysis of http Health check configuration in Nginx". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.