Forum Discussion

Lightspeed_VT_5's avatar
Lightspeed_VT_5
Icon for Nimbostratus rankNimbostratus
May 22, 2008

Monitor flapping

While reviewing today's "ltm" logfile on our LTM 1500, I see random monitor flapping for reasons I can't determine. When the flaps happen, all application users lose their session.

 

 

I'm using an HTTP health monitor with a send string that looks for GET /myfile.cfm. I'm not looking for a receive string, so maybe that might help.

 

 

The back-end webservers are IIS 6.0.

 

 

Is this the best monitoring choice, or would something like WMI be less volatile?

 

 

TIA,

 

 

Keith

 

 

3 Replies

  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    The HTTP monitor is the best choice for webserver monitoring.

    You should add a Receive string, but I don't think that's the issue here: Not specifying a receive string simply means you would get false positives (UP when it isn't really), rather than false negatives, since ANY response will mark the pool member UP.

    Have you lowered the interval / timeout values from the default? If so, I'd look for slow responses.

    You might also try using a more specific request string that includes the HTTP version, host header, & connection: close options, as in AskF5 Solution 3224: Click here

    GET /myfile.cfm HTTP/1.1\nHost: \nConnection: Close\n

    hth

    /deb

  • Thanks for the reply, deb.

     

     

    I did alter the send string to call a web page like so: GET /keepalive.aspx but didn't have the connection close parameter as you've indicated.

     

     

    I set the interval for 30 seconds and the timeout to 91 seconds.

     

     

    This eliminated the flapping issue or the most part, but it would still occur a few times a day.

     

     

    A cheesy fix was to add a TCP health monitor as a secondary check and the flapping has ceased.

     

     

    However, there have been instances where the machine was still up, but the application was not. This obviously creates problems because the machine with the app error stays in the mix.

     

     

    I'll try your idea of using an HTTP header instead and see what happens.