Here we will explain in detail the bugs in the healthcheck_nginx_upstreams module. For the installation and use of the healthcheck_nginx_upstreams module, please read the previous blog to learn.
In the testing environment, use nginx for reverse proxy and forward requests to 2 and 3:
1.192.168.0.235(nginx)2.192.168.30.150(apache)3.192.168.30.200(apache)
When I used the method of the previous blog to install healthcheck_nginx_upstreams and configure nginx as follows:
worker_processes 5;#daemon off;events { worker_connections 1000;}# Only if you want to see lots of spamerror_log logs/error.log debug_http;http { upstream test_upstreams { server 192.168.30.150:80; server 192.168.30.200:80; healthcheck_enabled; healthcheck_delay 2000; healthcheck_timeout 1000; healthcheck_failcount 1; healthcheck_send "GET /.health HTTP/1.0"; } server { listen 12389; location / { proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://test_upstreams; proxy_connect_timeout 3; } location /stat { healthcheck_status; } }}
1. Test processing when a machine fails:
Access all hosts to 200
2. Will the connection be automatically established when 150 is started?
When you access 235, you can access both machines at the same time.
What are the benefits of adding the healthcheck_nginx_upstreamsm module?
If the native upstream module is used, when the web server goes down, many user requests may be distributed to the down server, which directly affects user operations.
With the healthcheck_nginx_upstreams module, you can develop a more user-friendly monitoring interface by yourself.