Several solutions for health checks in backend applications

Here are just the solutions for your current company:

Project one: Through the Nginx healthcheck_nginx_upstreams module to achieve

The disadvantage is: The third party module, the need for independent compilation and installation, and 2 years has not been updated, do not know more than 1.6 of the Nginx version support how;

Warehouse Address of Project: Https://github.com/cep21/healthcheck_nginx_upstreams

Option two: Use Tengine, bring the Ngx_http_upstream_check_module module

Tengine is Ali based on nginx1.8 branch do two development, the main performance reflected in dynamic loading and performance, stability, the disadvantage is that the development lags far behind the development of the Nginx.

examples

HTTP {upstream Cluster1 {# simple Round-robin server 192.168.0.1:80; server 192.168.0.2:80; Check interval=3000 rise=2 fall=5 timeout=1000 type=http; Check_http_send "head/http/1.0\r\n\r\n"; Check_http_expect_alive http_2xx http_3xx;   } upstream Cluster2 {# simple Round-robin server 192.168.0.3:80; server 192.168.0.4:80; Check interval=3000 rise=2 fall=5 timeout=1000 type=http; Check_keepalive_requests 100; Check_http_send "head/http/1.1\r\nconnection:keep-alive\r\n\r\n"; Check_http_expect_alive http_2xx http_3xx;   } server {Listen 80;   LOCATION/1 {Proxy_pass http://cluster1;}   LOCATION/2 {Proxy_pass http://cluster2;}   location/status {check_status; Access_log off; Allow SOME. Ip. ADD. RESS; Deny all; } } }

directives

Syntax:check interval=milliseconds [Fall=count] [Rise=count] [timeout=milliseconds] [default_down=true|false] [type= TCP|HTTP|SSL_HELLO|MYSQL|AJP] [Port=check_port]
Default: If there are no configuration parameters, the defaults are: interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp
Context:upstream

This directive can open the Health Check feature of the backend server.

The parameters behind the directive are: interval: the interval of health check packets sent back to the end. Fall (Fall_count): If the number of consecutive failures reaches Fall_count, the server is considered down. Rise (Rise_count): If the number of consecutive successes reaches Rise_count, the server is considered up. Timeout: timeout for back-end health requests. Default_down: Set the state of the server at the initial time, if true, the default is down, if false, is up. The default value is true, which is considered to be unavailable at the start of the server and is considered healthy after a certain number of successful health check packs have been reached. Type: Health Check package types, now supports a variety of types of TCP: Simple TCP connections, if the connection succeeds, the backend is normal. Ssl_hello: Send an initial SSL Hello package and accept the server's SSL Hello package. http: Sends an HTTP request to determine if the back end is alive through the back-end packet status. MySQL: Connect to the MySQL server to determine if the backend is alive by receiving a greeting packet from the server. AJP: Send the cping packet of the AJP protocol to the back end to determine if the back end is alive by receiving the Cpong packet. Port: Specifies the check ports for the back-end server. You can specify a port that is different from a real service backend server, such as a 443 port application on the back end, and you can check the status of the 80 ports to determine the backend health status. The default is 0, which means the same port as the back-end server that provides the real service. This option appears in Tengine-1.4.0.

Syntax:check_keepalive_requests Request_num
Default:1
Context:upstream

The directive can configure the number of requests sent by a connection with a default value of 1, which means that the connection is closed after the Tengine completes 1 requests.

Syntax:check_http_send Http_packet
Default: "get/http/1.0\r\n\r\n"
Context:upstream

The directive can configure the requested content sent by the HTTP Health check package. In order to reduce the amount of data transmitted, the "Head" method is recommended.

When using a long connection for a health check, add the Keep-alive request header to the directive, such as "head/http/1.1\r\nconnection:keep-alive\r\n\r\n".
At the same time, in the case of a "get" method, the size of the request URI should not be too large to ensure that it can be transferred within 1 interval, or it will be considered a backend server or network exception by the Health Check module.

syntax:check_http_expect_alive [http_2xx | http_3xx | http_4xx | http_5xx]
default:http_2xx | Http_3xx
Context:upstream

This directive specifies the success status of the HTTP reply, and the 2XX and 3XX states are considered healthy by default.

Scenario Three: Direct use of Aliyun's SLB check Health to achieve