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 server
line.
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
section:
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 /healthz
server srv1 10.0.0.1:80 check
server srv2 10.0.0.2:80 check
Use 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".
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:
Parameter | Description |
---|---|
| 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.
![[Active/Standby with VRRP]](https://cdn.haproxy.com/documentation/hapee/1-5r2/assets/health-checks-interval-ed8fa64742db9346918ca8a0a951c9ce0507fdd4cb296a8b8084c210d207b555.png)
Change the health check thresholds
Use the 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
Use the 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 up
Passive Health Checks