JIYIK CN >

In Nginx load balancing, it is difficult to guarantee that every application server can run normally all the time. However, we can set Nginx to detect these application servers and detect which of them are inaccessible.

There are two ways to detect Nginx: passive monitoring and active monitoring. Let's take a look at these two methods.

Passive monitoring

When Nginx thinks that an application server is inaccessible, it will temporarily stop distributing requests to this application. It will not distribute requests to this application server until Nginx thinks that the application server can be accessed again.
To monitor the application server, two parameters are needed to help.

fail_timeout - This parameter indicates the time to stop distributing requests to the application server. In other words, if Nginx thinks that an application server cannot be accessed, Nginx will stop distributing requests to this application server. How long will it take for Nginx to think that the server can be accessed and distribute requests to it? This parameter is used to set this time.

max_fails - Set the maximum number of failed accesses. When Nginx distributes requests to a server, if the number of failures reaches the number set by this parameter, Nginx considers the application server inaccessible. No further requests will be sent to the application server. Requests will not be distributed to the application again until the time set by fail_timeout is reached.

Example 1

http {
    upstream onmpw {
        server 192.168.144.128;
        server 192.168.144.132 max_fails=3 fail_timeout=30s;
        server 192.168.144.131 max_fails=2;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://onmpw;
        }
    }
}

The default values ​​for fail_timeout and max_fails are 10s and 1 time respectively. That is, when Nginx sends a request to an application server, if it fails, the application server is considered inaccessible. In the next 10 seconds, the request will no longer be distributed to the application server. It will not be distributed to the application server again until 10 seconds later.

For example 1, we can see that for application 132, when the number of failed requests reaches 3 times, Nginx will not distribute requests to the application within 30 seconds. It will not distribute new requests to the application server again until 30 seconds later. For application 131, when the number of requests reaches 2 times, Nginx will not send requests to this application within 10 seconds (because fail_timeout is not set, so the default is 10 seconds).

This method requires us to set it behind the corresponding information of each application server, so it is called passive monitoring.

Active monitoring

Nginx periodically sends special requests to each application server to monitor whether the application server can be accessed normally. This method is called active monitoring.

In order to implement active monitoring, we need to add the health_check directive to the Nginx load balancing configuration file. In addition, we also need to add the zone directive to the group that sets the application server information.

Example 2

http {
upstream onmpw {
           zone onmpw 64k;
        server 192.168.144.128;
        server 192.168.144.132;
        server 192.168.144.131;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://onmpw;
                           health_check;
        }
    }
}

Here we have set up a group of application servers. All requests are distributed to this group of application servers through a single location. In this case, Nginx Plus will send a '/' request to each application server every 5 seconds. If any application server has a connection error or response timeout, or the proxied server responds with a status code of 2xx or 3xx, the health_check mechanism will consider it a failure. For any application server, if the health_check fails, it will be considered unstable. Then Nginx Plus will no longer distribute access requests to this application server.

The zone directive defines a memory space. This space stores the state of the runtime environment shared by each worker process and the configuration information of the application server group. This space should be applied as large as possible according to the actual situation to ensure that it can store this information.

Let’s look at another example like this:

Example 3

location / {
    proxy_pass http://onmpw;
    health_check interval=10 fails=3 passes=2;
}

In the above example 3, interval=10 means that the interval between two health_checks is 10s. If not set, the default interval is 5s. fails=3 means that if an application server fails three times, the application server is considered inaccessible. Finally, passes=2 means that a server that is considered inaccessible needs to perform two more health_checks before it can be considered accessible again.

In health_check, we can specify the url to request.

Example 4

location / {
    proxy_pass http://onmpw;
    health_check uri=/some/path;
}

For the first application server 128 in the onmpw group, the URL of a health check request is http://192.168.144.128/some/path.

The above two monitoring methods are commonly used. I hope this article will be helpful to you.