HTTPMonitor_cURL_ProbeTimeout

removing http monitor makes no difference and I do need both.

 

I believe I did the tcpdump correct but I see see only one packet

 

Internal is 10.50.0.246 and is not the floating IP.

 

lb50-1:Active] / tcpdump -i internal:4000

 

tcpdump: WARNING: internal:4000: no IPv4 address assigned

 

tcpdump: listening on internal:4000

 

15:56:57.203234 802.1Q vlan4095 P0 tmm.9141 > localhost.localdomain.syslog: udp 64 (DF)

 

A full tcpdump from the GUI does not show any traffic either

 

I have also noticed doing a b load adds a second = in the GUI monitor variable secition

 

removing them makes no difference

 

 

Your tcpdump command line should be something like:

tcpdump -nni internal host  and port 4000

If you don't see any traffic, your monitor is not sending the expected request, and you need to fall back to the command line to verify the script is working as expected.

To test the script at the command line, first export the variables you have defined:

export RECV="w50-[12].c50.domain.com:6802 .ok."
export POOL="cwmp.stage.443"
export URI="/caucho-status"
export P_TIMEOUT="5"

Verify the expected values have been properly exported by running the "set" command and examining the output. Then run the monitor from the command line, supplying the pool member address and port to which the monitor traffic should be sent:

/usr/bin/monitors/curlcaucho 10.50.1.1 5004

If you see the word "UP", the monitor script is working as expected. (That should be the only output you ever see.)

If the pool member is up, but no output was seen from the script, run the script again with the shell debug flag set:

sh -x /usr/bin/monitors/curlcaucho 10.50.1.1 5004

and examine the output to determine what isn't working as expected.

HTH

/deb

The script echoes UP as it should but it does not mark the pools as UP in the GUI template.

This statement w50-[12].c50.domain.com:6802 .ok." says if it sees any page that has

w50-1 or w50-2.domain in it and echoes as up

My original script is correct in that I need it to run a for loop

for i in `seq 1 2`; do

curl -fNs -m ${P_TIMEOUT} http://w50-$i.c50.domain.com:${CAUCHOPORT}${URI} | grep -io "w50-$i"'.c50.domain.com:6802 .ok.' 2>&1 > /dev/null

It should only down the $i for each app server

Each status page will look like the example I posted

1. w50-1.c50.domain.com:6802 (ok)
0
15
15
30
2. w50-2.c50.domain.com:6802 (ok)
0

above is part of one app servers resiin page Each app server will list all of the app servers in the cluster.

as shown below

echo bigpipe pool ${POOL} member 10.50.1.$i up 2>&1 > /dev/null

else

echo bigpipe pool ${POOL} member 10.50.1.$i down 2>&1 > /dev/null

I was not able to get this to work

tcpdump -nni host and port 4000

I tried tcpdump -nni hostname 10.50.0.246:4000

tcpdump: Interface name too long. Vlan names longer than 15 characters must use vlan as the interface name

My original script is correct in that I need it to run a for loop

for i in `seq 1 2`; do

curl -fNs -m ${P_TIMEOUT} http://w50-$i.c50.domain.com:${CAUCHOPORT}${URI} | grep -io "w50-$i"'.c50.domain.com:6802 .ok.' 2>&1 > /dev/null

As I mentioned before, this approach may work fine for a standalone script intended to monitor multiple hosts, but that is not what you are trying to build here. What you need is an LTM monitor, and an LTM monitor script is really a template for monitoring a single pool member. Whether you apply an LTM monitor to an individual pool member or to the entire pool in the GUI, a separate copy of the monitor runs for each pool member, passing only that specific IP & port to be tested and maintaining only that single tested pool member's availability.

Since the provided monitor script returns the expected value when run from the command line, the next step is to apply it as an external monitor using the settings recommended previously, and look at a trace of the monitor traffic to see what's going wrong.

Your tcpdump command should include the interface name before the host IP & port:

tcpdump -nni internal host 10.50.0.246 and port 4000

There is a logical problem you're bound to encounter once you get the monitor working, though: Since all pool members' status will be reflected in the output of this script, and the wildcard expression in the current RECV string will match all instances of the reported status, each pool member will be marked UP if any of them are UP (IOW, you will only ever get a DOWN status using this script against this page if all servers are DOWN.)

To work around that, you'll need to make your RECV string something more specific per instance. Since the last octet of the IP address is the same as the host number value you need, you should be able to use this string as the new RECV string to substitute that value on the fly for each monitor instance:

w50-`echo $IP | cut -d. -f4`.c50.domain.com:6802 .ok.

Be sure to test the script itself at the command line as you did before to verify the intended functionality before defining it as an external monitor.

/deb

lb50-1-cs:Active] monitors tcpdump -nni internal host 10.50.0.246 and port 4000

 

tcpdump: listening on internal

 

 

0 packets received by filter

 

0 packets dropped by kernel

 

running tcp dump while curl caucho is enabled gives no packets

 

 

If I enable the following export then the script works

 

The IP export must be added first because the script does run manually does not determine the IP based on

 

this command

 

IP=`echo ${1} | sed 's/::ffff://'`

 

 

export IP="10.50.1.1"

 

export RECV="w50-`echo $IP | cut -d. -f4`.c50.domain.com:6802 .ok."

 

export POOL="cwmp.stage.80"

 

export URI="/caucho-status"

 

export P_TIMEOUT="5"

 

export CAUCHOPORT=4000

 

 

[root@lb50-1-cs:Active] monitors sh -xv /usr/bin/monitors/curlcaucho 10.50.1.1 4004

 

remove IPv6/IPv4 compatibility prefix (LTM passes addresses in IPv6 format)

 

IP=`echo ${1} | sed 's/::ffff://'`

 

echo ${1} | sed 's/::ffff://'

 

++ echo 10.50.1.1

 

++ sed s/::ffff://

 

+ IP=10.50.1.1

 

PORT=${2}

 

+ PORT=4004

 

RECV="w50-$i"'.c50.domain.com:6802 .ok.'

 

PIDFILE="/var/run/`basename ${0}`.${IP}_${PORT}.pid"

 

basename ${0}

 

++ basename /usr/bin/monitors/curlcaucho

 

+ PIDFILE=/var/run/curlcaucho.10.50.1.1_4004.pid

 

kill of the last instance of this monitor if hung and log current pid

 

if [ -f $PIDFILE ]

 

then

 

kill -9 `cat $PIDFILE` > /dev/null 2>&1

 

fi

 

+ '[' -f /var/run/curlcaucho.10.50.1.1_4004.pid ']'

 

echo "$$" > $PIDFILE

 

+ echo 4737

 

send request & check for expected response

 

for i in `seq 1 2`; do

 

curl -fNs -m ${P_TIMEOUT} http://${IP}:${CAUCHOPORT}${URI} | grep -io "${RECV}" 2>&1 > /dev/null

 

+ curl -fNs -m 5 http://10.50.1.1:4000/caucho-status

 

+ grep -io 'w50-1.c50.domain.com:6802 .ok.'

 

 

let bigd mark node UP if expected response was received

 

otherwise force the node DOWN immediately

 

if [ $? -eq 0 ]

 

then

 

echo "UP"

 

else

 

echo /bin/bigpipe pool ${POOL} member ${IP}:${PORT} down 2>&1 > /dev/null

 

fi

 

+ '[' 0 -eq 0 ']'

 

+ echo UP

 

UP

 

 

rm -f $PIDFILE

 

+ rm -f /var/run/curlcaucho.10.50.1.1_4004.pid

 

exit

 

+ exit

Oh, IP and PORT should have been on the export list for command line testing. Probably a cut & paste error on my part, sorry about that.

 

 

Geez, not sure what I was thinking here -- IP & port are specified as command line arguments as indicated in the command above... Neither needs to be set as an env var if they are properly specified on the command line when running the script manually.

 

 

So it looks like it's working as expected. Did you have another question...?

 

 

/deb

 

 

 

It only works manually It does not work with the variables in the template

 

I see no traffic when I run

 

lb50-1-cs:Active] monitors tcpdump -nni internal host 10.50.0.246 and port 4000

 

tcpdump: listening on internal

 

 

0 packets received by filter

 

0 packets dropped by kernel

 

running tcp dump while curl caucho is enabled gives no packet

 

I don't think it is parsing $1 and $2 automatically

Do you see the traffic with the same tcpdump filter when testing from the command line?

 

 

Please post your current monitor definition (output from "b list monitor " )

 

 

/d

If you're not seeing the traffic in a trace in either case, perhaps you have the wrong self IP in the tcpdump filter. You can change it to the IP address of the pool member you are testing against (10.50.1.1) and see if you can see the target traffic then.

 

 

/deb

I had always had it an external monitor because the page is longer than 5120 bytes

 

I have tried it on cwmp.stage.443 and cwmp.stage.80

 

no difference

 

b list monitor curlcaucho did not work but the below did

 

[root@lb50-1-cs:Active] monitors b monitor curlcaucho list

 

monitor curlcaucho {

 

defaults from external

 

dest *:4000

 

POOL "cwmp.stage.80"

 

PORT "4004"

 

P_TIMEOUT "5"

 

RECV "w50-`echo $IP | cut -d. -f4`.c50.domain.com:6802 (ok)"

 

run "curlcaucho"

 

URI "/caucho-status"

 

}

 

not sure if I did this correct but I don't get anything

 

tcpdump -nni internal host 10.50.1.1 and port 4000

 

tcpdump: listening on internal

 

 

0 packets received by filter

 

0 packets dropped by kernel