Ace HTTP Probe expect regex

Unanswered Question
Jan 11th, 2008
User Badges:

Hi,


I have a question about the config of the ACe probe.


I have the following probe defined :


probe http P_HTTP_TEST

interval 5

passdetect interval 2

passdetect count 2

request method get url /test

expect status 200 200

expect regex trululu



I would like to use the regex just like the expect string on the csm probe...


The regex doesn't seem to work as the strin trululu is not on the page tested.


I guess the expect status override the regex but without the expect status it doesn't work either.


Anyone know how exactly the probe expect works for http ?



Another question, on the CSM module, the tcp probe by default use the real port for the probe, not the default port of the probe type, is it possible to change that so it mimmicks the CSM way of working ?


Thanks a lot ;-)


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Gilles Dufour Fri, 01/11/2008 - 01:24
User Badges:
  • Cisco Employee,

your config works for me


http method : GET

http url : /small.html

conn termination : GRACEFUL

expect offset : 0 , open timeout : 10

expect regex : trululu

send data : -

--------------------- probe results --------------------

probe association probed-address probes failed passed health

------------------- ---------------+----------+----------+----------+-------

serverfarm : linux1-80

real : linux1[80]

192.168.30.27 2 2 0 FAILED


Socket state : CLOSED

No. Passed states : 0 No. Failed states : 1

No. Probes skipped : 0 Last status code : 200

No. Out of Sockets : 0 No. Internal error: 0

Last disconnect err : User defined Reg-Exp was not found in Host Response

Last probe time : Fri Jan 11 08:57:55 2008

Last fail time : Fri Jan 11 08:57:50 2008



See the last disconnect error.

Get the same output as me and see the status of your probe - share with us if still not working.


We're not going to change the current behavior.

If you want the ACE module to use the port of the real server, do not specify the port in the probe configuration.

If you do specify a port, it will override the one of the real.

BTW, this is the same behavior on the CSM.


Gilles.

csco10387876 Fri, 01/11/2008 - 01:42
User Badges:

here is what I get :


Current config :

probe http P_HTTP_TEST

interval 5

passdetect interval 2

passdetect count 2

request method get url /test

expect regex trululu


sh probe P_HTTP_TEST detail


probe : P_HTTP_TEST

type : HTTP, state : ACTIVE

description :

----------------------------------------------

port : 80 address : 0.0.0.0 addr type : -

interval : 5 pass intvl : 2 pass count : 2

fail count: 3 recv timeout: 10


http method : GET

http url : /test

conn termination : GRACEFUL

expect offset : 0 , open timeout : 10

expect regex : trululu

send data : -

--------------------- probe results --------------------

probe association probed-address probes failed passed health

------------------- ---------------+----------+----------+----------+-------

real : R_xxx[0]

serverfarm: SF_xxx_TEST

10.xx.0.xx 39 39 0 FAILED


Socket state : CLOSED

No. Passed states : 0 No. Failed states : 1

No. Probes skipped : 0 Last status code : 0

No. Out of Sockets : 0 No. Internal error: 0

Last disconnect err : Received invalid status code

Last probe time : Fri Jan 11 09:37:58 2008

Last fail time : Fri Jan 11 09:36:40 2008

Last active time : Never



for de default tcp port, on the documentation there is a list that says the default tcp port used is 80, if I have a real listening to port 8080, and I try to put the probe either on the serverfarm or the real itself, I see tcp connection on the 80 port instead of the 8080 port. Strange, maybe os bug.


my default tcp probe is :


probe tcp P_TCP_DEFAULT

description probe defaut pour tcp

interval 5

passdetect interval 2

passdetect count 2



thanks for your help.


What is strange is that the http probe when I remove the expect status, the failed reason is still a invalid code and not "User defined Reg-Exp was not found in Host Response"



strange ;-) (I always have strange things with those Lb)


Gilles Dufour Fri, 01/11/2008 - 02:41
User Badges:
  • Cisco Employee,

if you only want the regexp to be considered for success or failure, configure an 'expect status 0 999' to permit all status code.

The regexp is only applied after the status matched the expect status.


Regarding your probe, could you show the serverfarm to which you applied the probe and a 'show probe name P_TCP_DEFAULT detail'


Thanks,


Gilles.

csco10387876 Fri, 01/11/2008 - 02:46
User Badges:

here is a sample :

serverfarm : SF_INTRAMUROS_PRD_WWW

real : R_ANUBIS[8082]

10.6.103.47 2108020 2108020 0 FAILED


Socket state : CLOSED

No. Passed states : 0 No. Failed states : 1

No. Probes skipped : 1060 Last status code : 0

No. Out of Sockets : 0 No. Internal error: 0

Last disconnect err : Connection refused by server

Last probe time : Fri Jan 11 10:42:58 2008

Last fail time : Fri Nov 23 14:54:13 2007

Last active time : Never



do you have any idea why the expect regex doesn't work and return a invalid status code insteand of string not found ? this is quite disturbing.

Thanks,


Gilles Dufour Fri, 01/11/2008 - 04:06
User Badges:
  • Cisco Employee,

as I said, you need to configure the expect status.

It is mandatory for the regexp to work.

Also, the response status must be in the range you have configured.

Try to configure an expect status 0 999


G.

csco10387876 Fri, 01/11/2008 - 04:42
User Badges:

Gilles,

I configured both expect status 0 999 and the expect regex trululu.



Now the probe is always successfull, as if the regex was not configured.



I will test with a simpler web service and keep you posted...


thanks for your help.


michal.jurco Mon, 11/07/2011 - 04:47
User Badges:

This seems to be bug related to some version of ACE software as HTTP return code overrides missing regexp. For sure this bug is present in:


system:    Version A2(2.0) [build 3.0(0)A2(2.0)]


Notice the difference between 192.168.1.1 (is missing regex in HTTP response) and 192.168.1.2 (sends regexp in HTTP response). Both are successful and as addition 192.168.1.1 (missing regexp) is showing last status code 200 which seems to be sufficient for probe to pass. 192.168.1.2 (which sends expected regexp) doesn't show last status code.


probe       : tw2_http_81

type        : HTTP

state       : ACTIVE

description :

----------------------------------------------

   port      : 81      address     : 0.0.0.0         addr type  : -

   interval  : 30      pass intvl  : 30              pass count : 1

   fail count: 1       recv timeout: 10

   http method      : GET

   http url         : /knowtw2-f/livelink.exe?func=ll&objtype=142&bypass

   conn termination : GRACEFUL

   expect offset    : 0         , open timeout     : 10

   expect regex     : lbmonitor

   send data        : -

                       --------------------- probe results --------------------

   probe association   probed-address  probes     failed     passed     health

   ------------------- ---------------+----------+----------+----------+-------


     real      : 192.168.1.1[81]

                       192.168.1.1    2          0          2          SUCCESS


   Socket state        : CLOSED

   No. Passed states   : 1         No. Failed states : 0

   No. Probes skipped  : 0         Last status code  : 200

   No. Out of Sockets  : 0         No. Internal error: 0

   Last disconnect err :  -

   Last probe time     : Mon Nov  7 12:38:42 2011

   Last fail time      : Never

   Last active time    : Mon Nov  7 12:38:22 2011


     real      : 192.168.1.2[81]

                       192.168.1.2    2          0          2          SUCCESS


   Socket state        : CLOSED

   No. Passed states   : 1         No. Failed states : 0

   No. Probes skipped  : 0         Last status code  : 0

   No. Out of Sockets  : 0         No. Internal error: 0

   Last disconnect err :  -

   Last probe time     : Mon Nov  7 12:38:27 2011

   Last fail time      : Never

   Last active time    : Mon Nov  7 12:37:58 2011

Actions

This Discussion