SharePoint 2013 HTTP Health Monitoring

UAG is Windows software running on a Windows server, usually in a DMZ. I've always been amazed how that idea doesn't scare the pants off of IA folk. A BIG-IP, on the other hand, is a default-deny, hardened security appliance. It may not have the inside knowledge that UAG may have on the health of a SharePoint environment, but it makes up for that in security and flexibility. That lack of internal introspection means that BIG-IP, like any ADC vendor's technology (other than UAG of course), cannot see things like resource utilization, CPU usage, and app pool thread counts. From the outside you can make a request to a service and use the service's response as basis for health status. If you think about it, that's not really a bad thing.

Can you provide this resource? Yes? Okay you're good until the next health check. 

Additionally, some of the more advanced LTM load balancing algorithms can look at things like TCP session counts and response latency, and actually help to stear traffic away from servers that appear to be having problems. The SharePoint iApp uses a very simple health monitor, most likely because 1) it's almost guaranteed not to break, and 2) the SharePoint environment can get so complex and so customized that there's simply no way to predict the best way to evaluate health. It's definitely not the best it can be, but the tools are there to make it better. For example, you could modify the monitor to do something like GET /Pages/Default.aspx, use NTLM credentials, and look for some specific attribute in the response payload. If you want to get crazy complex, you can use an external monitor, put on your Bash scripting hat (or Perl, Python, TCL, etc.) and make something that can log in, consume cookies, run queries, and do all sorts of things that would only be possible if the SharePoint server were truly healthy. And then you could simply look at this from SharePoint's perspective. What better place to know the true health and availability of a SharePoint server but the SharePoint server itself. You could, for example, built an ASP.NET page that queries various aspects of the environment (resource utilization, CPU usage, app pool thread counts, database connectivity, you name it) and then simply report "good", "bad", or something in between to a basic HTTP GET health monitor. I know this didn't exactly answer your question, so:

1. The current basic HTTP monitor has the following send string GET /\r\n (it doesn't have any application URL's) and we are not sure 100% if this is correct and it will monitor all the web applications?

The best way to make this monitor better is to know your SharePoint environment. What kind of HTTP request will truly identify a healthy (or unhealthy) SharePoint server? What URI is only available, or what response payload is only given if the SharePoint server is up and running? Do you need to provide credentials to make a request?

1. How do we configure the HTTP monitor to improve the load balancing for SharePoint web applications? Please provide me the examples and also the way to test the monitor and make sure they are working as expected.

Health monitoring and load balancing are tightly integrated, but still two different things. A load balancing decision is made based on all sorts of available data, one of which being the basic health and availability of a server based on monitoring. Using something better than Round Robin load balancing is your best first step. Least Connections and Observed methods are popular.

1. Also noticed the latest iAPP templates for SharePoint http://support.f5.com/kb/en-us/solutions/public/15000/000/sol15043.html, does it have any specific improvements to monitoring?

I don't believe the health monitors have specifically changed in the latest iApp, but given what I've already discussed, you're going to want to change it anyway.