Forum Discussion
J_W__Koebel_442
Nimbostratus
NimbostratusMonitors Won't Check HTTP Status Code
Hi everyone,
I'm trying to revise our currently lacking health monitors to keep better track of the status of each node. We run JBoss servlets on top of Tomcat to serve up a web application over HTTP; occasionally Java errors cause the application to crash on one node. Currently we don't have any way of detecting this; the receive string on our monitors is blank and they accept any response as valid.
I'm trying to get the health monitors to only mark a pool member as "good" if the HTTP status code is 200.
Here's what I'm checking:
SEND String: "GET /Jakarta/Login.do HTTP/1.1\r\n\nHost:\r\n\nConnection: close\r\n\r\n"
RECEIVE String: "HTTP/1.1 200 OK"
I verified using CURL that the proper codes are being set.
curl http://10.32.41.245:30200/Jakarta/Login.do -I
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)/Tomcat-5.5
Set-Cookie: JSESSIONID=2327E0E333F2697DEB355CB9685DC811;
Content-Type: text/html;charset=UTF-8
Content-Length: 6868
Date: Thu, 10 Dec 2009 00:10:56 GMT
And yet....my health monitor marks the pool as "down" in that configuration.
If I make the RECEIVE string "200" by itself, it marks the pool as "up" even when it is CLEARLY down, as in this case:
SEND String: "GET /Jakarta/Login.do HTTP/1.1\r\n\nHost:\r\n\nConnection: close\r\n\r\n"
RECEIVE String: "200"
pool members marked "up", but the server itself is responding that it's dead:
curl http://10.32.41.245:30200/Jakarta/Login.do -I
HTTP/1.1 404 Servlet action is not available
Server: Apache-Coyote/1.1
ETag: W/"743-1254223556000"
Last-Modified: Tue, 29 Sep 2009 11:25:56 GMT
Content-Type: text/html
Content-Length: 743
Date: Thu, 10 Dec 2009 00:08:31 GMT
Any thoughts?
- For your first example, you probably want to leave off the last \r\n or two, as the monitoring software will add them for you; the extras may be confusing your web server.
That said, it would probably be good to do a tcpdump on your BIG-IP to see what data your server is sending it. You could also set the bigd.debug DB variable to enable, and then check to see what information /var/log/bigdlog contains. That could at least help you narrow down the problem.
As for your second example, it does contain the string "200". It's in the Last-Modified line, just after "29 Sep". That explains why it is reported as UP. 
J_W__Koebel_442As for your second example, it does contain the string "200". It's in the Last-Modified line, just after "29 Sep". That explains why it is reported as UP.
Duh. It matches inside of tokens, not just entire tokens. Okay, that's one mystery solved.
I'll go forward with the logging idea, thanks for the suggestion! I'm relatively new to F5, so this is a bit of a learning experience for me.
hoolioCirrostratus
I'd also guess it's the \r\n's on the end of the send string causing the app to send a 400 response back to the client. You could confirm this by checking the web server logs or running a tcpdump on LTM filtering for the static self IP and pool member IP.
You can use a receive string like this to check for an HTTP 1.0 or HTTP 1.1 200 OK response:
HTTP/1\.(0|1) 200 OK
Or more simply, '200 OK' will usually do fine. 200 on its own will match the year in the Date header (or the Last-Modified header.
Aaron- J_W__Koebel_442You guys were right: the invalid SEND string was making the server return 400. It was actually two things. I removed one set of the trailing \r\n, but it was still erroring. Reading it more carefully again, I noticed something: "\r\n\n" in the middle.
Whoever wrote these in the first place, added an extra \n where there shouldn't have been apparently. I removed those extra \n and it works great now!
Thanks so much for the help guys. Having an extra set of eyes on this one really helped.
