Section – In-band Checks

In-band health checks are performed with each user request. Failing checks are tracked with a sliding average over the last 20 seconds, calculating the current failure rate. One single request can only impact the failure rate by a maximum of 5%. If more than 10% of the requests within that 20 seconds time window fail, Airlock Gateway marks the corresponding back-end server as "bad". If available, a spare back-end will now be brought on-line and take over traffic from the bad back-end. If no out-of-band health checks are configured, Airlock Gateway will then still send a small number of requests to a bad back-end server. If such a request still fails, it will then be diverted to a good back-end. As soon as one of those probe requests returns successfully, the back-end is set to "good" and will again be served normally. If a spare had been brought on-line previously, it will now be set to receive no further new sessions, but will still receive all traffic for its existing sessions. It is highly recommended to enable out-of-band health checks in order to avoid that any end-user requests are being sent to bad back-end servers.

Note: Connection-level errors such as connection timeouts and handshake failures will still mark back-end systems as "bad" even if "In-band Checks" are disabled.

To analyze the return status of the response, you can define a regular expression to match the response status code. Activate/deactivate the pattern by clicking on the gray/green button to the left of the pattern input field. This regular expression is always case insensitive, but can be inverted if required. If the response status code matches with the pattern, the request is counted as a failed request.

Examples:

^503$                   = interpret response status 503 as failed
^5                      = interpret response status 5xx as failed
^(200|3..)$, inverted   = only 200 and 3xx responses are expected, every other status is interpreted as a failure

It is also possible to analyze the response content to detect a back-end failure. For that, select check response content and enter a regular expression to match the response content your application returns when an error occurred.
Be aware that enabling response interpretation may slow down your application. The reason is that the response body is cached until enough data is available to decide whether the back-end server has failed or not.

The response body is parsed only if its content type matches the regular expression in this field. This regular expression is case insensitive.

Example:

^text/html$ (analyze only html documents)

If this regular expression matches against the response body, then the request is counted as a failed request. The regular expression can be configured to be either case sensitive or case insensitive.

This is the number of bytes that must be available before inspecting the response body. This data is cached and may increase latency. Therefore choose a reasonable number of bytes to reduce latency. Leave this field empty to search the whole response. You can use units: k(iloBytes), M(egaBytes) or G(igaBytes). Numbers that can be shortened, i.e 4096, will be shortened and displayed as 4k.