HTTP Monitor cURL Probe Timeout

Problem this snippet solves:

External HTTP monitor script that requests a URI from the pool member to which it is applied, marking it up if the expected response is received timely, or marking it down immediately if the response is not received within the specified probe timeout (without waiting for the configured external monitor timeout.) Useful when you need to monitor an application for performance with very small timeout tolerances, especially if that timeout is smaller than interval at which the monitor will run.

Probe timeout, pool name, URI and response string are user-configurable. cURL by default uses HTTP/1.1 and, since no hostname is specified in the cURL command, inserts the IP address in the Host header.

NOTE: Use external monitors only when a built-in monitor won't do the trick. This example is intended to demonstrate the use of cURL (which offers a large number of other useful options) to support a very short application timeout without overwhelming your servers with more frequent checks than necessary. If you don't need that extra functionality, a very simple HTTP monitor such as this is much more efficiently configured using the built-in HTTP monitor template instead.

How to use this snippet:

Create a new file containing the code below in /usr/bin/monitors on the LTM filesystem. Permissions on the file must be 700 or better, giving root rwx access to the file.
Create a monitor profile of type "External" with the following values:
- External Program: . . the name of the script file created in step 1
- Variables:
  - Name.....Value
  - P_TIMEOUT. .Probe timeout value -- max time for app to respond to be UP
  - POOL . . . .name of pool containing the nodes monitored by this instance
  - URI . . . . URI to request from the server
  - RECV . . . .expected response
Set Interval to the frequency in seconds you'd like to check each server. Must be longer than the P_TIMEOUT value specified above. (3x the P_TIMEOUT value is a good rule of thumb for a minimum value.)
Timeout value doesn't exactly come into play here unless the monitor script doesn't run at all for some reason. (2-3x the configured interval is a good rule of thumb for a minimum value.)

Caveats

This monitor will ALWAYS mark the pool member UP if the expected response is received, even if it was manually disabled in the LTM configuration. If you ever need to manually mark a pool member to which this monitor is applied DOWN for maintenance, you'll either need to remove this monitor, or manually mark DOWN the node address instead, otherwise this monitor will keep forcing the pool member UP.

Code :

#!/bin/sh
#
# (c) Copyright 1996-2007 F5 Networks, Inc.
#
# This software is confidential and may contain trade secrets that are the
# property of F5 Networks, Inc.  No part of the software may be disclosed
# to other parties without the express written consent of F5 Networks, Inc.
# It is against the law to copy the software.  No part of the software may
# be reproduced, transmitted, or distributed in any form or by any means,
# electronic or mechanical, including photocopying, recording, or information
# storage and retrieval systems, for any purpose without the express written
# permission of F5 Networks, Inc.  Our services are only available for legal
# users of the program, for instance in the event that we extend our services
# by offering the updating of files via the Internet.
#
# @(#) $Id: HTTPMonitor_cURL_ProbeTimeout,v 1.0 2007/09/20 13:09:07 deb Exp $
# (based on sample_monitor,v 1.3 2005/02/04 18:47:17 saxon)
#

#
# these arguments supplied automatically for all external monitors:
# $1 = IP (nnn.nnn.nnn.nnn notation)
# $2 = port (decimal, host byte order)
#
# additional command line arguments ($3 and higher) may be specified in the monitor template
# (This example does not expect any additional command line arguments)
#
# Name/Value pairs may also be specified in the monitor template
# This example expects the following Name/Vaule pairs:
#  P_TIMEOUT =  the probe timeout value -- max time for app to respond to be marked UP
#  POOL = the name of the pool containing the members monitored by this monitor instance
#  URI  = the URI to request from the server
#  RECV = the expected response (not case sensitive)
#

# remove IPv6/IPv4 compatibility prefix (LTM passes addresses in IPv6 format)
IP=`echo ${1} | sed 's/::ffff://'`
PORT=${2}

PIDFILE="/var/run/`basename ${0}`.${IP}_${PORT}.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
echo "$$" > $PIDFILE

# send request & check for expected response
curl -fNs -m ${P_TIMEOUT} http://${IP}:${PORT}${URI} | grep -i "${RECV}" 2>&1 > /dev/null

# if expected response was received, force the node UP if it was previously
# FORCEDOWN, & output something to stdout so bigd continues to mark the node UP
if [ $? -eq 0 ]
then
    /bin/bigpipe pool myPool member 10.10.10.100:8080 show | grep "forced down" 2>&1 > /dev/null
    if [ $? -eq 0 ]
    then
        /bin/bigpipe pool ${POOL} member ${IP}:${PORT} up 2>&1 > /dev/null
    fi
    rm -f $PIDFILE
    echo "UP"
# if expected response is not received in time, force the node DOWN immediately
else
    /bin/bigpipe pool ${POOL} member ${IP}:${PORT} down 2>&1 > /dev/null
    rm -f $PIDFILE
    exit
fi

Published Mar 12, 2015

Version 1.0

monitor