SharePoint 2013 HTTP Health Monitoring

HTTP 200 OK Response from the SP servers applications considered as healthy. Yes, we need to use NTLM to access the application pages. One thing that I would like to understand about the F5 HTTP monitoring is, is it capable of monitoring all the web applications through single GET string? In our case, we have five web applications published through the single virtual IP on F5, if we need to monitor all the five applications and making sure they are all up and running before F5 LTM passes the request, is it possible through the HTTP monitor? Our goal is to be able to monitor all the web applications on SharePoint servers ( Send the GET requests different web applications home pages .i.e. welcomePage.aspx, default.aspx and homepage.aspx) and making sure they are all healthy before passing the user request to the servers.

Not within a single HTTP monitor. I believe you'd necessarily need to use an external monitor for something like this. So, assuming you need all of the applications to be healthy to mark the server up, here's an example Bash script:

 these arguments supplied automatically for all external pingers:
 $1 = IP (::ffff:nnn.nnn.nnn.nnn notation or hostname)
 $2 = port (decimal, host byte order)

pidfile="/var/run/$MONITOR_NAME.$1..$2.pid"
if [ -f $pidfile ]
then
    kill -9 -`cat $pidfile` > /dev/null 2>&1
fi
echo "$$" > $pidfile

 Remove the IPv6/IPv4 compatibility prefix
node_ip=`echo $1 | sed 's/::ffff://'`

res=1

creds='domain\user:password'

curl -fNs -k -u $creds --ntlm https://$node_ip:$2/app1 |grep -i "app1-blah" 2>&1 > /dev/null
if [ $? -ne 0 ]; then res=0; fi

curl -fNs -k -u $creds --ntlm https://$node_ip:$2/test |grep -i "test-blah" 2>&1 > /dev/null
if [ $? -ne 0 ]; then res=0; fi

curl -fNs -k -u $creds --ntlm https://$node_ip:$2/blah |grep -i "blah-blah" 2>&1 > /dev/null
if [ $? -ne 0 ]; then res=0; fi

curl -fNs -k -u $creds --ntlm https://$node_ip:$2/bar |grep -i "bar-blah" 2>&1 > /dev/null
if [ $? -ne 0 ]; then res=0; fi

curl -fNs -k -u $creds --ntlm https://$node_ip:$2/foo |grep -i "foo-blah" 2>&1 > /dev/null
if [ $? -ne 0 ]; then res=0; fi

if [ $res -eq 1 ]
then
     Remove pidfile before script echoes anything to stdout and is killed by bigd
    rm -f $pidfile
    echo "up"
fi

rm -f $pidfile

iCall Script looks great, but I need some details on how to implement this in conjunction with iAPP SharePoint rule. Also noticed in that article that the BIG-IP needs to be on 11.4 or higher in order to get the iCall implemented. Ours is currently on BIG-IP 11.3.0 Build 3117.0 Hotfix HF5, not sure if its possible to update the Big-IP at this stage.

You can still do iCall-like functions with a user_alert.conf configuration, but in this case you need something to run periodically, which user_alert wouldn't do natively. The iCall script in Mike's response is basically TMSH scripting, so you could still technically run the code as an external monitor (with some modification).

We do have a software (WMI Based) for monitoring the websites in our environment. Last time when we had an outage on the SharePoint application (App pool down) the F5 was still passing the request to the servers 😞 without even marking that node is down.

Understand that in many cases an application can fail while the web server itself is still alive and well. I've even seen instances where the application failed and the web server still reported 200 OK. This is why, especially in complex environments like this, you should dive deeper into the application for monitoring. Don't just look for a 200 OK, but something that would only exist if the application was truly working.