F5 Labs : Customize HTTP Monitors

In the world of load balancing, sending traffic to a healthy server is key.

But how does the F5 BIG-IP know if a web server is “healthy”?

Enter the HTTP monitor, a customizable tool that checks whether your backend servers are ready to handle requests. In this lab, the goal isn’t to break things (yet!) but to build a precise, well-tuned HTTP monitor from the ground up.

Objectives

Create a custom HTTP monitor to correctly monitor a pool of web servers

Observe the impact of customizations on the default HTTP monitor.

Learn when to use which version of the HTTP protocol and its headers.

Build a correct send string and receive string.

Pre-requisites

Complete the initial lab building tutorial

Download and apply the base configuration file : link to ucs

Tasks

Credential list :

F5 Big IP :

Username : admin (web ui) / root (cli)

Password : MyLabs789$

Web Viewer VM :

Username : labs

Password : labs

Web Server VM :

Username : labs

Password : labs

Task 1 : Create the virtual server and pool

Create the virtual server and pool as follow :

Virtual Server name	Virtual Server IP:port
BigBrother_vs	192.168.110.101:80

Detail of the virtual server to create

Pool member server name	Pool member IP:port
Server Red	192.168.120.2:80
Server Blue	192.168.120.3:80
Server Green	192.168.120.4:80

Detail of the pool “BigBrother_pool” to create

Using the webviewer VM, make sure the virtual server is accessible on http://192.168.110.101.

Task 2 : Create a customized HTTP monitor

On the first Task, you created a pool that is either not monitored, or uses a default monitor (http / tcp ). In this task, you will create a customized HTTP monitor so that the Big IP can better monitor and adapt to the client/server behavior.

Create a custom monitor derived from the HTTP monitor. Let all the default value. Attach it to your pool.

Go to Local Traffc > Monitor to create a new monitor. In the “type” field, select http to inherit from the default http monitor :

Create a http monitor

Attach the monitor by going to the Local Traffic > Pool menu. Enter your pool. Make sure that in the monitor list the BigBrother_mon is enabled on the left list and is the only monitor. Remove any previous monitor by moving them to the right list.

Attach monitor to a pool

Are the servers marked "available" (green) ?

Yes the servers are marked green. The custom monitor inherit all the value of the default http monitor. Since the default http monitor marks the servers available, the custom monitor also marks the pool as available.

The default monitor send a basic HTTP GET request to the root of the webserver.

Task 3 : The angry system administrator

The administrator of the backend server is flooded every 5 seconds with your monitor in his logs. He wants you to add a header “User-Agent” in your monitor so he can differentiate the monitor traffic from real users.

This can be done using the send string of the monitor. Modify the monitor to add a header of User-agent as follow :

GET /\r\nUser-agent: BigIP\r\n

Connect to the WebserverVM using ssh. Use the following command to check the Nginx log :

tail -f /var/log/nginx/acces.log

This command display every connection to the webserver, this include the monitor of the Big IP every 5 seconds by default.

Does the log mention the User-Agent value for the monitor ? Is it mentionned with a regular acces using the web viewer VM ? Why is there a difference ?

In the log there is there is mention of the User-agent when the virtual server is accessed using the Web Viewer VM :

labs@webserver:/var/log/nginx$ tail -f access.log
192.168.110.2 – – [13/Oct/2024:12:05:50 +0000] “GET / HTTP/1.1” 200 766 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0“

However, for the monitor traffic, the User Agent is not logged :

192.168.120.254 – – [13/Oct/2024:12:05:52 +0000] “GET /” 200 1480 “-” “-“

By default, the Bip IP is using the HTTP 0.9 version if no version is specified. However, HTTP 0.9 does not allow headers. The monitor must be at least HTTP 1.0 to include the header User-Agent.

Modify the HTTP monitor so that it uses HTTP 1.0 protocol. Is the log displaying the user agent of the monitor?

Add the HTTP 1.0 protocol by adding the HTTP/1.0 string :

GET / HTTP/1.0\r\nUser-agent: BigIP\r\n\r\n

Since we are now using HTTP 1.0 version, each header should be ended with a carriage return and a line feed (\r\n). To indicate that the request is complete, complete the line with a double carriage return/line feed (\r\n\r\n).

The server log now display the user agent in the log.

192.168.120.254 – – [13/Oct/2024:13:08:01 +0000] “GET / HTTP/1.0” 200 1486 “-” “BigIP“

Task 4 : The still angry system administrator

The system administrator is again at your desk asking for some modifications on your monitor. He wants that you monitor a special page and not the root page of the website. He sends you an email with the name of the page “/isitready.html”.

Modify the monitor to check the /isitready.html page.

Modify the send string to /isitready.html on the monitor configuration page:

GET /isitready.html HTTP/1.0\r\nUser-agent: BigIP\r\n\r\n

What is the status of the pool ?

The pool is marked available :

BigBrother pool status

Does this page exist ? What is the HTTP return code for this page ? Why is the pool marked as available ?

This page does not exist. Using the webviewer accessing this page return a 404 error :

404 error page

There is nothing specified on the Receive String field of the monitor. As long as there is an aswer to the request, the pool will be marked available. This includes errors pages aswell. A 404 error page can mark a monitor as available.

Modify the monitor so that the pool is marked available only if there is a return code 200. Is the pool available ?

Modify the receive string so that it contains the value “200”. Page without the request code “200” will be marked as unavailable.

Upon this modification, the pool is now marked as unavailable :

Big Brother pool unavailable

The system administrator made a mistake, and the page to monitor the service is the page /isitup.html .

Modify the monitor so that it requests the page /isitup.html. Is the pool available ? Why ?

Modify the send string to :

GET /isitup.html HTTP/1.0\r\nUser-agent: BigIP\r\n\r\n

Now that the Big IP monitor a real page return status code 200, the monitor marks the pool as available.

Task 5 : The still over-angry system administrator

The server administrators wants you to instruct the server to directly close the connection as soon as the request is made by the monitor. This is so that the server doesn’t keep a TCP connection since no further HTTP request will be done.

Which header should be added ?

The header “Connection” should be added with the value close. This instruct the server to immediatly close the connection one the HTTP request is served.

Surprisingly, the system administrator studied the HTTP protocol in his youth. He recalls you that the header Connection is a HTTP 1.1 header.

Upgrade your custom monitor so that it uses HTTP 1.1 version and the Connection: close header.

When you modify only the HTTP version to 1.1 with the header Connection, is the pool marked available with this monitor ? Why ?

First, modify the send string so that the HTTP version used is now 1.1 :

GET /isitup.html HTTP/1.1\r\nUser-agent: BigIP\r\n\r\n

After that, add a header Connection with the close value :

GET /isitup.html HTTP/1.1\r\nUser-agent: BigIP\r\nConnection: close\r\n\r\n

Now the pool is marked unavailable. HTTP version 1.1 require the request to have a host header. Without the header host, the HTTP1.1 request is invalid and the backend server respond with an error 400.

Add the Host header with a value of "192.168.110.101". Is the pool marked available ?

Add the host header:

GET /isitup.html HTTP/1.1\r\nHost: 192.168.110.101\r\nUser-agent: BigIP\r\nConnection: close\r\n\r\n

Once the host header is added, the pool is marked avaiable.

Conclusion

Congratulations! You’ve successfully configured an HTTP monitor, gaining insight into the building blocks of a solid health check. As you’ve seen, the HTTP protocol version plays a crucial role—whether it’s HTTP/0.9, HTTP/1, or HTTP/1.1 choosing the right version ensures that your monitor speaks the same language as your servers. Old versions does not allow everything !

We also explored the significance of HTTP status codes—a well-designed monitor knows to expect a 200 OK or any other success code, but ensure this is the expected one. Don’t forget the headers! They can carry important information, like the hostname (mandatory in HTTP 1.1).

Fine-tuning these elements ensures your F5 BIG-IP device can reliably determine when a server is ready to receive traffic—and when it’s time to step aside. With your newfound knowledge, you’re ready to build monitors that deliver precise insights and help your applications run smoothly.

Building Custom HTTP Monitors