http-check disable-on-404 Enable a maintenance mode upon HTTP/404 response to health-checks May be used in sections :

defaults frontend listen backend yes yes no no yes yes yes yes Arguments : none When this option is set, a server which returns an HTTP code 404 will be excluded from further load-balancing, but will still receive persistent connections. This provides a very convenient method for Web administrators to perform a graceful shutdown of their servers. It is also important to note that a server which is detected as failed while it was in this mode will not generate an alert, just a notice. If the server responds 2xx or 3xx again, it will immediately be reinserted into the farm. The status on the stats page reports "NOLB" for a server in this mode. It is important to note that this option only works in conjunction with the "httpchk" option. If this option is used with "http-check expect", then it has precedence over it so that 404 responses will still be considered as soft-stop. See also : "option httpchk", "http-check expect" http-check expect [!] Make HTTP health checks consider response contents or specific status codes May be used in sections :

defaults frontend listen backend yes yes no no yes yes yes yes Arguments :

is a keyword indicating how to look for a specific pattern in the response. The keyword may be one of "status", "rstatus", "string", or "rstring". The keyword may be preceded by an exclamation mark ("!") to negate the match. Spaces are allowed between the exclamation mark and the keyword. See below for more details on the supported keywords.

is the pattern to look for. It may be a string or a regular expression. If the pattern contains spaces, they must be escaped with the usual backslash ('\'). By default, "option httpchk" considers that response statuses 2xx and 3xx are valid, and that others are invalid. When "http-check expect" is used, it defines what is considered valid or invalid. Only one "http-check" statement is supported in a backend. If a server fails to respond or times out, the check obviously fails. The available matches are :

status : test the exact string match for the HTTP status code. A health check response will be considered valid if the response's status code is exactly this string. If the "status" keyword is prefixed with "!", then the response will be considered invalid if the status code matches.

rstatus : test a regular expression for the HTTP status code. A health check response will be considered valid if the response's status code matches the expression. If the "rstatus" keyword is prefixed with "!", then the response will be considered invalid if the status code matches. This is mostly used to check for multiple codes.

string : test the exact string match in the HTTP response body. A health check response will be considered valid if the response's body contains this exact string. If the "string" keyword is prefixed with "!", then the response will be considered invalid if the body contains this string. This can be used to look for a mandatory word at the end of a dynamic page, or to detect a failure when a specific error appears on the check page (eg: a stack trace).

rstring : test a regular expression on the HTTP response body. A health check response will be considered valid if the response's body matches this expression. If the "rstring" keyword is prefixed with "!", then the response will be considered invalid if the body matches the expression. This can be used to look for a mandatory word at the end of a dynamic page, or to detect a failure when a specific error appears on the check page (eg: a stack trace).

It is important to note that the responses will be limited to a certain size defined by the global "tune.chksize" option, which defaults to 16384 bytes. Thus, too large responses may not contain the mandatory pattern when using "string" or "rstring". If a large response is absolutely required, it is possible to change the default max size by setting the global variable. However, it is worth keeping in mind that parsing very large responses can waste some CPU cycles, especially when regular expressions are used, and that it is always better to focus the checks on smaller resources.

Also "http-check expect" doesn't support HTTP keep-alive. Keep in mind that it will automatically append a "Connection: close" header, meaning that this header should not be present in the request provided by "option httpchk".

Last, if "http-check expect" is combined with "http-check disable-on-404", then this last one has precedence when the server responds with 404. Examples :

only accept status 200 as valid

http-check expect status 200

consider SQL errors as errors

http-check expect ! string SQL\ Error

consider status 5xx only as errors

http-check expect ! rstatus ^5

check that we have a correct hexadecimal tag before /html

http-check expect rstring <!--tag:[0-9a-f]*</html> See also : "option httpchk", "http-check disable-on-404" http-check send-state Enable emission of a state header with HTTP health checks May be used in sections :

defaults frontend listen backend yes yes no no yes yes yes yes Arguments : none When this option is set, haproxy will systematically send a special header "X-Haproxy-Server-State" with a list of parameters indicating to each server how they are seen by haproxy. This can be used for instance when a server is manipulated without access to haproxy and the operator needs to know whether haproxy still sees it up or not, or if the server is the last one in a farm.

The header is composed of fields delimited by semi-colons, the first of which is a word ("UP", "DOWN", "NOLB"), possibly followed by a number of valid checks on the total number before transition, just as appears in the stats interface. Next headers are in the form "=", indicating in no specific order some values available in the stats interface :

• a variable "address", containing the address of the backend server. This corresponds to the

  field in the server declaration. For unix domain sockets, it will read "unix".

• a variable "port", containing the port of the backend server. This corresponds to the field in the server declaration. For unix domain sockets, it will read "unix".

• a variable "name", containing the name of the backend followed by a slash ("/") then the name of the server. This can be used when a server is checked in multiple backends.

• a variable "node" containing the name of the haproxy node, as set in the global "node" variable, otherwise the system's hostname if unspecified.

• a variable "weight" indicating the weight of the server, a slash ("/") and the total weight of the farm (just counting usable servers). This helps to know if other servers are available to handle the load when this one fails.

• a variable "scur" indicating the current number of concurrent connections on the server, followed by a slash ("/") then the total number of connections on all servers of the same backend.

• a variable "qcur" indicating the current number of requests in the server's queue.

Example of a header received by the application server :

X-Haproxy-Server-State: UP 2/3; name=bck/srv2; node=lb1; weight=1/2; \ scur=13/22; qcur=0 See also : "option httpchk", "http-check disable-on-404"