iband monitor

As a follow up, I think the article http://devcentral.f5.com/weblogs/amurphy/archive/2009/04/09/5933.aspx has some killer stuff in it but there's some potential for confusion. From my understanding, you can achieve all of this as laid out in the post, but not quite with inband aloe. The author mentions combining both active and passive, which is pretty much what we're thinking of doing here for your issue. This is where much of the power for inband monitors lies, by the way - "passively" monitoring real user connections, but also with the ability to fall back to an active monitor issued by the LTM. Throw in some iRules magic and you're really dealing with some sophistication!

 

 

For example, it's entirely possible for you to:

 

 

1) Mark a member down on the 500 response. Use an active HTTP health check with a receive string for this.

 

 

2) Keep track of the application traffic overall at the tcp level with inband monitors. If an app server sends RST or stops responding to connection requests, it'll flag it as down, or fall back to an active monitor for further validation.

 

 

3) Retry your request to another pool member on your 500 error - this is done via an iRule. Run a search for the HTTP::retry command for ideas or re-post if you are interested in doing this.

 

 

-Matt