HAProxy Enterprise Documentation 1.5r2

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

inter

Sets the interval between two consecutive health checks. If not specified, the default value is 2s.

fastinter

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.

downinter

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]

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