HAProxy ALOHA Documentation 12.5

HTTP

You can proactively check the health of your backend servers and remove them from the load balancer rotation until they're up and running again. HAProxy ALOHA provides a way to monitor the health of your servers using the HTTP protocol.

Active health checks

When you set up active health checks, a probe regularly tries to send the server an HTTP request. If the HTTP request fails, the health check fails.

To enable active health checks, select the LB Layer7 tab.
Add the option httpchk directive to the appropriate backend section. Also, add a check parameter to each server line that you would like to monitor.

The option httpchk directive 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.
Enable active health checks.
```
backend be_myapp
  option httpchk
  server srv1 10.0.0.1:80   check
  server srv2 10.0.0.2:8080 check
```

Change the HTTP method and URL

To change the HTTP method and/or URL used for the health check to something other than OPTIONS and the root path /, add an http-check send line and specify the meth and uri parameters to specify the HTTP method and URL.

Send health check probes through the GET method to the /healthz URL.

backend be_myapp
  option httpchk
  http-check send meth GET uri /healthz
  server srv1 10.0.0.1:80   check
  server srv2 10.0.0.2:8080 check

Require a specific HTTP status code from the server

By default, the health check probe will accept any server response with a status code in the 2xx or 3xx range as successful. To require a specific status code response, add the http-check expect directive to the appropriate backend section.

Consider only a 200 OK response as a successful health check.

backend be_myapp
  option httpchk
  http-check expect status 200
  server srv1 10.0.0.1:80   check
  server srv2 10.0.0.2:8080 check

You can also match the status code using a regular expression. Add the rstatus directive to the http-check directive to set a regular expression.

Regard all statuses as valid except those beginning with the number 5.

backend be_myapp
  option httpchk
  http-check expect ! rstatus ^5
  server srv1 10.0.0.1:80   check
  server srv2 10.0.0.2:8080 check

Search for a string in the response body

A health check probe can require that a string be included in the body of the response.

Set 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

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 threshold of failed health checks

To change the number of failed health checks that trigger removing the server from the load balancer rotation, add the fall parameter to the server line.

The default threshold is 3.

Put the server in the DOWN state after five failed checks.

backend be_myapp
  option httpchk
  server srv1 10.0.0.1:80   check fall 5
  server srv2 10.0.0.2:8080 check fall 5

Change the threshold of successful health checks

To set how many successful checks are needed to bring a down server back up, add the rise parameter to the server line.

The default threshold is 2.

The server is back in the load balancer rotation after 10 successful health checks.

backend be_myapp
  option httpchk
  server srv1 10.0.0.1:80   check fall 5 rise 10
  server srv2 10.0.0.2:8080 check fall 5 rise 10

Change the health check interval

To change how often HAProxy ALOHA sends a health check probe, add the inter parameter to the server line.

The default value is 2s.

HAProxy ALOHA sends a health check probe once every four seconds.

backend be_myapp
  option httpchk
  server srv1 10.0.0.1:80   check inter 4s
  server srv2 10.0.0.2:8080 check inter 4s

When a server fails its first health check, you may want to send the probes more rapidly to take the problematic server out of the rotation more quickly. In that case, you can use the fastinter parameter on the server line to change the interval between consecutive health checks when the server is either transitioning to a DOWN state (because it will eventually fail enough health checks) or is transitioning to the UP state (because it is currently down, but is passing health checks now).

After failing the first health check, begin sending health check probes every second.

backend be_myapp
  option httpchk
  server srv1 10.0.0.1:80   check inter 4s fastinter 1s
  server srv2 10.0.0.2:8080 check inter 4s fastinter 1s

When a server is DOWN and has not yet returned any successful checks, you may wish to send it probes less often to preserve network bandwidth on a server that isn't likely to recover quickly. In that case, you can set the downinter parameter on the server line, which specifies the interval between consecutive health checks when a server is already down.

When a server is down, send it health check probly only every minute.

backend be_myapp
  option httpchk
  server srv1 10.0.0.1:80   check inter 4s downinter 1m
  server srv2 10.0.0.2:8080 check inter 4s downinter 1m

Each of these intervals accepts a time suffix, as described in the table below.

Time unit	Description
us	Microseconds
ms	Milliseconds
s	Seconds
m	Minutes
h	Hours
d	Days

The diagram below describes at which phase each setting applies.

Passive health checks

A passive health check monitors live traffic for error HTTP responses. Passive checks will detect errors returning from any part of your proxied service, but they require active traffic to monitor.

Monitor for HTTP errors

To monitor live traffic for HTTP response errors, follow these steps:

Add the check parameter to the server lines you want to monitor.
Add the observe layer7 parameter to each server line to activate passive health checking.
Add the error-limit and on-error parameters to set the threshold for failed passive health checks and the action to take when errors exceed that threshold.

We monitor for HTTP response errors. When there are at least 10 of these errors, we mark the server as down by using the mark-down value for the on-error parameter:

backend servers
  option httpchk
  server server1 192.168.0.10:80 check  observe layer7  error-limit 10  on-error mark-down

The check parameter enables an active health check probe that will will bring the server back online after it has been removed from the load balancing rotation from failed passive health checks.

Set the on-error action

The on-error parameter on the server line determines what action to take when errors exceed the threshold you set with the error-limit. It takes any of the following values:

Action	Description
fastinter	Forces "fastinter" mode, which causes the active health check probes to be sent more rapidly.
fail-check	Increments one failed active health check and forces "fastinter" mode.
sudden-death	Simulates a pre-fatal failed check. One more check will mark the server as down. It also forces "fastinter" mode.
mark-down	Marks the server as down and forces "fastinter" mode.

Active health checks (Direct Server Return)

The LB Layer7 tab configures an HAProxy reverse proxy. You can also load balance HTTP by using the LB Layer4 tab, which instead configures a network router using Linux Virtual Server (LVS). While an HAProxy reverse proxy is simpler, you may prefer to use the LB Layer4 tab (LVS) when you want to load balance HTTP in combination with Direct Server Return.

In that case, the director section supports sending an HTTP health check probe.

Configure HTTP health checks on the LB Layer4 tab.

director exchange 10.0.0.9:443 TCP
  balance roundrobin                               # load balancing algorithm
  mode gateway                                     # forwarding mode

  option httpcheck port 80 uri /check vhost app.domain.com
  check interval 5s timeout 1s                     # advanced check parameters
  server web1 10.0.0.1:443 check
  server web2 10.0.0.2:443 check

Add a check parameter to each server line for which you would like to enable health checking.

Add option httpcheck in the same section. It uses the following syntax:

option httpcheck [uri <uri>] [statuscode <int>] [vhost <string>]

This directive takes the following arguments:

`uri <string>` (optional)	Requested uri. (default is root /).
`statuscode <code>` (optional)	Expected status code (default: code 200)
`vhost <string>` (optional)	String to set in Host header field.

Add the line check to the section to configure other options. It uses the following syntax:

check { [timeout <seconds>] [interval <seconds>] [source <ip>] [port <port>]
        [rise <count>] [fall <count>] [inhibit] }

`timeout <seconds>`	Period after which an attempt without a response from the server is considered as failed (default: half of `interval`)
`interval <seconds>`	Interval between two checks, in seconds (default: 10 seconds)
`source <ip>`	Source IP to use when performing the check
`port <port>`	Forces the destination port (default: real server port, if it exists)
`rise <count>`	A server will be considered as operational after <count> consecutive successful health checks. The default is 1.
`fall <count`	A server will be considered as dead after <count> consecutive unsuccessful health checks. The default is 1.
`inhibit`	If a server is down, its weight is passed to 0 but not deleted. Established connection are not broken but new connections are dispatched on the other servers.

Next up

ICMP

More Versions

HAProxy Products Documentation