vADC Forum

Reply
Occasional Contributor
Posts: 7
Registered: ‎08-22-2013
Accepted Solution

Health Check on a different port

We have a dependency on a different port in order for the service to be online. Is it possible to do a health check on a port that is not the one defined on the pool nodes?

Brocadian
Posts: 232
Registered: ‎11-29-2012

Re: Health Check on a different port

I can think of two options:

  1. Using a Pool / GLB health check - you can be prescriptive on what NODE you actually want checked.
  2. Using an external monitor -  you can script exactly the hostSmiley Tongueort combination you want checked in your script logic
Occasional Contributor
Posts: 7
Registered: ‎08-22-2013

Re: Health Check on a different port

Thanks for your reply Aidan!

From what I learned reading the manual and a few threads here on the support forum I got the idea that would only be possible with an External Monitor program.

I am trying to use this article as a reference in order to create a custom monitor but I couldn't make it work yet.

Regarding your first suggestion, can you please describe a little more the way I can implement that?

Brocadian
Posts: 232
Registered: ‎11-29-2012

Re: Re: Health Check on a different port

Pool Wide monitors and external monitors are covered in the STM User Guide on page 220.

A Pool Wide monitor is going to be much easier to set up, but is not quite as flexible.

Per-node and Pool-wide Monitors

Monitors fall into two categories: per-node and pool-wide. A per-node monitor tests the health of each node in the pool. A pool-wide monitor performs tests on one machine which influences the health of the entire pool. For example, a mail server pool might keep its data on an NFS server, which each of your back-end servers accesses. A pool-wide monitor could test this server. If it fails, none of the back-ends can retrieve the data so the whole pool is deemed to have failed.

You can choose whether your monitor should be per-node or pool-wide. If it is pool- wide, you must specify a machine (and possibly port) for the monitor to test, such as an NFS server used by the pool.

SRWare Iron035.png

If you choose to use an external monitor, rather than the route you have chosen, a simpler way to get started with an external monitor would be to refer to the documentation on page 220 of the Stingray Traffic Manager User Guide (see below).  All you need to do with your external monitor is write your script to handle the arguments that the STM passes to it.  In you script, you could ignore the port that the STM asks it to check, and instead, check the port *you* want checked.

External Program Monitors

An external program monitor can be written in any language. The traffic manager passes command-line arguments to the executable:


domonitor --ipaddr=<machine_to_monitor> --node=<nodename> \ --port=<port_to_monitor>


Note: The ipaddr, node and port arguments are always passed to an external program monitor. The node argument is the hostname part of the node, as configured in the pool, and the ipaddr is the corresponding IP address.

You can also specify additional arguments for the monitor, which may be useful if you are using the same executable for several different monitoring tasks. Use the Program Arguments section of the Edit page for the monitor in question.

For example, if you configured two additional arguments (named ‘regex’ and ‘interface’) and gave then appropriate values on the Edit page, the monitor executable would be invoked as follows:


domonitor --ipaddr=<machine_to_monitor> --node=<nodename> \


          --port=<port_to_monitor> \


          --interface=<interface_value> --regex=<regex_value>


A successful monitor should exit with an exit code of 0; a timeout or non-zero exit code is interpreted as failure, and in this case the contents of STDERR are written to the Event Log.

When you develop and test a monitor executable or script, you can easily run it from the command line, providing arguments in the format described above. Your monitor can emit debugging information to STDOUT.

When the monitor is used by the traffic manager, you can enable verbose mode. If the monitor is called in verbose mode, anything printed to STDOUT by the executable is written to the Event Log; verbose mode can be toggled on the monitor’s Edit page.

Brocadian
Posts: 2
Registered: ‎12-07-2012

Re: Health Check on a different port

Hi Bruno

the link on splash will do the job for what you are looking for

https://splash.riverbed.com/docs/DOC-1834

I skype you

regards

Occasional Contributor
Posts: 7
Registered: ‎08-22-2013

Re: Health Check on a different port

Thanks Jacques, I am trying to work that one out as I mentioned on my previous post...

Contributor
Posts: 74
Registered: ‎10-03-2011

Re: Health Check on a different port

Hi Bruno,

Try the below perl script. It doesn't require a TrafficScript rule, it simply connects to the address given by the stingray monitor process on the port specified in the $port variable.


#!/bin/sh



exec $ZEUSHOME/perl/miniperl -wx $0 ${1+"$@"}


    if 0;



#!/usr/bin/perl


#line 7



BEGIN { unshift @INC, "/usr/bin/perl",


                      "$ENV{ZEUSHOME}/zxtm/lib/perl",


                      "$ENV{ZEUSHOME}/zxtmadmin/lib/perl"; }



use strict;


use Zeus::ZXTM::Monitor qw( ParseArguments MonitorWorked MonitorFailed Log );


use IO:Smiley Frustratedocket;



my %args = ParseArguments();


my $port = 4567;


my $retcode = 1;


my $ping = "PING\r\n";


my $pong = "PONG";



my $socket = IO:Smiley Frustratedocket::INET->new(PeerAddr => $args{ipaddr},


              PeerPort => $port,


              Proto    => 'tcp');


die "$!" unless $socket;


$socket->autoflush();



$socket->print( $ping );


my $resp = $socket->getline();


if ( defined($resp) && $resp =~ /$pong/ ) {


  $retcode = 0;


}



if ($retcode == 0) {


  Log("Monitor Passed, Host: $args{ipaddr}, PORT: $port, PONG: $resp");


  MonitorWorked();


} else {


  if ( defined($resp) ) {


    MonitorFailed("PORT: $port, PONG Response: \"$resp\"");


  } else {


    MonitorFailed("PORT: $port, PONG - NO Response!");


  }


}



exit $retcode;


Ensure that you set $ping to the request string, and $pong to the response you expect.

Cheers,

Mark

Occasional Contributor
Posts: 7
Registered: ‎08-22-2013

Re: Health Check on a different port

Hi, Mark!

This solution seems a bit more polished. I'll try it out!

Thanks for your feedback!

Bruno Melo

Occasional Contributor
Posts: 7
Registered: ‎08-22-2013

Re: Health Check on a different port

Hello Mark,

I finally got the time to test your idea but unfortunately I'm getting timeout errors on the event log:

     [Monitor: my_monitor] [Machine: 192.168.244.131:8888] Failed: Timeout

     [Monitor: my_monitor] [Machine: 192.168.244.131:8888] Running: /opt/zeus/zxtm/conf/scripts/monitor04.sh

     --ipaddr=192.168.244.131 --port=8888 --node=192.168.244.131 --verbose "--vsport=8888" "--path=" --failures_left=0

I created a monitor based on your script and changed the port and the $ping and $pong variables.

my $ping = "GET / HTTP/1.1";

my $pong = "HTTP/1.1 200 OK";

When I try this using telnet from the Stingray Virtual Appliance I get the 200 OK response, but with the monitor it times out... Any ideas?

Another question, when I enable verbose on a monitor where are the logs written to? Is it to the same pool log file?

Thanks in advance!


BMelo

Contributor
Posts: 74
Registered: ‎10-03-2011

Re: Health Check on a different port

Hi Bruno,

HTTP will require a two <CR><LF> at the end of the request, and HTTP/1.1 will require a Host header.

Try changing your ping to:

my $ping = "GET / HTTP/1.0\r\n\r\n";

OR

my $ping = "GET / HTTP/1.1\r\nHost: www.foo.com\r\n\r\n";

Cheers,

Mark

Join the Community

Get quick and easy access to valuable resource designed to help you manage your Brocade Network.