Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.
Historic F5 Account

I’ve participated in and inherited quite a few WA (WebAccelerator) deployments during my tenure at F5. One pet peeve I have and I see it again and again: dirty performance reports! Take a look at the image below and you’ll notice that solid red line section of the bar graph at the bottom of the chart. Those are errors and they are too consistent to be user produced.




A small baseline of errors is expected as there is always someone out there trying to forcefully browse the site or possibly a broken link, etc. These non-user-produced errors in the chart above however are almost always caused by an incorrect HTTP monitor. In a lot of cases, an administrator will point a plain HTTP monitor from their LTM at a WA virtual server and walk away. We all know that WA uses hostnames to determine the appropriate acceleration policy to apply to the incoming traffic. Without a host header the WA will respond with a HTTP 400 (Bad Request) and the monitor will be marked up, because it did receive a “valid response”. This has two consequences: not knowing the true health of our application and our performance reports will be marred by lots of errors.

In order to remedy this, we need to build a more intelligent HTTP monitor that provides a valid host header. I would also recommend a more intelligent monitor than a plain HTTP, but more on that next time. In order to do that, we need to login to our LTM user interface and navigate to “Local Traffic > Monitors > Create”. Name your monitor something intuitive (mysite.example.com_http), you can change the interval and timeout parameters to suit your needs, now here’s where the magic happens: the send string.

GET /index.html HTTP/1.1\r\nHost:\r\nConnection: Close\r\n\r\n

You can set the receive string to something you expect to receive from index.html every time or leave it blank. Keep in mind that by leaving it blank, you still have the same case as mentioned previously whereby any HTTP response is considered valid. Either way, the errors will be removed from the performance charts making things a lot prettier. If all went well, your performance reports should start to look more like the one below.


Version history
Last update:
‎18-Aug-2010 16:10
Updated by: