Nginx Load Balancer Monitoring node status

Nginx Load Balancer monitoring node status v plug-in (ngx_http_upstream_check_module)

• Upstream_check_module Introduction:

The module can provide Tengine with proactive backend server health checks.

The module is not enabled by default before the Tengine-1.4.0 version, it can be opened when the compile option is configured:./configure--with-http_upstream_check_module

• Upstream_check_module Official Documents

Http://tengine.taobao.org/document_cn/http_upstream_check_cn.html

• Upstream_check_module

Https://github.com/yaoweibin/nginx_upstream_check_module

• Installing the patch on nginx

Unzip Nginx_upstream_check_module-master.zip
Useradd nginx-s/sbin/nologin-m
Tar XF nginx-1.9.2.tar.gz
CD nginx-1.9.2
Patch-p0</root/nginx_upstream_check_module-master/check_1.9.2+.patch
./configure \
--prefix=/application/nginx-1.9.2 \
--user=nginx \
--group=nginx \
--with-http_ssl_module \
--with-http_stub_status_module \
--add-module=/root/nginx_upstream_check_module-master
Make
Make install
Ln-s/application/nginx-1.9.2//application/nginx

• Patch Parameter Description

-P0 option to find the destination file (clip) from the current directory

-P1 option to ignore the first level of the directory, starting from the current directory to find.

Here is an example description:

Old/modules/pcitable

If you use the parameter-p0, it means to find a folder called old from the current directory, and under it look for the pcitable file under modules to perform the patch operation.

If you use parameter-p1, it means ignoring the first-level directory (that is, old), looking for the Modules folder from the current directory, and looking for pcitable under it. This assumes that the current directory must be the directory where the modules is located.

• Upstream_check_module Syntax

Syntax:checkinterval=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=5rise=2 timeout=1000 default_down=true type=tcp

Context:upstream

The meaning of the parameters after the instruction is:

Interval: The interval of health check packets sent to the back end. The unit is in milliseconds.

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: The time-out for the backend health request. The unit is in milliseconds.

Default_down: Set the initial state of the server, if true, it means that the default is down, if false, is up. The default value is true, that is, the start of the server is not available, it will be considered healthy after the health check pack has reached a certain number of successes.

Type: Types of health Check packages, which now support the following multiple types

TCP: A simple TCP connection, if the connection is successful, indicates that the backend is normal.

Ssl_hello: Send an initial SSL Hello packet and accept the server's SSL Hello package.

http: Sends an HTTP request to determine whether the backend is alive by the state of the backend's reply packet.

MySQL: Connect to the MySQL server to determine if the backend is alive by receiving the greeting packet from the server.

AJP: Sends the cping packet of the AJP protocol to the back end to determine if the backend is alive by receiving the Cpong packet.

Port: Specifies the check port for the back-end server. You can specify the port of a backend server that is different from the real service, such as a 443 port application on the backend, and you can check the status of Port 80 to determine the backend health. The default is 0, which means that the backend server provides the same port as the real service. This option appears in Tengine-1.4.0.

http {    upstream cluster1 {         # simple round-robin        server 192.168.0.1:80 ;        server 192.168.0.2:80;          check interval=3000 rise=2 fall=5timeout=1000 type=http;         check_http_send  "head /http/1.0\r\n\r\n";         check_http_expect_alive http_2xxhttp_3xx;    }      upstream cluster2 {        #  simple round-robin        server 192.168.0.3:80;         server 192.168.0.4:80;          check interval=3000 rise=2 fall=5timeout=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_2xxhttp_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;         }    }}

• Configuration

http {    upstream dynamic_pools {        server192.168.10.30;       server192.168.10.31;        check interval=3000 rise=2 fall=5timeout=1000;# interval detection interval time, In milliseconds, Rsie requests 2 times normal, marking this realserver status as Up,fall indicates that the request 5 times fails, marking the status of this realserver as down,timeout for the time-out, in milliseconds.     }    server {         Listen       80;        server_name   www.etiantian.org;        location / {            proxy_pass http://dynamic_pools;             includeproxy.conf;         }        location /nstatus {             check_status;            access_ log off;   #不记录访问日志              allow192.168.10.0/24;   #允许的ip地址 (Duan)              deny all;   #除过允许的ip地址 (segment) Deny all IP access        }     }}

• Browser access

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M01/78/D9/wKioL1aEAxiREQswAADBnCmmiy8149.png "title=" Qq20151231000123.png "alt=" Wkiol1aeaxireqswaadbncmmiy8149.png "/>

This article from "Pinellia, perilla" blog, please be sure to keep this source http://shmilyjinian.blog.51cto.com/8279182/1730196

Nginx Load Balancer Monitoring node status