The Monitors Catalog

Some monitor types use regular expressions. Before continuing, read and understand the security considerations in Using Regular Expressions.

Setting Up a Monitor

To access the Monitors catalog, click Catalogs > Monitors in the Admin UI.

The Traffic Manager contains a number of preset monitors. Some of these deal with generic TCP client-first or server-first protocols, and others are protocol-specific. For instance, the built-in “Full HTTP” monitor requests a specified page from a Web server and looks for a suitable status code in the response.

All monitors have the following configurable settings:

Setting	Description
delay	Monitors are executed repeatedly against each node. Once a monitor has completed or times out, the Traffic Manager pauses for this configured period of time before trying the monitor again.
timeout	If a monitor fails to complete within this timeout period, it is aborted and judged to have failed.
failures	A monitor may occasionally fail for unpredictable and unrepeatable reasons, such as a brief network glitch. This setting indicates how many times a monitor must fail consistently before the monitored node is judged to have failed.
verbose	This setting enables verbose monitor logging in the error log. It is useful for testing a monitor, but should not be used in a product system or for a long period of time because it can fill up the error log file.

You can edit the built-in monitors: click the name of one, and modify the timings, failure conditions, and logging, along with any other monitor-specific settings (such as the Web page to request). Click Update to commit your changes.

To create a copy of the built-in monitor under a new name, click Copy Monitor.

Built-in Health Monitors

The Traffic Manager contains a number of predefined monitors in the Monitors catalog. These built-in monitors perform standard tests for various protocols.

Basic Monitors

Basic Monitors perform simple tests against a node. For example:

•Ping: The ping monitor performs ping requests against each node. It will fail if no response is received.

•Connect: This performs TCP connects to the node. Its purpose is to ensure that a server is listening on the port, and will accept traffic. This monitor can cause some programs (such as exim) to output errors; in this case a more protocol specific monitor should be used.

Advanced Monitors

Advanced monitors perform more complex request and response tests against a node. These monitors are used as building blocks for other monitors, and can use SSL to connect and transfer the request and response. For example:

•Client First: This is a monitor based on the TCP transaction monitor. It will send some data to the node, and match the response against the supplied regular expression. In order to use it, the data to send (the write_string) must be configured.

•Server First: This monitor can be used to check services where the server writes data first. It will connect to the node, and check that the server returns some data. This monitor can easily be altered to check for specific data being returned by the server.

•Full HTTP / HTTPS: This monitor can be used to perform HTTP or HTTPS requests. The host header, URL and authorization parameters can all be configured.

The response return code is matched against the value in status_regex. For example, if you are expecting a 200 return code, set status_regex to "^200$". Alternatively, use "^[234][0-9][0-9]$" to accept errors from 200 to 499.

The response body is matched against the optional setting body_regex.

If the pool that an SSL monitor is assigned to has ssl_server_name enabled, the monitor sends a Server Name Indication (SNI) TLS extension with the name of the node to the back end.

Protocol-Specific Monitors

Protocol-specific monitors perform specific tests against a node. These include:

•DNS: This is an example of a program monitor. It will run a program (ZEUSHOME/zxtm/conf/scripts/dns.pl) that makes a DNS request to the node, and validate the address returned.

•FTP: This monitor is based on the TCP transaction monitor. It will make a simple FTP connection, and check that the server is responding correctly. It only checks that the banner is returned by the server, and does not authenticate.

•POP: This monitor is based on the TCP transaction monitor. It will make an initial connection to the node, and check that the correct POP banner is returned.

•SMTP: This is identical to the POP monitor, except that it checks for the SMTP server banner being returned.

•Simple HTTP and HTTPS: These monitors request the home page from each node. They check that the response code is a 2xx, 3xx, or 4xx response code, and indicate a failure of not.

•RTSP: This monitor will send an RTSP DESCRIBE request to the server. It will check for a 2xx, 3xx or 4xx response or report a failure if one is not received. Note that some RTSP servers require the presence of a path in such a DESCRIBE request, in which case you should enter one in the rtsp_path setting. The protocol specific additional settings for RTSP are:

•rtsp_path: the path to be used in the DESCRIBE request. This is the path to the multimedia file being streamed.

•rtsp_status_regex: The status code regular expression that the RTSP response must match.

•rtsp_body_regex: The regular expression that the RTSP response body must match.

•SIP (UDP): This monitor will send a SIP OPTIONS request to the server with Max-Forwards set to 0. It will check for a 2xx, 3xx or 4xx response and report a failure if one is not received.

•sip_status_regex: The status code regular expression that the response must match.

•sip_body_regex: The regular expression that the SIP response body must match.

•udp_accept_all: Should this monitor accept responses from any IP and port?

•SIP (TCP): This monitor uses the same request as the SIP-UDP monitor but sends it over a TCP connection.

Custom Health Monitors

The main Monitors catalog page has a “Create New Monitor” section, where you can create a new monitor. There are several options for the underlying type:

Monitor Type	Description
TCP Transaction	This performs a TCP transaction with the target machine, with an optional string of data to write to the connection It can look for a specified regex in the response.
Ping	This pings the target machine at specified intervals.
External Program	This runs an external program, whose file path on the Traffic Manager machine you specify. It sends two built-in arguments, port and ipaddr, along with any others specified. An exit code of 0 is classed as a success; a code other than 0, or a timeout, is a failure. ZEUSHOME/zxtm/conf/scripts contains your custom monitor executables; you can see an example there.
HTTP	This sends an HTTP request to the target server, optionally using SSL, with specified parameters such as host header and the URL path to use. It searches for a status code regex in the response code, and a regex against the response body data.
TCP Connect	This makes a TCP connection with the target machine, to check that the appropriate port is open.
RTSP	This issues an RTSP DESCRIBE request to the target server, with the specified rtsp_path parameter. It looks for a status regex in the response, and a regex against the response body data.
SIP	This sends a SIP OPTIONS request to the target server using the specified transport protocol. It searches for the status regex in the response code and the body regex in any body of data that was received. A failure is reported if either of these do not match.

When you have chosen the basic settings for your monitor, click Add Monitor. You can click the name of the monitor to edit it.2

It is possible to build sophisticated custom monitors, using either the “TCP Transaction” or “HTTP“ monitor templates. For example, a pair of HTTP-based monitors could test the secure part of a Web site to verify that:

•A request with a valid username and password receives a valid 200 response.

•A request with an incorrect username and password receives a 401 or 403 error response.

“TCP Transaction” monitors are useful building blocks for nodes that use other protocols.

For more sophisticated tests, a monitor can run an external program or script. “External Program monitors” are described in External Program Monitors.

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.