Applies To:

Show Versions Show Versions

Manual Chapter: BIG-IP version 9.2 Configuration Guide for Local Traffic Management: Configuring Monitors
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


10

Configuring Monitors


Introducing monitors

An important feature of the BIG-IP® local traffic management (LTM) system is a load-balancing tool called monitors. Monitors verify connections on pool members and nodes. A monitor can be either a health monitor or a performance monitor, designed to check the status of a pool, pool member, or node on an ongoing basis, at a set interval. If a pool member or node being checked does not respond within a specified timeout period, or the status of a pool member or node indicates that performance is degraded, the LTM system can redirect the traffic to another pool member or node.

Some monitors are included as part of the LTM system, while other monitors are user-created. Monitors that the LTM system provides are called pre-configured monitors. User-created monitors are called custom monitors. For more information on pre-configured and custom monitors, see Understanding pre-configured and custom monitors .

Before configuring and using monitors, it is helpful to understand some basic concepts regarding monitor types, monitor settings, and monitor implementation.

  • Monitor types
    Every monitor, whether pre-configured or custom, is a certain type of monitor. Each type of monitor checks the status of a particular protocol, service, or application. For example, one type of monitor is HTTP. An HTTP type of monitor allows you to monitor the availability of the HTTP service on a pool, pool member, or node. A WMI type of monitor allows you to monitor the performance of a pool, pool member, or node that is running the Windows Management Instrumentation (WMI) software. An ICMP type of monitor simply determines whether the status of a node is up or down. For more information on monitor types, see Summary of monitor types and Configuring monitor settings .
  • Monitor settings
    Every monitor consists of settings with values. The settings and their values differ depending on the type of monitor. In some cases, the LTM system assigns default values. For example, Figure 10.1 shows that an ICMP-type monitor has these settings and default values.
    Figure 10.1 Example of a monitor with default values
    Name my_icmp
    
    Type ICMP
    
    Interval 5
    
    Timeout 16
    
    Transparent No
    Alias Address * All Addresses
  • The settings in Figure 10.1 specify that an ICMP type of monitor is configured to check the status of an IP address every 5 seconds, and to time out every 16 seconds. The destination IP address that the monitor checks is specified by the Alias Address setting, with the value * All Addresses. Thus, in the preceding example, all IP addresses with which the monitor is associated are checked. For more information on monitor settings, see Summary of monitor settings and Configuring monitor settings .

  • Monitor implementation
    The task of implementing a monitor varies depending on whether you are using a pre-configured monitor or creating a custom monitor. If you want to implement a pre-configured monitor, you need only associate the monitor with a pool, pool member, or node. If you want to implement a custom monitor, you must first create the custom monitor, and then associate it with a pool, pool member, or node. For more information on implementing a monitor, see Understanding pre-configured and custom monitors and Creating a custom monitor .

Summary of monitor types

The LTM system includes many different types of monitors, each designed to perform a specific type of monitoring. Table 10.1 lists the monitor types that you can configure for controlling your network traffic.

Table 10.1 Monitor types available on an LTM system
Monitor Types
Description
Simple monitors
ICMP
Checks the status of a node, using Internet Control Message Protocol (ICMP).
Gateway ICMP
Checks nodes in a pool that implements gateway failsafe for high availability.
TCP Echo
Checks the status of a node, using Transmission Control Protocol (TCP).
Extended Content Verification (ECV) monitors
TCP
Verifies the Transmission Control Protocol (TCP) service by attempting to receive specific content from a node.
HTTP
Verifies the Hypertext Transfer Protocol (HTTP) service by attempting to receive specific content from a web page.
HTTPS
Verifies the Hypertext Transfer Protocol Secure (HTTPS) service by attempting to receive specific content from a web page protected by Secure Socket Layer (SSL) security.
Extended Application Verification (EAV) monitors
External
Allows users to monitor services using their own programs.
FTP
Verifies the File Transfer Protocol (FTP) service by attempting to download a specific file to the /var/tmp directory on an LTM system. Once downloaded successfully, the file is not saved.
IMAP
Verifies the Internet Message Access Protocol (IMAP) by attempting to open a specified mail folder on a server. This monitor is similar to the pop3 monitor.
LDAP
Verifies the Lightweight Directory Access Protocol (LDAP) service by attempting to authenticate the specified user.
MSSQL
Verifies Microsoft® Windows SQL-based services.
NNTP
Verifies the Usenet News protocol (NNTP) service by attempting to retrieve a newsgroup identification string from the server.
Oracle
Verifies services based on Oracle® by attempting to perform an Oracle login to a service.
POP3
Verifies the Post Office Protocol (pop3) service by attempting to connect to a pool, pool member, or node, log on as the specified user, and log off.
RADIUS
Verifies the Remote Access Dial-in User Service (RADIUS) service by attempting to authenticate the specified user.
Real Server
Checks the performance of a pool, pool member, or node that is running the RealServer data collection agent, and then dynamically load balances traffic accordingly.
SIP
Checks the status of Session Initiation Protocol (SIP) Call-ID services on a device. The SIP protocol enables real-time messaging, voice, data, and video.
SMTP
Checks the status of a pool, pool member, or node by issuing standard Simple Mail Transport Protocol (SMTP) commands.
SNMP DCA
Checks the current CPU, memory, and disk usage of a pool, pool member, or node that is running an SNMP data collection agent, and then dynamically load balances traffic accordingly.
SNMP DCA Base
Checks the current user usage of a pool, pool member, or node that is running an SNMP data collection agent, and then dynamically load balances traffic accordingly. The way that you configure the monitor settings determines the data that the LTM system collects.
SOAP
Tests a Web service based on the Simple Object Access Protocol (SOAP).
UDP
Verifies the User Datagram Protocol (UDP) service by attempting to send UDP packets to a pool, pool member, or node and receiving a reply.
WMI
Checks the performance of a pool, pool member, or node that is running the Windows Management Infrastructure (WMI) data collection agent and then dynamically load balances traffic accordingly.

Summary of monitor settings

Monitors contain settings with corresponding values. These settings and their values affect the way that a monitor performs its status check. When you create a custom monitor, you must configure these setting values. For those settings that have default values, you can either retain the default values, or modify them to suit your needs.

Table 10.2 contains a complete list of all possible monitor settings, along with their descriptions. Note that each monitor contains only a subset of these settings.

Table 10.2 List of all possible monitor settings
Setting
Definition
Additional Accepted Status Codes
Status codes for a SIP monitor. Acceptable values are Any, None, or a list of status codes that you specify.
Agent
An agent specification for use with Real Server, SNMP Base, and WMI monitors only.
Agent Type
The type of agent running on the server that you are monitoring with an SNMP DCA monitor.
Alias Address
The destination node for a ping. Usually has a value of *, which checks all nodes. This setting causes the monitor instance to ping the IP address for which it is instantiated. Specifying an individual IP address forces the destination to that address (that is, a node). When the monitor includes the Alias Address setting but not the Alias Service Port setting, the monitor pings a node address rather than a pool member.
Alias Service Port
The destination pool member for a ping. Usually has a value of *:*, which checks all pool members. This setting causes the monitor instance to ping the IP address and port for which it is instantiated. Specifying an individual IP address and port forces the destination to that address and port (that is, a pool member).
Arguments
Any command-line arguments that are required.
Base
Starting place in the LDAP hierarchy from which to begin the query, for LDAP monitors only.
Cipher List
List of ciphers, for use with HTTPS monitors only.
Command
A command associated with metrics and metric values. Applies to Real Server and WMI monitors.
Community
A setting that applies to SNMP DCA monitors only. Default value is Public.
CPU Coefficient
A CPU value used for calculating a ratio weight.
CPU Threshold
The highest CPU threshold value allowed, used in calculating a ratio weight.
Database
Database name, for Oracle and MSSQL monitors only.
Disk Coefficient
A disk value used for calculating a ratio weight.
Disk Threshold
The highest disk threshold value allowed, used in calculating a ratio weight.
Domain
Domain name, for SMTP monitors only.
External Program
A user-created monitor type.
Filter
LDAP-format key of what is to be searched for, for LDAP monitors only.
Folder
Folder name for IMAP monitors only.
Interval
Time interval for frequency of pool, pool member, or node checking, in seconds.
Memory Coefficient
A memory value used for calculating a ratio weight.
Memory Threshold
The highest disk threshold value allowed, used in calculating a ratio weight.
Method
A method specification such as GET or POST. Applies to Real Server, SOAP, and WMI monitors only.
Metrics
Metrics that you want to monitor, such as CPU percentage or memory usage. Applies to Real Server and WMI monitors only.
Mode
Mode of the monitor.
Newsgroup
Newsgroup, for NNTP monitors only.
Password
Password for services with password security.
Path/Filename
For FTP monitors only, this setting replaces the Send String setting. You can use this setting to specify a full path to a file.
Receive Row
The row in the returned table that contains the Receive String value.
Receive Column
The column in the returned table that contains the Receive String value.
Receive String
Receive expression for ECV checking. Default Send String and Receive String values are empty (""), which match any string.
Reverse
A mode that sets the pool, pool member, or node to a down state if the received content matches the Receive String string.
Secret
Shared secret for RADIUS monitors only.
Security
The security protocol that the monitor should use (SSL, TLS, or None). Applies to LDAP monitors only.
Send Packets
Number of packets to send when using the UDP monitor.
Send String
Send string for ECV checking. Default Send String and Receive String values are empty (""), which matches any string.
Timeout
Timeout for checking a pool, pool member, or node, in seconds.
Timeout Packets
Timeout in seconds for receiving UDP packets.
Transparent
A mode that forces pinging through the pool, pool member, or node to the IP address and/or port for transparent pool members and nodes, such as firewalls.
URL
For a WMI monitor, supplies a URL.
URL Path
For a SOAP monitor, supplies a URL path.
User Name
User name for services with password security. For LDAP monitors only, this is a distinguished name, that is, LDAP-format user name.

 

Understanding pre-configured and custom monitors

When you want to monitor the health or performance of pool members or nodes, you can either use a pre-configured monitor, or create and configure a custom monitor.

Using pre-configured monitors

For a subset of monitor types, the LTM system includes a set of pre-configured monitors. A pre-configured monitor is an existing monitor that the LTM system provides for you, with its settings already configured. You cannot modify pre-configured monitor settings, as they are intended to be used as is. The purpose of a pre-configured monitor is to eliminate the need for you to explicitly create one. You use a pre-configured monitor when the values of the settings meet your needs as is.

The names of the pre-configured monitors that the LTM includes are:

  • gateway_icmp
  • http
  • https
  • https_443
  • icmp
  • real_server
  • snmp_dca
  • tcp
  • tcp_echo
  • tcp_half_open

An example of a pre-configured monitor is the icmp monitor. Figure 10.2 shows the icmp monitor, with values configured for its Interval, Timeout, and Alias Address settings. Note that the Interval value is 5, the Timeout value is 16, the Transparent value is No, and the Alias Address value is * All Addresses.

Figure 10.2 The icmp pre-configured monitor
Name icmp
Type ICMP
Interval 5
Timeout 16
Transparent No
Alias Address * All Addresses

 

If the Interval, Timeout, Transparent, and Alias Address values meet your needs, you simply assign the icmp pre-configured monitor directly to a pool, pool member, or node, using the Pools or Nodes screens within the Configuration utility. In this case, you do not need to use the Monitors screens, unless you simply want to view the values of the pre-configured monitor settings.

If you do not want to use the values configured in a pre-configured monitor, you can create a custom monitor.

Using custom monitors

A custom monitor is a monitor that you create based on one of the allowed monitor types.You create a custom monitor when the values defined in a pre-configured monitor do not meet your needs, or no pre-configured monitor exists for the type of monitor you are creating. (For information on monitor types, see Summary of monitor types .)

Importing settings from a pre-configured monitor

If a pre-configured monitor exists that corresponds to the type of custom monitor you are creating, you can import the settings and values of that pre-configured monitor into the custom monitor. You are then free to change those setting values to suit your needs. For example, if you create a custom monitor called my_icmp, the monitor can inherit the settings and values of the pre-configured monitor icmp. This ability to import existing setting values is useful when you want to retain some setting values for your new monitor but modify others.

Figure 10.3 shows an example of a custom ICMP-type monitor called my_icmp, which is based on the pre-configured monitor icmp. Note that the Interval value has been changed to 10, and the Timeout value to 20. The other settings retain the values defined in the pre-configured monitor.

Figure 10.3 A custom monitor based on a pre-configured monitor
Name my_icmp
Type ICMP
Interval 10
Timeout 20
Transparent No
Alias Address * All Addresses

 

Importing settings from a custom monitor

You can import settings from another custom monitor instead of from a pre-configured monitor. This is useful when you would rather use the setting values defined in another custom monitor, or when no pre-configured monitor exists for the type of monitor you are creating. For example, if you create a custom monitor called my_oracle_server2, you can import settings from an existing Oracle-type monitor such as my_oracle_server1. In this case, because the LTM system does not provide a pre-configured Oracle-type monitor, a custom monitor is the only kind of monitor from which you can import setting values.

Selecting a monitor is straightforward. Like icmp, each of the monitors has a Type setting based on the type of service it checks, for example, http, https, ftp, pop3, and takes that type as its name. (Exceptions are port-specific monitors, like the external monitor, which calls a user-supplied program.)

For procedures on selecting and configuring a monitor, see Creating a custom monitor .

Importing settings from a monitor template

If no pre-configured or custom monitor exists that corresponds to the type of monitor you are creating, the LTM system imports settings from a monitor template. A monitor template is a non-visible entity that exists within the LTM system for each monitor type and contains a group of settings and default values. A monitor template merely serves as a tool for the LTM system to use for importing settings to a custom monitor when no monitor of that type already exists.

Creating a custom monitor

When you create a custom monitor, you use the Configuration utility to: give the monitor a unique name, specify a monitor type, and, if a monitor of that type already exists, import settings and their values from the existing monitor. You can then change the values of any imported settings.

You must base each custom monitor on a monitor type. When you create a monitor, the Configuration utility displays a list of monitor types. To specify a monitor type, simply choose the one that corresponds to the service you want to check. For example, if you want to want to create a monitor that checks the health of the HTTP service on a pool, you choose HTTP as the monitor type.

If you want to check more than one service on a pool or pool member (for example HTTP and HTTPS), you can associate more than one monitor on that pool or pool member. For more information, see Chapter 4, Configuring Load Balancing Pools .

Checking services is not the only reason for implementing a monitor. If you want to verify only that the destination IP address is alive, or that the path to it through a transparent node is alive, use one of the simple monitors, icmp or tcp_echo. Or, if you want to verify TCP only, use the monitor tcp.

Note

Before creating a custom monitor, you must decide on a monitor type. For information on monitor types, see Configuring monitor settings .

To create a custom monitor

  1. On the Main tab, expand Local Traffic.
    The Local Traffic menu expands.
  2. Click Monitors.
    This displays a list of existing monitors.
  3. In the upper right corner of the screen, click Create.
    The New Monitor screen opens.
  4. For the Type setting, select the type of monitor that you want to create.
    If a monitor of that type already exists, Import Settings appears.
  5. Specify a name, based on one of these settings:
    • If Import Settings appears, choose a monitor name from the list.
    • If a monitor of the type you selected does not exist, in the Name box, type a unique name for the custom monitor.
  6. In the Configuration section of the screen, select Advanced. This allows you to modify additional default settings.
  7. Configure all settings shown.
  8. Click Finished.

Configuring monitor settings

Before you can create a custom monitor, you must select a monitor type. Monitors types fall into three categories:

  • Simple monitors
    These are health monitors that monitor the status of a node.
  • Extended Content Verification (ECV) monitors
    These are health monitors that verify service status by retrieving specific content from pool members or nodes.
  • External Application Verification (EAV) monitors
    These are health or performance monitors that verify service status by executing remote applications, using an external service-checker program.

Simple monitors

Simple monitors are those that check nodes only, and not pool members. The simple monitor types are:

  • ICMP
  • Gateway ICMP
  • TCP Echo
  • TCP Half Open

The LTM system provides a set of pre-configured simple monitors: icmp, gateway_icmp, tcp_echo, and tcp_half_open. You can either use these pre-configured monitors as is, or create custom monitors of these types.

The following sections describe each type of simple monitor and show the pre-configured monitor for each type. Note that each pre-configured monitor consists of settings and their values. The boldfaced type within each pre-configured monitor serves to distinguish the settings from their corresponding values.

Important

When defining values for custom monitors, make sure you avoid using any values that are on the list of reserved keywords. For more information, see solution number 3653 (for 9.0+ systems) on the AskF5 web site.

ICMP

Using an ICMP type of monitor, you can use Internet Control Message Protocol (ICMP) to make a simple node check. The check is successful if the monitor receives a response to an ICMP_ECHO datagram. Figure 10.4 shows the settings and their values for the pre-configured monitor icmp.

Figure 10.4 The icmp pre-configured monitor
    Name icmp
Type ICMP
Interval 5
Timeout 16
Transparent No
Alias Address * All Addresses

 

The Transparent mode is an option for ICMP-type monitors. When you set this mode to Yes, the monitor pings the node with which the monitor is associated. For more information about Transparent mode, refer to Using transparent and reverse modes .

Gateway ICMP

A Gateway ICMP type of monitor has a special purpose. You use this monitor for a pool that implements gateway failsafe for high availability.

A Gateway ICMP monitor functions the same way as an ICMP monitor, except that you can apply a Gateway ICMP monitor to a pool member. (Remember that you can apply an ICMP monitor to a node only and not a pool member.) Figure 10.5 shows the settings and their values for the pre-configured gateway_icmp monitor.

Figure 10.5 The gateway_icmp pre-configured monitor
    Name gateway_icmp
Type Gateway ICMP
Interval 5
Timeout 16
Alias Address * All Addresses
    Alias Service Port * All Ports

 

TCP Echo

With a TCP Echo type of monitor, you can verify Transmission Control Protocol (TCP) connections. The check is successful if the LTM system receives a response to a TCP Echo message. The TCP Echo type also supports Transparent mode. In this mode, the node with which the monitor is associated is pinged through to the destination node. (For more information about Transparent mode, see Using transparent and reverse modes .)

To use a TCP Echo monitor type, you must ensure that TCP Echo is enabled on the nodes being monitored. Figure 10.6 shows the settings for the pre-configured monitor tcp_echo.

Figure 10.6 The tcp_echo pre-configured monitor
    Name tcp_echo  {
Type TCP Echo
Interval 5
Timeout 16
Transparent No
Alias Address * All Addresses

 

TCP Half Open

A TCP Half Open type of monitor performs a quick check on the associated service by sending a TCP SYN packet to the service. As soon as the monitor receives the SYN-ACK packet from the service, the monitor considers the service to be in an up state, and sends a RESET to the service instead of completing the three-way handshake.

Figure 10.7 shows the settings for the pre-configured monitor tcp_half_open.

Figure 10.7 The tcp_half_open pre-configured monitor
    Name tcp_half_open  {
Type TCP Half Open
Interval 5
Timeout 16
Transparent No
Alias Addresses * All Addresses
    Alis Service Ports * All Ports

 

Extended Content Verification (ECV) monitors

ECV monitors use Send String and Receive String settings in an attempt to retrieve explicit content from pool members or nodes. The LTM system provides the pre-configured monitors tcp, http, https, and https_443 for these ECV monitor types:

  • TCP
  • HTTP
  • HTTPS

You can associate TCP, HTTP, and HTTPS monitors with pools and pool members only. You cannot associate them with nodes. You can either use the pre-configured ECV monitors as is, or create custom monitors from these monitor types.

The following sections describe each type of simple monitor and show the pre-configured monitor for each type. Note that each pre-configured monitor consists of settings and their values. The boldfaced type within each pre-configured monitor serves to distinguish the settings from their corresponding values.

Important

When defining values for custom monitors, make sure you avoid using any values that are on the list of reserved keywords. For more information, see solution number 3653 (for 9.0+ systems) on the AskF5 web site.

TCP

A TCP type of monitor attempts to receive specific content sent over TCP. The check is successful when the content matches the Receive String value. A TCP type of monitor takes a Send String value and a Receive String value. If the Send String value is blank and a connection can be made, the service is considered up. A blank Receive String value matches any response. Both Transparent and Reverse modes are options. For more information about Transparent and Reverse modes, see Using transparent and reverse modes .

Figure 10.8 shows the settings for the pre-configured monitor tcp.

Figure 10.8 The tcp pre-configured monitor
Name tcp
Type TCP
Interval 5
Timeout 16
Send String ""
Receive String ""
Reverse No
Transparent No
Alias Address * All Addresses
Alias Service Port * All Ports

 

HTTP

You can use an HTTP type of monitor to check the status of Hypertext Transfer Protocol (HTTP) traffic. Like a TCP monitor, an HTTP monitor attempts to receive specific content from a web page, and unlike a TCP monitor, may send a user name and password. The check is successful when the content matches the Receive String value. An HTTP monitor uses a send string, a receive string, a user name, a password, and optional Reverse and Transparent modes. (If there is no password security, you must use blank strings [""] for the Username and Password settings.)

For more information on transparent and reverse modes, see Using transparent and reverse modes .

Figure 10.9 shows the settings of the pre-configured monitor http.

Figure 10.9 The http pre-configured monitor
Name http
Type HTTP
Interval 5
Timeout 16
Send String GET /
Receive String ""
User Name ""
Password ""
Reverse No
Transparent No
Alias Address * All Addresses
Alias Service Port * All Ports

 

HTTPS

You use an HTTPS type of monitor to check the status of Hypertext Transfer Protocol Secure (HTTPS) traffic. An HTTPS type of monitor attempts to receive specific content from a web page protected by SSL security. The check is successful when the content matches the Receive String value.

HTTPS-type monitors use a send string, a receive string, a user name, a password, and an optional Reverse setting. (If there is no password security, you must use blank strings [""] for the Username and Password settings.) For more information on the Reverse setting, see Using transparent and reverse modes .

HTTP-type monitors also include the settings Cipher List, Compatibility, and Client Certificate. If you do not specify a cipher list, the monitor uses the default cipher list DEFAULT:+SHA:+3DES:+kEDH. When you set the Compatibility setting to Enabled, this sets the SSL options to ALL. You use the Client Certificate setting to specify a certificate file that the monitor then presents to the server.

The LTM system provides two pre-configured HTTPS monitors, https and https_443. Figure 10.10 shows the settings of the pre-configured monitor https, and Figure 10.11 shows the settings of the pre-configured https_443.

Figure 10.10 The https pre-configured monitor
Name https
Type HTTPS
Interval 5
Timeout 16
Send String GET /
Receive String ""
Cipher List ""
User Name ""
Password ""
Compatibility Enabled
Client Certificate ""
Reverse No
Alias Address * All Addresses
Alias Service Port * All Ports

 

Figure 10.11 The https_443 pre-configured monitor
Name https_443
Type HTTPS_443
Interval 5
Timeout 16
Send String GET /
Receive String ""
Cipher List ""
User Name ""
Password ""
Compatibility Enabled
Client Certificate ""
Reverse No
Alias Address * All Addresses
Alias Service Port HTTPS

The Reverse mode is an option for monitors that import settings from the https and https_443 monitors. For more information on Reverse mode, see Using transparent and reverse modes .

External Application Verification (EAV) monitors

EAV monitors verify applications on servers by running those applications remotely, using an external service checker program located in the directory /user/bin/monitors.

The types of EAV monitors that you can create are:

  • External
  • FTP
  • IMAP
  • LDAP
  • MSSQL
  • NNTP
  • Oracle
  • POP3
  • RADIUS
  • Real Server
  • Scripted
  • SIP
  • SMTP
  • SNMP DCA
  • SNMP DCA Base
  • SOAP
  • UDP
  • WAP
  • WMI

The LTM system provides two pre-configured EAV monitors, snmp_dca and real_server, based on the monitor types SNMP DCA and Real Server. For any other EAV monitor type that you want to use, you create a custom monitor.

The following sections describe each type of simple monitor and show the pre-configured monitor for each type. Note that each pre-configured monitor consists of settings and their values. The boldfaced type within each pre-configured monitor serves to distinguish the settings from their corresponding values.

Important

When defining values for custom monitors, make sure you avoid using any values that are on the list of reserved keywords. For more information, see solution number 3653 (for 9.0+ systems) on the AskF5 web site.

External

Using an External type of monitor, you can create your own monitor type. To do this, you create a custom External-type monitor and within it, specify a user-supplied monitor to run.

It is the External Program setting that you use to specify the executable name of your user-supplied monitor program. By default, an External-type monitor searches the directory /user/bin/monitors for that monitor name. If the user-supplied monitor resides elsewhere, you must enter a fully qualified path name.

The Arguments setting allows you to specify any command-line arguments that are required.

Figure 10.12 shows the settings and default values of an External-type monitor.

Figure 10.12 An External-type custom monitor with default values
Name my_external
Type External
Interval 5
Timeout 16
External Program ""
Arguments ""
Variables ""
Alias Address * All Addresses
Alias Service Port * All Ports

FTP

Using an FTP type of monitor, you can monitor File Transfer Protocol (FTP) traffic. A monitor of this type attempts to download a specified file to the /var/tmp directory, and if the file is retrieved, the check is successful. Note that once the file has been successfully downloaded, the LTM system does not save it.

An FTP monitor specifies a user name, a password, and a full path to the file to be downloaded.

Figure 10.13 shows the settings and default values of an FTP-type monitor.

Figure 10.13 An FTP-type custom monitor with default values
Name my_ftp
Type FTP
Interval 10
Timeout 31
User Name ""
Password ""
Path/Filename ""
Mode Passive
Alias Address * All Addresses
Alias Service Port * All Ports

IMAP

With an IMAP type of monitor, you can check the status of Internet Message Access Protocol (IMAP) traffic. An IMAP monitor is essentially a POP3 type of monitor with the addition of the Folder setting. The check is successful if the monitor is able to log into a server and open the specified mail folder.

An IMAP monitor requires that you specify a user name and password. Figure 10.14 shows the settings and default values of an IMAP-type monitor.

Figure 10.14 An IMAP-type custom monitor with default values
Name my_imap
Type IMAP
Interval 5
Timeout 16
User Name ""
Password ""
Folder INBOX
Alias Address * All Addresses
Alias Service Port * All Ports

 

Note

Servers to be checked by an IMAP monitor typically require special configuration to maintain a high level of security, while also allowing for monitor authentication.

LDAP

An LDAP type of monitor checks the status of Lightweight Directory Access Protocol (LDAP) servers. The LDAP protocol implements standard X.500 for email directory consolidation. A check is successful if entries are returned for the base and filter specified. An LDAP monitor requires a user name, a password, and base and filter strings. Figure 10.15 shows the settings and default values of an LDAP-type monitor.

Figure 10.15 An LDAP-type custom monitor with default values
Name my_ldap
Type LDAP
Interval 10
Timeout 31
User Name ""
Password ""
Base ""
Filter ""
Security None
Mandatory Attributes No
Alias Address * All Addresses
Alias Service Port * All Ports

 

The User Name setting specifies a distinguished name, that is, an LDAP-format user name.

The Base setting specifies the starting place in the LDAP hierarchy from which to begin the query.

The Filter setting specifies an LDAP-format key of the search item.

The Security setting specifies the security protocol to be used. Acceptable values are SSL, TLS, or None.

The Mandatory Attributes setting affects the way that the system conducts the filter search. When the value is No, the system performs a one-level search for attributes, and if the search returns no attributes, the node is reported as up. When the value is Yes, the system performs a subtree search, and if the search returns no attributes, the node is not reported as up.

For an LDAP monitor to work properly, the BIG-IP system must be able to perform a reverse DNS lookup on the address of the LDAP or LDAPS node. This reverse lookup allows the BIG-IP system to check the host name of the node's address when it verifies the SSL certificate. An external DNS server does not work with this type of monitor

The reverse DNS lookup requirement applies to both LDAP and LDAPS nodes, even though LDAP does not require the use of an SSL certificate.

Note

You do not need to insert an entry for each LDAP server into the /etc/hosts file.

MSSQL

You use an MSSQL type of monitor to perform service checks on Microsoft SQL Server-based services such as Microsoft SQL Server versions 6.5 and 7.0.

The LTM system requires installation of a JDBC driver before performing the actual login. For more information, see Appendix A, Additional Monitor Considerations .

If you receive a message that the connection was refused, verify that the IP address and port number or service are correct. If you are still having login trouble, see Troubleshooting MSSQL logins .

The remainder of this section on MSSQL monitors describes prerequisite tasks, the default monitor settings, and troubleshooting tips.

Prerequisite tasks for MSSQL

Before using an MSSQL-type monitor, you must download a set of JDBC JavaTM Archive (JAR) files and install them on the LTM system. For more information, see Appendix A, Additional Monitor Considerations .

MSSQL monitor settings and their default values

Figure 10.16 shows the settings and default settings of an MSSQL-type monitor.

Figure 10.16 An MSSQL-type custom monitor with default values
Name my_mssql
Type mssql
Interval 30
Timeout 91
Send String ""
Receive String ""
User Name ""
Password ""
Database ""
Receive Row ""
Receive Column ""
Alias Address * All Addresses
Alias Service Port * All Ports

 

In an MSSQL-type monitor, the Database setting specifies the name of the data source on the Microsoft® SQL-based server. Examples are sales and hr.

The Send String setting is optional and specifies a SQL query statement that the LTM system should send to the server. Examples are SELECT * FROM sales and SELECT FirstName, LastName From Employees. If you configure the Send String setting, you can also configure these settings:

  • Receive String
    The Receive String setting is an optional parameter that specifies the value expected to be returned for the row and column specified with the Receive Row and Receive Column settings. An example of a Receive String value is ALAN SMITH. You can only configure this setting when you configure the Send String setting.
  • Receive Row
    The Receive Row setting is optional, and is useful only if the Receive String setting is specified. This setting specifies the row in the returned table that contains the Receive String value. You can only configure this setting when you configure the Send String setting.
  • Receive Column
    The Receive Column setting is optional and is useful only if the Receive String setting is specified. This setting specifies the column in the returned table that contains the Receive String value. You can only configure this setting when you configure the Send String setting.

Troubleshooting MSSQL logins

If an MSSQL monitor cannot log in to the server, and you have checked that the specified IP address and port number or service are correct, try the following:

  • Verify that you can log in using another tool.
    For example, the server program Microsoft NT SQL Server version 6.5 includes a client program named ISQL/w. This client program performs simple logins to SQL servers. Use this program to test whether you can log in to the server using the ISQL/w program.
  • Add login accounts using the Microsoft SQL Enterprise Manager.
    On the Microsoft SQL Server, you can run the SQL Enterprise Manager to add login accounts. When first entering the SQL Enterprise Manager, you may be prompted for the SQL server that you want to manage.

    You can register servers by entering the machine name, user name, and password. If these names are correct, the server becomes registered and you are then able to click an icon for the server. When you expand the subtree for the server, there is an icon for login accounts.

    Beneath this subtree, you can find the SQL logins. Here, you can change passwords or add new logins by right-clicking the Logins icon. Click this icon to access the Add login option. After you open this option, type the user name and password for the new login, as well as which databases the login is allowed to access. You must grant the test account access to the database you specify in the EAV configuration.

NNTP

You use an NNTP type of monitor to check the status of Usenet News traffic. The check is successful if the monitor retrieves a newsgroup identification line from the server. An NNTP monitor requires a newsgroup name (for example, alt.cars.mercedes) and, if necessary, a user name and password.

Figure 10.17 shows the settings and default values of an NNTP-type monitor.

Figure 10.17 An NNTP-type custom monitor with default values
Name my_nntp
Type NNTP
Interval 5
Timeout 16
User Name ""
Password ""
Newsgroup ""
Alias Address * All Addresses
Alias Service Port * All Ports

 

Oracle

With an Oracle type of monitor, you can check the status of an Oracle database server. The check is successful if the monitor is able to connect to the server, log in as the indicated user, and log out.

Figure 10.18 shows the settings and default values of an Oracle-type monitor.

Figure 10.18 An Oracle-type custom monitor with default values
Name my_oracle
Type Oracle
Interval 30
Timeout 91
Send String GET /
Receive String ""
User Name ""
Password ""
Database ""
Receive Row ""
Receive Column ""
Alias Address * All Addresses
Alias Service Port * All Ports

 

The Send String setting specifies a SQL statement that the LTM system should send to the Oracle server. An example is SELECT * FROM sales.

The Receive String setting is an optional parameter that specifies the value expected to be returned for a specific row and column of the table that the Send String setting retrieved. An example of a Receive String value is SMITH.

In an Oracle type of monitor, the Database setting specifies the name of the data source on the Oracle server. Examples are sales and hr.

The Receive Row setting is optional, and is useful only if the Receive String setting is specified. This setting specifies the row in the returned table that contains the Receive String value.

The Receive Column setting is optional and is useful only if the Receive String setting is specified. This setting specifies the column in the returned table that contains the Receive String value.

POP3

A POP3 type of monitor checks the status of Post Office Protocol (POP) traffic. The check is successful if the monitor is able to connect to the server, log in as the indicated user, and log out. A POP3 monitor requires a user name and password.

Figure 10.19 shows the settings and default values of a POP3-type monitor

Figure 10.19 A POP3-type custom monitor with default values
Name my_pop3
Type POP3
Interval 5
Timeout 16
User Name ""
Password ""
Alias Address * All Addresses
Alias Service Port * All Ports

 

RADIUS

Using a RADIUS type of monitor, you can check the status of Remote Access Dial-in User Service (RADIUS) servers. The check is successful if the server authenticates the requesting user. A RADIUS monitor requires a user name, a password, and a shared secret string for the code number.

Note

Servers to be checked by a RADIUS monitor typically require special configuration to maintain a high level of security while also allowing for monitor authentication.

Figure 10.20 shows the settings and default values of a RADIUS-type monitor.

Figure 10.20 A RADIUS-type custom monitor with default values
Name my_radius
Type RADIUS
Interval 10
Timeout 31
User Name ""
Password ""
Secret ""
Alias Address * All Addresses
Alias Service Port * All Ports

 

Real Server

A Real Server type of monitor checks the performance of a pool, pool member, or node that is running the RealSystem Server data collection agent. The monitor then dynamically load balances traffic accordingly. Performance monitors are generally used with dynamic ratio load balancing. For more information on performance monitors and dynamic ratio load balancing, see Chapter 4, Configuring Load Balancing Pools and Appendix A, Additional Monitor Considerations .

Note

Unlike health monitors, performance monitors do not report on the status of a pool, pool member, or node.

The LTM system provides a pre-configured Real Server monitor named real_server. Figure 10.21 shows the settings and default values of the real_server monitor.

Figure 10.21 The real_server pre-configured monitor
Name real_server
Type Real Server
Interval 5
Timeout 16
Method GET
Command GetServerStats
Metrics ServerBandwidth:1.5, CPUPercentUsage, MemoryUsage,         
TotalClientCount
Agent Mozilla/4.0 (compatible: MSIE 5.0; Windows NT)
Alias Address * All Addresses
Alias Service Port 12345

 

Like all pre-configured monitors, the real_server monitor is not user-modifiable. However, if you want to modify the Metrics setting, you can create a custom Real Server monitor, to which you can add metrics and modify metric values.

Note

When creating a custom Real Server monitor, you cannot modify the values of the Method, Command, and Agent settings.

Table 10.3 shows the complete set of server-specific metrics and metric setting default values that apply to the GetServerStats command.

Table 10.3 Metrics for a Real Server monitor
Metric
Default Coefficient
Default Threshold
ServerBandwidth (Kbps)
1.0
10,000
CPUPercentUsage
1.0
80
MemoryUsage (Kb)
1.0
100,000
TotalClientCount
1.0
1,000
RTSPClientCount
1.0
500
HTTPClientCount
1.0
500
PNAClientCount
1.0
500
UDPTransportCount
1.0
500
TCPTransportCount
1.0
500
MulticastTransportCount
1.0
500

 

The metric coefficient is a factor determining how heavily the metric's value counts in the overall ratio weight calculation. The metric threshold is the highest value allowed for the metric if the metric is to have any weight at all. To understand how to use these values, it is necessary to understand how the overall ratio weight is calculated. The overall ratio weight is the sum of relative weights calculated for each metric. The relative weights, in turn, are based on three factors:

  • The value for the metric returned by the monitor
  • The coefficient value
  • The threshold value

Given these values, the relative weight is calculated as follows:

w=((threshold-value)/threshold)*coefficient

You can see that the higher the coefficient, the greater the relative weight calculated for the metric. Similarly, the higher the threshold, the greater the relative weight calculated for any metric value that is less than the threshold. (When the value reaches the threshold, the weight goes to zero.)

Note that the default coefficient and default threshold values shown in Table 10.3 are metric defaults, not monitor defaults. The monitor defaults take precedence over the metric defaults, just as user-specified values in the custom real_server monitor take precedence over the monitor defaults. For example, the monitor shown specifies a coefficient value of 1.5 for ServerBandwidth and no value for the other metrics. This means that the monitor uses the monitor default of 1.5 for the ServerBandwidth coefficient and the metric default of 1 for the coefficients of all other metrics. However, if a custom monitor my_real_server were configured specifying 2.0 as the ServerBandwidth coefficient, this user-specified value would override the monitor default.

Metric coefficient and threshold are the only non-monitor defaults. If a metric not in the monitor is to be added to the custom monitor, it must be added to the list of metrics for the Metrics setting. The syntax for specifying non-default coefficient or threshold values is:

<metric>:<coefficient |<*>:<threshold>

Scripted

You use the Scripted type of monitor to generate a simple script that reads a file that you create. The file contains send and expect strings to specify lines that you want to send or that you expect to receive. For example, Figure 10.22 shows a sample file that you could create, which specifies a simple SMTP sequence. Note that the lines of the file are always read in the sequence specified.

Figure 10.22 A sample file specifying an SMTP sequence
expect 220
send "HELO bigip1.somecompany.net\r\n"
expect "250"
send "quit\r\n

 

Using a Scripted monitor, you can then generate a script that acts on the above file. When the Scripted monitor script reads this file, the script examines each line, and if the line has no double quotes, the line is sent or expected to be received as is. If the line is surrounded by quotation marks, the script strips off the quotation marks, and examines the line for escape characters, treating them accordingly.

Figure 10.23 shows the settings and default values of a Scripted-type monitor.

Figure 10.23 A SIP-type custom monitor with default values
Name my_scripted_monitor
Type Scripted
Import Settings scripted
Interval 10
Timeout 31
Filename <filename>
Alias Address * All Addresses
Alias Service Port * All Ports

 

Note

When you create a file containing send and expect strings, store the file in the directory /config/eav.

SIP

You use a SIP type of monitor to check the status of SIP Call-ID services. This monitor type uses UDP to issue a request to a server device. The request is designed to identify the options that the server device supports. If the proper request is returned, the device is considered to be up and responding to commands.

Figure 10.24 shows the settings and default values of a SIP-type monitor.

Figure 10.24 A SIP-type custom monitor with default values
Name my_sip
Type SIP
Interval 5
Timeout 16
Mode UDP
Additional Accepted Status Codes None
Alias Address * All Addresses
Alias Service Port * All Ports

 

Possible values for the Mode setting are TCP and UDP.

Possible values for the Additional Accepted Status Codes setting are Any, None, and Status Code List. The Status Code List setting specifies one or more status codes, in addition to status code 200, that are acceptable in order to indicate an up status. Multiple status codes should be separated by spaces. Specifying an asterisk (*) indicates that all status codes are acceptable.

SMTP

An SMTP type of monitor checks the status of Simple Mail Transport Protocol (SMTP) servers. This monitor type is an extremely basic monitor that checks only that the server is up and responding to commands. The check is successful if the mail server responds to the standard SMTP HELO and QUIT commands. An SMTP-type monitor requires a domain name.

Figure 10.25 shows the settings and default values of an SMTP-type monitor.

Figure 10.25 An SMTP-type custom monitor with default values
Name my_smtp
Type SMTP
Interval 5
Timeout 16
Domain ""
Alias Address * All Addresses
Alias Service Port * All Ports

 

SNMP DCA

With an SNMP DCA type of monitor, you can check the performance of a server running an SNMP agent such as UC Davis, for the purpose of load balancing traffic to that server. With this monitor you can define ratio weights for CPU, memory, and disk use.

Performance monitors are generally used with dynamic ratio load balancing. For more information on performance monitors and dynamic ratio load balancing, see Chapter 4, Configuring Load Balancing Pools , and Appendix A, Additional Monitor Considerations .

Note

Unlike health monitors, performance monitors do not report on the status of a pool, pool member, or node.

The LTM system provides a pre-configured SNMP DCA monitor named snmp_dca. Figure 10.26 shows the settings and values of the snmp_dca pre-configured monitor.

Figure 10.26 The snmp_dca pre-configured monitor
Name snmp_dca
Type SNMP DCA
Interval 10
Timeout 30
Community Public
Version v1
Agent Type UCD
CPU Coefficient 1.5
CPU Threshold 80
Memory coefficient 1.0
Memory Threshold 70
Disk Coefficient 2.0
Disk Threshold 90
Variables ""
Alias Address * All Addresses
Alias Service Port SNMP

 

Pre-configured monitors are not user-modifiable. Thus, if you want to change the values for the SNMP DCA monitor settings, you must create an SNMP DCA-type custom monitor. Possible values for the Version setting are v1, v2c, and Other. Possible values for the Agent Type setting are UCD, Win2000, and Other.

When configuring an SNMP DCA custom monitor, you can use the default CPU, memory, and disk coefficient and threshold values specified in the monitors, or you can change the default values. Optionally, you can specify coefficient and threshold values for gathering other types of data. Note that if the monitor you are configuring is for a type of SNMP agent other than UC Davis, you must specify the agent type, such as Win2000.

SNMP DCA Base

You use an SNMP DCA Base type of monitor to check the performance of servers that are running an SNMP agent, such as UC Davis. However, you should use this monitor only when you want the load balancing destination to be based solely on user data, and not CPU, memory or disk use.

Figure 10.27 shows the settings and default values of an SNMP DCA Base type of monitor.

Figure 10.27 An SNMP DCA-type custom monitor with default values
Name my_snmp_dca_base 
Type snmp_dca_base
Interval 10
Timeout 30
Community Public
Version v1
Variables ""
Alias Address * All Addresses
Alias Service Port SNMP

 

Performance monitors are generally used with dynamic ratio load balancing. For more information on performance monitors and dynamic ratio load balancing, see Chapter 4, Configuring Load Balancing Pools and Appendix A, Additional Monitor Considerations .

Note

Unlike health monitors, performance monitors do not report on the status of pool, pool member, or node.

SOAP

A SOAP monitor tests a Web service based on the Simple Object Access protocol (SOAP). More specifically, the monitor submits a request to a SOAP-based Web service, and optionally, verifies a return value or fault. Figure 10.28 shows the settings and default values of a SOAP-type monitor.

Figure 10.28 A SOAP-type custom monitor with default values
Name my_soap
Type soap
User Name ""
Password ""
Protocol" HTTP
URL Path ""
Namespace ""
Method ""
Parameter Name ""
Parameter Type bool
Parameter Value ""
Return Type bool
Return Value ""
Expect Fault No
Alias Address * All Addresses
Alias Service Port * All Ports

 

Possible values for the Protocol setting are HTTP and HTTPS.

Possible values for the Parameter Type setting are: bool, int, long, and string.

Possible values for the Return Type setting are: bool, int, short, long, float, double, and string.

Possible values for the Expect Fault setting are No and Yes.

UDP

You use a UDP type of monitor when the system is sending User Datagram Protocol (UDP) packets. Designed to check the status of a UDP service, a UDP-type monitor sends one or more UDP packets to a target pool, pool member, or node.

Figure 10.29 shows the settings and default values of a UDP-type monitor. As shown in this figure, the value in seconds of the Timeout Packets setting should be lower than the value of the Interval setting

Figure 10.29 A UDP-type custom monitor with default values
Name my_udp
Type UDP
Interval 5
Timeout 16
Send String default send string
Send Packets 2
Timeout Packets 2
Alias Address * All Addresses
Alias Service Port * All Ports

When using a UDP-type monitor to monitor a pool, pool member, or node, you must also enable another monitor type, such as ICMP, to monitor the pool, pool member, or node. Until both a UDP-type monitor and another type of monitor to report the status of the UDP service as up, the UDP service receives no traffic.

Table 10.4 Determining status of the UDP service
If a UDP monitor reports status as
And another monitor reports status as
Then the UDP service is
up
up
up
up
down
down
down
up
down
down
down
down

See Table 10.4 for details.

WAP

You use a WAP monitor to monitor Wireless Application Protocol (WAP) servers. The common usage for the WAP monitor is to specify the Send String and Receive String settings only. The WAP monitor functions by requesting a URL (the Send String setting) and finding the string in the Receive String setting somewhere in the data returned by the URL response. Figure 10.30 shows the settings and default values of a WAP-type monitor.

Figure 10.30 A WAP-type custom monitor with default values
Name my_wap
Type WAP
Import Settings wap
Interval 10
Timeout 31
Send String ""
Receive String ""
Secret ""
Accounting Node ""
Accounting Port ""
Server ID ""
Call ID ""
Session ID ""
Framed Address ""
Alias Address * All Addresses
Alias Service Port * All Ports

The Secret setting is the RADIUS secret, a string known to both the client and the RADIUS server, and is used in computing the MD5 hash.

The Accounting Node setting specifies the RADIUS node. If this a null string and RADIUS accounting has been requested (accounting port is non-zero), then the WAP server node is assumed to also be the RADIUS node.

If set to non-zero, the Accounting Port setting requests RADIUS accounting and uses the specified port.

The Server ID setting specifies the RADIUS NAS-ID of the requesting server (that is, the BIG-IP system). It is a string used as an alias for the FQDN. See the section on testing WAP_monitor just below.

The Call ID setting is an identifier similar to a telephone number, that is, a string of numeric characters. For testing purposes, this value is usually a string of eleven characters.

The Session ID setting is a RADIUS session ID, used to identify this session. This is an arbitrary numeric character string, often something like 01234567.

The Framed Address setting is a RADIUS framed IP address. The setting has no special use and is usually specified simply as 1.1.1.1.

RADIUS accounting is optional. To implement RADIUS accounting, you must set the accounting port to a non-zero value. If you set the Accounting Port setting to a non-zero value, then the monitor assumes that RADIUS accounting is needed, and an accounting request is sent to the specified accounting node and port to start accounting. This is done before the URL is requested. After the successful retrieval of the URL with the correct data, an accounting request is sent to stop accounting.

WMI

A WMI type of monitor checks the performance of a pool, pool member, or node that is running the Windows Management Infrastructure (WMI) data collection agent and then dynamically load balances traffic accordingly.

You generally use performance monitors such as a WMI monitor with dynamic ratio load balancing. For more information on performance monitors and dynamic ratio load balancing, see Chapter 4, Configuring Load Balancing Pools , and Appendix A, Additional Monitor Considerations .

Note

Unlike health monitors, performance monitors do not report on the status of a pool, pool member, or node.

Figure 10.31 shows the settings and default values of a WMI-type monitor.

Figure 10.31 A WMI-type custom monitor with default values
Name my_wmi
Type wmi
Interval 5
Timeout 16
User Name ""
Password ""
Method POST
URL /scripts/f5Isapi.dll
Command GetCPUInfo, GetDiskInfo, GetOSInfo
Metrics LoadPercentage, DiskUsage, PhysicalMemoryUsage:1.5, 
VirtualMemoryUsage:2.0
Agent Mozilla/4.0 (compatible: MSIE 5.0; Windows NT)
Post RespFormat=HTML
Alias Address * All Addresses
Alias Service Port HTTP

 

Note that when creating a custom WMI monitor, the only default values that you are required to change are the null values for user name and password. Also note that you cannot change the value of the Method setting.

Table 10.5 shows the complete set of commands and metrics that you can specify with the Command and Metrics settings. Also shown are the default metric values.

Table 10.5 WMI-type monitor commands and metrics
Command
Metric
Default Coefficient
Default
Threshold
GetCPUInfo
LoadPercentage (%)
1.0
80
GetOSInfo
PhysicalMemoryUsage (%)
1.0
80
 
VirtualMemoryUsage (%)
1.0
80
 
NumberRunningProcesses
1.0
100
GetDiskInfo
DiskUsage (%)
1.0
90
GetPerfCounters
TotalKBytesPerSec
1.0
10,000
 
ConnectionAttemptsPerSec
1.0
500
 
CurrentConnections
1.0
500
 
GETRequestsPerSec
1.0
500
 
PUTRequestsPerSec
1.0
500
 
POSTRequestsPerSec
1.0
500
 
AnonymousUsersPerSec
1.0
500
 
CurrentAnonymousUsers
1.0
500
 
NonAnonymousUsersPerSec
1.0
500
 
CurrentNonAnonymousUser
1.0
500
 
CGIRequestsPerSec
1.0
500
 
CurrentCGIRequests
1.0
500
 
ISAPIRequestsPerSec
1.0
500
 
CurrentISAPIRequests
1.0
500
GetWinMediaInfo
AggregateReadRate
1.0
10,000 Kbps
 
AggregateSendRate
1.0
10,000 Kbps
 
ActiveLiveUnicastStreams
1.0
1000
 
ActiveStreams
1.0
1000
 
ActiveTCPStreams
1.0
1000
 
ActiveUDPStreams
1.0
1000
 
AllocatedBandwidth
1.0
10,000 Kbps
 
AuthenticationRequests
1.0
1000
 
AuthenticationsDenied
1.0
100
 
AuthorizationRequests
1.0
1000
 
AuthorizationsRefused
1.0
100
 
ConnectedClients
1.0
500
 
ConnectionRate
1.0
500
 
HTTPStreams
1.0
1000
 
HTTPStreamsReadingHeader
1.0
500
 
HTTPStreamsStreamingBody
1.0
500
 
LateReads
1.0
100
 
PendingConnections
1.0
100
 
PluginErrors
1.0
100
 
PluginEvents
1.0
100
 
SchedulingRate
1.0
100
 
StreamErrors
1.0
100
 
StreamTerminations
1.0
100
 
UDPResendRequests
1.0
100
 
UDPResendsSent
1.0
100

 

Special configuration considerations

Every pre-configured or custom monitor has settings with some default values assigned. The following sections contain information that is useful when changing these default values.

Setting destinations

By default, the value for the Alias Address setting in the monitors is set to the wildcard * Addresses, and the Alias Service Port setting is set to the wildcard * Ports. This value causes the monitor instance created for a pool, pool member, or node to take that node's address or address and port as its destination. You can, however, replace either or both wildcard symbols with an explicit destination value, by creating a custom monitor. An explicit value for the Alias Address and/or Alias Service Port setting is used to force the instance destination to a specific address and/or port which may not be that of the pool, pool member, or node.

The ECV monitors http, https, and tcp have the settings Send String and Receive String for the send string and receive expression, respectively.

The most common Send String value is GET /, which retrieves a default HTML page for a web site. To retrieve a specific page from a web site, you can enter a Send String value that is a fully qualified path name:

"GET /www/support/customer_info_form.html"

The Receive String expression is the text string the monitor looks for in the returned resource. The most common Receive String expressions contain a text string that is included in a particular HTML page on your site. The text string can be regular text, HTML tags, or image names.

The sample Receive expression below searches for a standard HTML tag:

"<HEAD>"

You can also use the default null Receive String value [""]. In this case, any content retrieved is considered a match. If both the Send String and Receive String are left empty, only a simple connection check is performed.

For HTTP and FTP monitors, you can use the special settings get or hurl in place of Send String and Receive String statements. For FTP monitors specifically, the GET setting specifies the full path to the file to retrieve.

Using transparent and reverse modes

The normal and default behavior for a monitor is to ping the destination pool, pool member, or node by an unspecified route, and to mark the node up if the test is successful. However, with certain monitor types, you can specify a route through which the monitor pings the destination server. You configure this by specifying the Transparent or Reverse setting within a custom monitor.

  • Transparent setting
    Sometimes it is necessary to ping the aliased destination through a transparent pool, pool member, or node. When you create a custom monitor and set the Transparent setting to Yes, the LTM system forces the monitor to ping through the pool, pool member, or node with which it is associated (usually a firewall) to the pool, pool member, or node. (In other words, if there are two firewalls in a load balancing pool, the destination pool, pool member, or node is always pinged through the pool, pool member, or node specified and not through the pool, pool member, or node selected by the load balancing method.) In this way, the transparent pool, pool member, or node is tested: if there is no response, the transparent pool, pool member, or node is marked as down.
  • Common examples are checking a router, or checking a mail or FTP server through a firewall. For example, you might want to check the router address 10.10.10.53:80 through a transparent firewall 10.10.10.101:80. To do this, you create a monitor called http_trans in which you specify 10.10.10.53:80 as the monitor destination address, and set the Transparent setting to Yes. Then you associate the monitor http_trans with the transparent pool, pool member, or node.

    This causes the monitor to check the address 10.10.10 53:80 through 10.10.10.101:80. (In other words, the LTM system routes the check of 10.10.10.53:80 through 10.10.10.101:80.) If the correct response is not received from 10.10.10.53:80, then 10.10.10.101:80 is marked down. For more information on associating monitors with pool members or nodes, see Associating monitors with pools and nodes .

  • Reverse setting
    With the Reverse setting set to Yes, the monitor marks the pool, pool member, or node down when the test is successful. For example, if the content on your web site home page is dynamic and changes frequently, you may want to set up a reverse ECV service check that looks for the string "Error". A match for this string means that the web server was down.

Figure 10.6 shows the monitors that contain the Transparent setting, the Reverse setting, or both.

Table 10.6 Monitors that contain the Transparent or Reverse settings
Monitor Type
Setting
TCP
Transparent
Reverse
HTTP
Transparent
Reverse
HTTP
 
Reverse
TCP Echo
Transparent
 
ICMP
Transparent
 

 

Associating monitors with pools and nodes

Once you have created a monitor and configured its settings, the final task is to associate the monitor with the server or servers to be monitored. The server or servers can be either a pool, a pool member, or a node, depending on the monitor type.

Some monitor types are designed for association with nodes only, and not pools or pool members. Other monitor types are intended for association with pools and pool members only, and not nodes. Therefore, when you use the Configuration utility to associate a monitor with a pool, pool member, or node, the utility displays only those pre-configured monitors that are designed for association with that server. For example, you cannot associate the monitor icmp with a pool or its members, since the icmp monitor is designed to check the status of a node itself and not any service running on that node.

When you associate a monitor with a server, the LTM system automatically creates an instance of that monitor for that server. A monitor association thus creates an instance of a monitor for each server that you specify. Therefore, you can have multiple instances of the same monitor running on your servers.

The Configuration utility allows you to disable an instance of a monitor that is running on a server. This allows you to suspend health or performance checking, without having to actually remove the monitor association. When you are ready to begin monitoring that server again, you simply re-enable that instance of the monitor.

Types of monitor associations

The three types of monitor associations are:

  • Monitor-to-pool association
    This type of association associates a monitor with an entire load balancing pool. In this case, the monitor checks all members of the pool. For example, you can create an instance of the monitor http for every member of the pool my_pool, thus ensuring that all members of that pool are checked.
  • Monitor-to-pool member association
    This type of association associates a monitor with an individual pool member, that is, an IP address and service. In this case, the monitor checks only that pool member and not any other members of the pool. For example, you can create an instance of the monitor http for pool member 10.10.10.10:80 of my_pool.
  • Monitor-to-node association
    This type of association associates a monitor with a specific node. In this case, the monitor checks only the node itself, and not any services running on that node. For example, you can create an instance of the monitor icmp for node 10.10.10.10. In this case, the monitor checks the specific node only, and not any services running on that node.

For more information on associating monitors with pools and pool members, see Chapter 4, Configuring Load Balancing Pools . For more information on associating monitors with nodes, see Chapter 3, Configuring Nodes .

Managing monitors

When managing existing monitors, you can display or delete them, or you can enable and disable an instance of a monitor. Note that prior to deleting a monitor, you must remove all existing monitor associations.

To display a monitor

  1. On the Main tab, expand Local Traffic.
  2. Click Monitors.
    A list of existing monitors appears.
  3. Click a monitor name.
    This displays the monitor settings and their values.

To delete a monitor

  1. On the Main tab, expand Local Traffic.
  2. Click Monitors.
    A list of existing monitors appears.
  3. Click the Select box for the monitor that you want to delete.
  4. Click Delete.
    A confirmation message appears.
  5. Click Delete.

To enable or disable a monitor instance

  1. On the Main tab, expand Local Traffic.
  2. Click Monitors.
    This displays a list of custom monitors.
  3. Click a monitor name in the list.
  4. On the menu bar, click Instances.
    This lists any existing monitor instances.
  5. For the instance you want to manage, click the Select box.
  6. Click Enable or Disable.
  7. Click Update.



Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)