Better F5 BIG-IP Health Monitor

In the VIP we created in the basic load balancing virtual, we used the default TCP F5 BIG-IP health monitor. Although its not terrible, its not really a great monitor. Same applies to the default HTTP monitor. Take a look below at the configuration of the default:

HTTP monitor
Default F5 BIG-IP Health Monitor for HTTP

Most of the options here should be pretty self explanatory, but if you ever need to get some quick info, try the help tab next to the main menu.

F5 BIG-IP help tab
The Help page is actually pretty useful

You’ll see that we’re just sending a really basic GET request to / with no headers. We’re also not checking for anything in the “Receive String.” What does this amount to? Well it basically is just a TCP monitor. Even if the web server responds back with a 404 or a 500 error, we’d still mark the web server as being available?

Static Monitor

A better monitor would be to set a specific page on your web server, with a specific word or string of characters that you can search for in the response. For example:

A custom HTTP monitor
Custom F5 BIG-IP Health Monitor for a static page

This would be a much better monitor. We’re checking for a specific page, and then furthermore, within that page the actual content. Be careful though, if a new guy joins the team, and starts “cleaning” things up, I’ve seen people delete health check files and take their servers out of the F5 accidentally!

Better Monitor

So that is a pretty good monitor for a static site, and much better than the default, but most sites are dynamic now. Taking the same concept a bit further, you could perhaps have a lightweight database call that would make sure your app is truly working and not just the web server daemon. Again, caveats apply, you don’t want to do something that is going to generate a lot of overhead and take out or cause excessive use of your database.

Remember you’ll be doing your health checks every couple of seconds, and if you have a highly available setup, each F5 will be doing those checks, so you might end up having that page hit every second or so! Here’s a basic example below. I’m not specifically recommending this for various reasons. I’m not a web programmer, so there’s probably a better way to do it. It’s just to give you an idea of the possibilities:

Using this php file, we connect to the database and just check that we connected successfully. You can test this on the command line by typing php file.php. We’ve put it in the same directory as our static page.

$servername = "db-host";
$username = "db-user";
$password = "db-pass";

//Create connection
$conn = mysqli_connect($servername, $username, $password);
//Check Connection
if (!$conn) {
  die("Connection failed: " . mysqli_connect_error());
echo "Connected Successfully - f5_db_healthcheck";

Next, we create a monitor on the F5 to check for this. I’m going to set the monitor to 60 seconds with 181 to fail so it isn’t hitting the database as much.


This applies to any service that you have running through the F5. If you for instance were load balancing LDAP, you’d want to craft a health check that is actually verifying the health of those servers, not just that the port is available, or that the server is up!

Leave a Reply

Your email address will not be published. Required fields are marked *