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 appropriatebackend
section. Also, add acheck
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 theglobal
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.
![[Active/Standby with VRRP]](https://cdn.haproxy.com/documentation/aloha/12-5/assets/health-checks-interval-ed8fa64742db9346918ca8a0a951c9ce0507fdd4cb296a8b8084c210d207b555.png)
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 theserver
lines you want to monitor.Add the
observe layer7
parameter to eachserver
line to activate passive health checking.Add the
error-limit
andon-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 eachserver
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