iband monitor

I think the problem here may be that a 500 error is a valid server response so you're not getting the behavior you expect. I would suggest using a normal HTTP monitor here. Oh, and be sure and use a good receive string, or you'll get the same results...

 

 

-Matt

Already using http monitor,just trying to use passive monitoring and white paper noted that error responses acn be gathered by inband monitor.

 

 

any idea ?

While extremely useful, inband doesn't monitor above layer 4. For example, if your server stopped responding or was sending tcp RSTs, you'd see it flagged as down. As it stands, your tcp-level chatter is 'healthy' to the inband monitor - after all, a 500 ISE is an application response of an application event; well above tcp level stuff. On other words: inband monitors don't actually seek out specific application data (here an HTTP response).

 

 

For application data like that, you'll want to use an HTTP monitor to deal with the HTTP responses you expect and don't expect.

 

 

I hope this helps.

 

 

-Matt

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

I'm not sure exactly when it was added, but in 9.4.7 (and possibly earlier) you can also configure the fallback host to be used for specific HTTP status codes like a 50x:

 

 

 

Fallback on Error Codes

 

 

Type the HTTP error codes from server responses that should trigger a redirection to the fallback host. Typical error codes are 500, 501, and 502. If you are specifying more than one code, separate the codes with a blank space, such as 500 501 502. You can also specify a range of error codes, as in this example: 505-515.

 

 

 

 

Aaron

Great point hoolio, thanks. @ysungur this is yet another option available to you. In this case the LTM will issue a redirect to the fallback host as defined in the fallback host field in the HTTP profile for this particular virtual server.

 

 

-Matt

 

option 2 of l4l7 's reply seems the most effective and efficent one.But hoolio made a nice point about fallback host directive while I think of it as a error page replacement.

 

 

I hope they modify inband monitor so that it can catch the application errors, they already have this capability on "fallback host" directive.

 

 

 

thank you guys,

 

As Matt suggested, the inband monitor only applies at layer 4. It wouldn't necessarily make sense to try to check a layer 7 application response code for this. You could argue for a layer 7 inband monitor which marks the pool member down on specific response codes.

 

 

Though this is generally too strict for most customer's applications as you wouldn't want to consider a server down if it generates a single HTTP 500 response. Marking a member down on a specific response code in a potential new monitor type or in an iRule would probably open yourself up to a denial of service scenario if a single attacker can trigger an HTTP 500 from each server in the pool by crafting a bad request.

 

 

Aaron

Question about the inband monitor: if you set the retry timer to 0, will the inband monitor will not start to retry to connect to th system, so it will keep it as down? How can you get the poolmember back up again?

Posted By EmBee on 08/23/2010 05:00 AM

 

Question about the inband monitor: if you set the retry timer to 0, will the inband monitor will not start to retry to connect to th system, so it will keep it as down? How can you get the poolmember back up again?

 

 

It will indeed stay down. You need an active monitor to mark it up.