Active Health Checks
An active health check attempts to connect to a server or send it an HTTP request at a regular interval. If the connection cannot be established or the HTTP request fails, then the health checks fails. The minimum configuration for a health check is the
check keyword on a
Check a TCP port
A basic TCP-layer health check tries to connect to the server's TCP port. The check is valid when the server answers with a SYN/ACK packet. Enable it by adding a
check parameter to each
server line that you would like to monitor.
In the following example, the load balancer tries to connect to port 80 on each server:
backend be_myapp server srv1 10.0.0.1:80 check server srv2 10.0.0.2:80 check
To send health check probes to a port other than the one to which normal traffic is sent, add the
port parameter. In the following example, the health check is sent to port 8080.
backend be_myapp server srv1 10.0.0.1:80 check port 8080 server srv2 10.0.0.2:80 check port 8080
Check an HTTP service
An HTTP-layer health check sends an HTTP OPTIONS request to the server and expects to get a successful response. The response status code should be in the 2xx or 3xx range. To enable it, add
option httpchk to the
backend be_myapp option httpchk server srv1 10.0.0.1:80 check server srv2 10.0.0.2:80 check
You can change the HTTP method and URL by specifying them on the
option httpchk line. In the following example, checks are sent using GET to the URL /healthz:
backend be_myapp option httpchk GET
/healthzserver srv1 10.0.0.1:80 check server srv2 10.0.0.2:80 check
http-check expect to require a specific HTTP status code from the server. In the following example, the server must return a 200 OK response:
backend bk_myapp option httpchk http-check expect status 200 server srv1 10.0.0.1:80 check server srv2 10.0.0.2:80 check
Alternatively, you can use
rstatus to specify a regular expression to match the status code. In the next example, the health check uses
rstatus in conjunction with the negation operator (!) to consider all statuses as valid except for 5xx responses:
backend bk_myapp option httpchk http-check expect ! rstatus ^5 default-server inter 3s fall 3 rise 2 server srv1 10.0.0.1:80 check server srv2 10.0.0.2:80 check
You can also specify a string to search for in the body of the response. In the next example, the response must contain the string "OK".
tune.chksize in the
global section to set the number of bytes of the response to buffer.
Buffer 32 kilobytes (32,768 bytes) of the response.
global tune.chksize 32768
Then add the
http-check expect string directive to specify the string that you expect to see in the body.
The response must contain the string OK.
backend be_myapp option httpchk http-check expect string OK server srv1 10.0.0.1:80 check server srv2 10.0.0.2:8080 check
Change the health check interval
By default, HAProxy Enterprise sends a health check every two seconds. Change this by adding the
inter parameter to the
server line. In the next example, health checks are sent once every four seconds:
backend be_myapp server srv1 10.0.0.1:80 check inter 4s server srv2 10.0.0.2:80 check inter 4s
Use any of the following time suffixes:
us : microseconds
ms : milliseconds
s : seconds
m : minutes
h : hours
d : days
Other parameters that affect the check interval are defined below:
| || |
Sets the interval between two consecutive health checks. If not specified, the default value is 2s.
| || |
Sets the interval between two consecutive health checks when the server is in any of the transition states: UP - transitionally DOWN or DOWN - transitionally UP. If not set, then inter is used.
| || |
Sets the interval between two consecutive health checks when the server is in the DOWN state. If not set, then inter is used.
The diagram below describes at which phase each of these settings applies.
Change the health check thresholds
fall parameter to change the number of failed health checks that will trigger removing the server from the load-balancing rotation. By default, this is set to 3. In the following example, five failed checks will put the server into the DOWN state:
backend be_myapp server srv1 10.0.0.1:80 check fall 5 server srv2 10.0.0.2:80 check fall 5
rise parameter to set how many successful checks are needed to bring a down server back up. The default is 2. In the following example, ten successful health checks are needed before the server will return to the load-balancing rotation:
backend be_myapp server srv1 10.0.0.1:80 check fall 5 rise 10 server srv2 10.0.0.2:80 check fall 5 rise 10
Next upPassive Health Checks