HTTPMonitor_cURL_ProbeTimeout

OK, wiki page is updated to indicate the correct directory, sorry for the confusion there.

 

 

Now as far as your variables are concerned, you need either set them in the monitor definition as name/value pairs OR set them within the script. If you do both, your monitor settings will be ignored and the script values will be used for every instance of the script. In this case, since they are the same, that isn't the problem. (Also, if your pool members are defined on port 4000 already, you don't need to specify that as a variable value in either place.)

 

 

I'm not sure I understand your intention regarding the argument you've specified, but since your script doesn't look for any arguments (passed as $3 or greater), eliminate all arguments from the monitor definition.

 

 

LTM by default isn't configured for name resolution, and even if it were, resolving a name within a monitor is not recommended since the induced latency will most likely result in intermittent false down's.

 

 

You also have not included the required LTMv9 IP address parsing line. (This is the most likely reason your monitor is failing -- no valid destination address. I bet if you looked at a trace, you'd see no monitor traffic.)

 

 

I didn't notice reading your script before, but it seems to be using a for loop to check both pool members, and the loop is terminated in the wrong place for proper pidfile management. You are also using a bigpipe command to manipulate the node status. Neither approach represents how LTM monitors are intended to work, and both of them will interfere with the normal operation of the monitor.

 

 

Hold on & I'll post a script that will work and the monitor definition to deploy it...

 

 

/deb