F5 BIG-IP health checks and HTTP errors

When a web site or application becomes too large to run on a single server, it’s frequently placed on multiple servers with a load balancer in front of them to spread the load and also to remove faulty servers from the pool.

The F5 BIG-IP is one such load balancer.

To ensure that faulty servers are removed from the load balancer pool automatically, you need to set a health check (or monitor). These monitors poll the server every few seconds and based on what it receives can make decisions on whether to leave a server in a pool or mark it as faulty.

When monitoring web applications you create a http (or https) monitor, however the default out of the box behaviour is to check two conditions:

• That content is returned by the server.
• That the http/https port is open and responding.

Unfortunately applications can also fail in such a way that the above checks pass but the application is not available to the end user (eg: if it’s returning a 500 Internal Server Error). This will result in users intermittently receiving an error page, or worse – receiving an error page for an extended period of time if session persistence is turned on (ie: once a session is created, they’ll be directed to that one server).

To protect against this you need to create a new health check (monitor) that not only checks the above conditions, but also checks to ensure that the HTTP status code returned with the request is not an error code.

First of all you need to create a new HTTP monitor. You’ll have your typical send string (eg: HEAD / HTTP/1.0) but the receive string is what’s important.

Here’s the receive string I use:

HTTP/1.[01] [23]0[0-6]

This string will accept any returned HTTP status code from 200-206 and 300-306. Any error codes (ie: 4xx and 5xx) will result in the receive string not being matched and the check failing.

Here’s an example of the fully configured check:

You’ll note that I’m using HTTP/1.0 for the check despite HTTP/1.1 being the current version of the protocol. This is because I use the one health check across multiple clients, and HTTP/1.1 would require me to include a host header, eg:

HEAD / HTTP/1.1
Host: shaun.net
Connection: close

Using HTTP/1.0 (which does not support virtual hosts) eliminates this requirement and makes using a single check for many different clients much easier.

Once you’ve created your new monitor to your requirements you need to go to go the pool and add the new check.

After you’ve changed this, all you need to do is update the configuration and your new health check is active. If your application starts returning a 500 Internal Server Error, it should automatically be taken out of the pool within seconds!