Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Monitors
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

11 
An important feature of the Global Traffic Manager is set of load balancing tools called monitors. Monitors verify connections on pools and virtual servers. A monitor can be either a health monitor or a performance monitor. Monitors are designed to check the status of a pool or virtual server on an ongoing basis, at a set interval. If a pool or virtual server being checked does not respond within a specified timeout period, or the status of a pool or virtual server indicates that performance is degraded, then the Global Traffic Manager can redirect the traffic to another resource.
Some monitors are included as part of the Global Traffic Manager, while other monitors are user-created. Monitors that the Global Traffic Manager 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. For more information on monitor types, see Summary of monitor types, and Configuring monitor settings.
Monitor types
Every monitor, whether pre-configured or custom, belongs to a certain category, or monitor type. Each monitor type checks the status of a particular protocol, service, or application. For example, an HTTP monitor allows you to monitor the availability of the HTTP service on a pool member (that is a virtual server).
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 Global Traffic Manager assigns default values. For example, the following are the default values for the HTTP monitor:
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
These settings specify that an HTTP monitor is configured to check the status of an IP address every 30 seconds, to time out after 120 seconds, to timeout the probe request every 5 seconds, and specifies that the monitor does not operate in either Reverse or Transparent mode.
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 or virtual server. If you want to implement a custom monitor, you must first create the custom monitor, and then associate it with a pool or virtual server.
The Global Traffic Manager includes many different types of monitors, each designed to perform a specific type of monitoring. The monitors belong to one of three categories: simple, extended content verification (ECV), and extended application verification (EAV).
Simple monitors check the health of a resource by sending a packet using the specified protocol, and waiting for a response from the resource. If the monitor receives a response, then the health check is successful and the resource is considered up. For information about configuring monitor settings for Simple monitors, see Simple monitors.
ECV monitors check the health of a resource by sending a query for content using the specified protocol, and waiting to receive the content from the resource. If the monitor receives the correct content, then the health check is successful and the resource is considered up. For information about configuring monitor settings for ECV monitors, see Extended Content Verification (ECV) monitors.
EAV monitors check the health of a resource by accessing the specified application. If the monitor receives the correct response, then the health check is successful and the resource is considered up. For information about configuring monitor settings for EAV monitors, see External Application Verification (EAV) monitors.
Table 11.1 briefly describes the types of monitors that you can apply to your load balancing resources.
Monitor Category
Possible Object Associations
Uses Internet Control Message Protocol (ICMP) to make a simple resource check. The check is successful if the monitor receives a response to an ICMP_ECHO datagram.
link,
pool member, server,
virtual server
Monitors the associated service by sending a TCP SYN packet to the service. As soon as the monitor receives the SYN-ACK packet, the monitor marks the service as up.
pool member, server,
virtual server
Verifies the Hypertext Transfer Protocol (HTTP) service by attempting to receive specific content from a web page.
pool member, server,
virtual server
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.
pool member, server,
virtual server
Verifies the Transmission Control Protocol (TCP) service by attempting to receive specific content from a resource.
pool member, server,
virtual server
Note: You cannot configure the ignore-down-response setting of this monitor to configure a BIG-IP system to allow more than one probe attempt per interval.
server,
virtual server
link,
node
pool member, server,
virtual server
Verifies the File Transfer Protocol (FTP) service by attempting to download a specific file to the /var/tmp directory on the system. Once downloaded successfully, the file is not saved.
pool member, server,
virtual server
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.
pool member, server,
virtual server
Verifies the Lightweight Directory Access Protocol (LDAP) service by attempting to authenticate the specified user.
pool member, server,
virtual server
Verifies Microsoft® Windows SQL-based services.
pool member, server,
virtual server
Verifies the Usenet News protocol (NNTP) service by attempting to retrieve a newsgroup identification string from the server.
pool member, server,
virtual server
Verifies services based on Oracle® by attempting to perform an Oracle logon to a service.
pool member, server,
virtual server
Verifies the Post Office Protocol version 3 (POP3) service by attempting to connect to a pool, pool member, or virtual server, log on as the specified user, and log off.
pool member, server,
virtual server
Verifies the Remote Access Dial-in User Service (RADIUS) service by attempting to authenticate the specified user.
pool member, server,
virtual server
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.
node,
pool member, server,
virtual server
Generates 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.
pool member, server,
virtual server
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.
pool member, server, virtual server
Checks the status of a pool, pool member, or virtual server by issuing standard Simple Mail Transport Protocol (SMTP) commands.
pool member, server,
virtual server
Checks the current CPU, memory, and disk usage of a pool, pool member, or virtual server that is running an SNMP data collection agent, and then dynamically load balances traffic accordingly.
node,
pool member, server,
virtual server
pool member, server,
virtual server
Verifies the User Datagram Protocol (UDP) service by attempting to send UDP packets to a pool, pool member, or virtual server and receiving a reply.
pool member, server,
virtual server
Requests the URL specified in the Send setting, and finds the string specified in the Recv setting somewhere in the data returned by the URL response.
pool member, server,
virtual server
Checks the performance of a pool, pool member, or virtual server that is running the Windows Management Infrastructure (WMI) data collection agent and then dynamically load balances traffic accordingly.
node,
pool member, virtual server
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. You can find details about the settings for each monitor type in Configuring monitor settings.
When you want to monitor the health or performance of pool members or virtual servers, you can either use a pre-configured monitor, or create and configure a custom monitor.
For a subset of monitor types, the Global Traffic Manager includes a set of pre-configured monitors. A pre-configured monitor is an existing monitor with default settings already configured. You use a pre-configured monitor when the default values of the settings meet your needs.
An example of a pre-configured monitor is the http monitor. If the default values of this monitor meet your needs, you simply assign the http pre-configured monitor directly to a pool or virtual server. In this case, you do not need to use the Monitors screens, unless you simply want to view the default settings of the pre-configured monitor.
A custom monitor is a monitor that you create based on one of the allowed monitor types. (For information on monitor types, see Summary of monitor types.)
Like http, each of the custom monitors has a Type setting based on the type of service it checks (for example, 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.)
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. For example, if you create a custom monitor called my_http, the monitor can inherit the settings and values of the pre-configured monitor http. This ability to import existing setting values is useful when you want to retain some setting values for your new monitor, but modify others.
The following list shows an example of a custom HTTP monitor called my_http, which is based on the pre-configured monitor http. Note that the value of the Interval setting has been changed from the default value of 30 to a new value of 60. The other settings retain the values defined in the pre-configured monitor.
Name: my_http
Type: HTTP
Timeout: 120
You can import settings from another custom monitor instead of from a pre-configured monitor. This is useful when you want to 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 monitor such as my_oracle_server1. In this case, because the Global Traffic Manager does not provide a pre-configured Oracle monitor, a custom monitor is the only kind of monitor from which you can import setting values.
If no pre-configured or custom monitor exists that corresponds to the type of monitor you are creating, the Global Traffic Manager imports settings from a monitor template. A monitor template is an abstraction that exists within the Global Traffic Manager for each monitor type and contains a group of settings and default values. A monitor template serves as a tool for the Global Traffic Manager to use for importing settings to a custom monitor when no monitor of that type already exists.
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, select 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. For information on monitor types, see Configuring monitor settings.
If you want to check more than one service on a pool or virtual server (for example HTTP and HTTPS), you can associate more than one monitor on that pool or virtual server. For more information, see Chapter 7, Load Balancing with the Global Traffic Manager.
Checking services is not the only reason for implementing a monitor. If you want to verify only that the destination IP address is live, or that the path to it through a transparent virtual server is live, use one of the simple monitors, such as gateway_icmp. Or, if you want to verify TCP only, use the monitor tcp.
1.
On the Main tab of the navigation pane, expand Global Traffic and click Monitors.
The main monitors screen opens.
2.
Click the Create button.
The New Monitor screen opens.
3.
In the Name box, type a name for the monitor.
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.
From the Configuration list, select Advanced.
Additional fields display with default settings.
7.
Click the Finished to save your changes.
The Global Traffic Manager supports a wide variety of monitor types. Each of these monitor types contains specific settings that you can configure to ensure that the monitor accurately tests a given resource before determining if that resource is available for load balancing operations. When you configure these settings, you are creating a custom monitor for your network.
Simple monitors
These are health monitors that monitor the status of a resource.
Extended Content Verification (ECV) monitors
These are health monitors that verify service status by retrieving specific content from pool members or virtual servers.
External Application Verification (EAV) monitors
These are health or performance monitors that verify service status by accessing remote applications, using an external service-checker program.
The Global Traffic Manager provides a set of pre-configured simple monitors: gateway_icmp 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 settings and their values.
You can use a Gateway ICMP monitor for a virtual server, a server (that is, all of the virtual servers on a specified server), a pool member, a pool (that is, all of the pool members of a specified pool), or a link. This monitor uses the Internet Control Message Protocol (ICMP) to perform a simple resource check. The check is successful if the monitor receives a response to an ICMP_ECHO datagram.
Type: Gateway ICMP
Import Settings: Gateway ICMP
Interval: 30 seconds
Timeout: 120 seconds
Probe Interval: 1 second
Probe Timeout: 5 seconds
Alias Address: * All Addresses
Alias Service Port: * All Ports
A TCP Half Open monitor performs a check on the associated service by sending a TCP SYN packet to the service. If 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 packet to the service instead of completing the three-way handshake.
Import Settings: TCP Half Open
Type: TCP Half Open
Interval: 30 seconds
Timeout: 120 seconds
Probe Interval: 1 second
Probe Timeout: 5 seconds
Alias Address: * All Addresses
Alias Service Port: * All Ports
Extended Content Verification (ECV) monitors use Send String and Receive String settings in an attempt to retrieve explicit content from resources. The Global Traffic Manager provides the pre-configured monitors http, https, and tcp for these ECV monitor types:
The following sections describe each type of ECV monitor, and show the pre-configured monitor settings and their values.
You use an HTTP 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.)
Type: HTTP
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
User Name: (empty)
Password: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
You use an HTTPS monitor to check the status of Hypertext Transfer Protocol Secure (HTTPS) traffic. An HTTPS 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 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 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.
Type: HTTPS
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
Cipher List: DEFAULT:+SHA:+#DES:+kEDH
User Name: (empty)
Password: (empty)
Compatibility: Enabled
Client Key: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
The Reverse setting is an option for monitors that import settings from the https monitor. In most monitor settings, the Global Traffic Manager considers the resource available when the monitor successfully probes it. However, in some cases you may want the resource to be considered unavailable after a successful monitor test. You accomplish this configuration with the Reverse setting. For more information on Reverse mode, see Using transparent and reverse modes.
The TCP monitor attempts to receive specific content sent over TCP. The check is successful when the content matches the Receive String value. A TCP 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.
Type: TCP
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
Send String: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
EAV monitors verify applications on servers by running those applications remotely, using an external service checker program located in the directory /config/monitors.
The Global Traffic Manager provides pre-configured monitors for several of these monitor types. In cases where a pre-configured monitor does not meet your needs or does not exist, you can create a custom monitor. For more information on custom monitors, see Creating a custom monitor.
The following sections describe each type of EAV monitor and show the pre-configured monitor settings and their values.
When you use the Global Traffic Manager in a network that contains a Local Traffic Manager, you must assign a BIG-IP monitor to the Local Traffic Manager. This monitor is automatically assigned to the Local Traffic Manager if you do not manually assign it.
The BIG-IP monitor gathers metrics and statistics information that the Local Traffic Manager acquires through the monitoring of its own resources. In general, it is sufficient to assign only the BIG-IP monitor to a Local Traffic Manager. In situations where you want to verify the availability of a specific resource managed by the Local Traffic Manager, F5 Networks recommends that you first assign the appropriate monitor to the resource through the Local Traffic Manager, and then assign a BIG-IP monitor to the Local Traffic Manager through the Global Traffic Manager. This configuration provides the most efficient means of tracking resources managed by a BIG-IP system.
Type: BIG-IP
Interval: 30 seconds
Timeout: 90 seconds
Probe Timeout: 1 second
Ignore Down Response: No
Note that F5 recommends that you leave this setting at the default value for the BIG-IP monitor.
Alias Address: * All Addresses
Alias Service Port: * All Ports
Note: If the Global Traffic Manager and the Local Traffic Manager are on the same machine, you must still assign a BIG-IP monitor to the server that you added to your configuration that represents the Global Traffic Manager/Local Traffic Manager system. See Chapter 5, Defining the Physical Network, for more information.
When you use the Global Traffic Manager in a network that contains a Link Controller, you must assign a BIG-IP Link monitor to the Link Controller. This monitor is automatically assigned to the Link Controller if you do not manually assign it.
The BIG-IP Link monitor gathers metrics and statics information that the Link Controller acquires through the monitoring of its own resources.
Type: BIG-IP Link
Import Settings: bigip_link
Interval: 10 seconds
Timeout: 30 seconds
Probe Timeout: 1 second
Ignore Down Response: No
Note that F5 recommends that you leave this setting at the default value for BIG-IP Link monitor.
Alias Address: * All Addresses
Note: If the Global Traffic Manager and the Link Controller systems are on the same machine, you must still assign a BIG-IP Link monitor to the server that represents these two systems. See Chapter 5, Defining the Physical Network, for more information.
You can use an External monitor to create your own monitor type. To do this, you create a custom External monitor and within it, specify a user-supplied monitor to run.
The External Program setting specifies the name of your user-supplied monitor program. An External monitor searches the directory /config/monitors for that monitor name.
The Arguments setting allows you to specify any command-line arguments that are required.
Type: External
Import Settings: external
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
Arguments: (empty)
Variables: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
You use a FirePass® monitor to verify FirePass traffic. This monitor checks the health of FirePass systems.
Type: FirePass
Import Settings: firepass_gtm
Interval: 30 seconds
Timeout: 90 seconds
Probe Timeout: 5 seconds
Cipher List: HIGH:!ADH
User Name: gtmuser
Password: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
You use an FTP monitor to verify 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. An FTP monitor specifies a user name, a password, and a full path to the file to be downloaded.
Type: FTP
Interval: 10 seconds
Probe Timeout: 5 seconds
User Name: (empty)
Password: (empty)
Path/Filename: (empty)
Mode: Passive
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
You use an IMAP monitor to check the status of Internet Message Access Protocol (IMAP) traffic. An IMAP monitor is essentially a POP3 monitor with the addition of the Folder setting. The check is successful if the monitor is able to log onto a server and open the specified mail folder. An IMAP monitor requires that you specify a user name and password. The following list shows the settings and default values of an IMAP monitor.
Type: IMAP
Interval: 10 seconds
Timeout: 31 seconds
Probe Timeout: 5 seconds
User Name: (empty)
Password: (empty)
Folder: INBOX
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
Note: Servers checked by an IMAP monitor typically require special configuration to maintain a high level of security, while also allowing for monitor authentication.
You use an LDAP monitor to check 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. The following list shows the settings and default values of an LDAP monitor.
Type: LDAP
Interval: 10 seconds
Timeout: 31 seconds
Probe Timeout: 5 seconds
User Name: (empty)
Password: (empty)
Base: (empty)
Filter: (empty)
Security: None
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
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.
You use an MSSQL monitor to perform service checks on Microsoft SQL Server-based services such as Microsoft SQL Server versions 6.5 and 7.0.
The remainder of this section on MSSQL monitors describes prerequisite tasks, the default monitor settings, and troubleshooting tips.
Type: mssql
Interval: 30 seconds
Timeout: 91 seconds
Probe Timeout: 5 seconds
Send String: (empty)
User Name: (empty)
Password: (empty)
Database: (empty)
Receive Row: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
For an MSSQL 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 Global Traffic manager 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 the following 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.
If an MSSQL monitor cannot log on to the server, and you have checked that the specified IP address and port number or service are correct, try the following troubleshooting options:
Verify that you can log on 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 logons to SQL servers. Use this program to test whether you can log on to the server using the ISQL/w program.
Add logon accounts using the Microsoft SQL Enterprise Manager.
On the Microsoft SQL Server, you can run the SQL Enterprise Manager to add logon accounts. When first logging on the SQL Enterprise Manager, you may be prompted for the SQL server that you want to manage.

You can register servers by specifying the machine name, user name, and password. If these names are correct, the server is registered, and then you can click an icon for the server. When you expand the subtree for the server, there is an icon for logon accounts. Beneath this subtree, you can find the SQL logons. To change passwords or add new logons, right-click 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 logon, as well as which databases the logon is allowed to access. You must grant the test account access to the database you specify in the EAV configuration.
You use an NNTP 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.
Type: NNTP
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
User Name: (empty)
Password: (empty)
Newsgroup: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
You use an Oracle monitor to check the status of an Oracle database server. The check is successful if the monitor is able to connect to the server, log on as the indicated user, and log off.
Type: Oracle
Interval: 30 seconds
Timeout: 91 seconds
Probe Timeout: 5 seconds
Send String: (empty)
User Name: (empty)
Password: (empty)
Database: (empty)
Receive Row: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
The Send String setting specifies a SQL statement that the Global Traffic Manager 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 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.
You use a POP3 monitor to check the status of Post Office Protocol version 3 (POP3) traffic. The check is successful if the monitor is able to connect to the server, log on as the indicated user, and log off. A POP3 monitor requires a user name and password.
Type: POP3
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
User Name: (empty)
Password: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
You use a RADIUS monitor to 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: Configure the servers to be checked by a RADIUS monitor to maintain a high level of security while also allowing for monitor authentication.
Type: RADIUS
Interval:10 seconds
Timeout: 31 seconds
Probe Timeout: 5 seconds
User Name: (empty)
Password: (empty)
Secret: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
You use a Real Server monitor to check the performance of a pool or virtual server that is running the RealSystem Server data collection agent and 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 7, Load Balancing with the Global Traffic Manager.
The Global Traffic Manager provides a pre-configured Real Server monitor named real_server. The following list shows the settings and default values of the real_server monitor.
Type: Real Server
Import Settings: real_server
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
Method: GET
Command: GetServerStats
Metrics: ServerBandwidth: 1.5, CPUPercentUsage, MemoryUsage, TotalClientCount
Agent: Mozilla/4.0 (compatible: MSIE 5.0, Windows NT)
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 11.2 shows the complete set of server-specific metrics and metric setting default values that apply to the command GetServerStats.
The metric coefficient is a factor determining how heavily the metrics 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:
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 11.2 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 overrides 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:
You use the Scripted 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 11.1 shows a sample file that specifies a simple SMTP sequence. Note that the system always reads the lines of the file in the specified sequence.
Using a Scripted monitor, you can 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 quotation marks, the line is sent or expected 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.
Type: Scripted
Import Settings: scripted
Interval: 10 seconds
Timeout: 31 seconds
Probe Timeout: 5 seconds
File name: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
You use a SIP 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.
Type: SIP
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
Mode: UDP
Header List: (empty)
SIP Request: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
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.
You use an SMTP monitor to check the status of Simple Mail Transport Protocol (SMTP) servers. This monitor is a 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 monitor requires a domain name. The following list shows the settings and default values of an SMTP monitor.
Type: SMTP
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
Domain: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
You use an SNMP monitor to check the performance of a server running an SNMP agent such as UC Davis, for the purpose of load balancing traffic to that server. This monitor conducts an SNMP query for a specific number of times, counting the number of times the query is successful. If the number of successful queries matches the number that you set when configuring the monitor, the Global Traffic Manager considers the resource available.
Performance monitors are generally used with dynamic ratio load balancing. For more information on performance monitors and dynamic ratio load balancing, see Chapter 7, Load Balancing with the Global Traffic Manager.
Unlike health monitors, performance monitors do not report on the status of a pool, pool member, or virtual server; they report on the status of the server itself. The exception to this is when you assign the monitor to a Cisco, Alteon, Extreme, or Radware server. In those situations, the monitor can obtain availability information on the virtual servers associated with that server. On Foundry servers, you can only obtain the administrative status of the virtual server.
The Global Traffic Manager provides a pre-configured SNMP monitor named snmp_gtm. The following list shows the settings and values of the snmp_gtm pre-configured monitor.
Type: SNMP
Import Settings: snmp_gtm
Interval: 90 seconds
Timeout: 180 seconds
Probe Interval: 1 second
Probe Timeout: 1 second
Community: public
Port: 161
Alias Address: * All Addresses
Alias Service Port: * All Ports
Pre-configured monitors are not user-modifiable. Thus, if you want to change the values for the SNMP monitor settings, you must create an SNMP custom monitor. Possible values for the Version setting are v1, v2c, and Other.
The Global Traffic Manager provides a pre-configured SNMP monitor named snmp_link. The following list shows the settings and values of the snmp_link pre-configured monitor.
Type: SNMP Link
Import Settings: snmp_link
Interval: 10 seconds
Timeout: 30 seconds
Probe Interval: 1 second
Probe Timeout: 5 seconds
Community: public
Port: 161
Alias Address: * All Addresses
Unlike health monitors, performance monitors do not report on the status of pool, pool member, or virtual server. Performance monitors are generally used with dynamic ratio load balancing. For more information on performance monitors and dynamic ratio load balancing, see Chapter 7, Load Balancing with the Global Traffic Manager.
Pre-configured monitors are not user-modifiable. Thus, if you want to change the values for the SNMP Link monitor settings, you must create an SNMP Link custom monitor.
You use a SOAP monitor to test 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. The following list shows the settings and default values of a SOAP monitor.
Type: SOAP
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
User Name: (empty)
Password: (empty)
Protocol: HTTP
Possible values are HTTP and HTTPS.
URL Path: (empty)
Namespace: (empty)
Method: (empty)
Parameter Type: bool
Possible values are: bool, int, long, and string.
Return Type: bool
Possible values are: bool, int, short, long, float, double, and string.
Return Value: (empty)
Expect Fault: No
Possible values are No and Yes.
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
You use a UDP monitor to check the status of User Datagram Protocol (UDP) packets. A UDP monitor sends one or more UDP packets to a target pool, pool member, or virtual server.
Type: UDP
Interval: 30 seconds
Timeout: 120 seconds
Probe Interval: 1 second
Probe Timeout: 5 seconds
Send String: default send string
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
Important: The value in seconds of the Timeout Packets setting must be lower than the value of the Interval setting.
When using a UDP monitor to check a pool or virtual server, you must also enable another monitor type, such as HTTP, to monitor the pool or virtual server. Until both a UDP monitor and another type of monitor report the status of the UDP service as up, the UDP service receives no traffic. See Table 11.3 for details.
And another monitor reports status as
You use a WAP monitor to check Wireless Application Protocol (WAP) servers. The WAP monitor requests a URL (the Send String setting), finds the string in the Receive String setting in the data returned by the URL response. The following list shows the settings and default values of a WAP monitor.
Type: WAP
Interval: 10 seconds
Timeout: 31 seconds
Probe Timeout: 5 seconds
Send String: (empty)
Secret: (empty)
Server ID: (empty)
Call ID: (empty)
Session ID: (empty)
Alias Address: * All Addresses
Alias Service Port: * All Ports
Debug: No
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 resource. If this a null string and RADIUS accounting has been requested (accounting port is non-zero), then the WAP server resource is assumed to also be the RADIUS resource.
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.
You use a WMI monitor to check the performance of a pool or virtual server that is running the Windows Management Infrastructure (WMI) data collection agent and then dynamically load balances traffic accordingly.
Unlike health monitors, performance monitors do not report on the status of a pool, pool member, or virtual server. 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 7, Load Balancing with the Global Traffic Manager.
Type: WMI
Interval: 30 seconds
Timeout: 120 seconds
Probe Timeout: 5 seconds
User Name: (empty)
Password: (empty)
Method: POST
URL: /scripts/F5lsapi.dll
Command: GetCPUInfo, GetDiskInfo, GetOSInfo
Metrics: LoadPercentage, DiskUsage, PhsyicalMemoryUsage
Agent: Mozilla/4.0 (compatible: MSIE 5.0; Windows NT)
Post: RespFormat=HTML
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 11.4 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.
Default Coefficient
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.
By default, the value for the Alias Address setting for most monitors is set to the wildcard * Addresses, and the Alias Service Port setting is set to the wildcard * Ports (exceptions to this rule are the WMI and Real Server monitors). This value causes the monitor instance created for a pool or virtual server to take that resources 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 or virtual server.
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:
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:
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 monitors, you can use the special settings get or hurl in place of Send String and Receive String statements, respectively.
The normal and default behavior for a monitor is to ping the destination pool or virtual server by an unspecified route, and to mark the resource 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 or virtual server. When you create a custom monitor and set the Transparent setting to Yes, the Global Traffic Manager forces the monitor to ping through the pool or virtual server with which it is associated (usually a firewall) to the pool or virtual server. (In other words, if there are two firewalls in a load balancing pool, the destination pool or virtual server is always pinged through the pool or virtual server specified and not through the pool or virtual server selected by the load balancing method.) In this way, the transparent pool or virtual server is tested: if there is no response, the transparent pool or virtual server 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 firewall (10.10.10.101:80).
This causes the monitor to check the address 10.10.10 53:80 through 10.10.10.101:80. (In other words, the Global Traffic Manager 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 virtual servers, see Associating monitors with resources.
Reverse setting
In most monitor settings, the Global Traffic Manager considers the resource available when the monitor successfully probes it. However, in some cases you may want the resource to be considered unavailable after a successful monitor test. You accomplish this configuration with the Reverse setting. With the Reverse setting set to Yes, the monitor marks the pool or virtual server 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.
Table 11.5 shows the monitors that contain the Transparent setting, the Reverse setting, or both.
If all iQuery® connections between a Global Traffic Manager and a BIG-IP system are lost, by default the Global Traffic Manager marks all of the virtual servers on the BIG-IP system as down. However, you can configure the Global Traffic Manager so that even when all iQuery connections from the Global Traffic Manager to the BIG-IP system are lost, the Global Traffic Manager marks the virtual servers as down only when the monitors associated with the virtual servers time out.
To do this, you change the value of the virtuals-depend-on-server-state option to no. Note that even after you set this option to no, as long as the iQuery connections between the Global Traffic Manager and the BIG-IP system are still connected, when the Global Traffic Manager receives a down response for a virtual server from the BIG-IP system, it immediately marks that virtual server down.
The default value of the virtuals-depend-on-server-state option is yes. To change the value to no, use the following tmsh command:
For information about the command syntax you use to change this variable, see the gtm settings component in the Traffic Management Shell (tmsh) Reference Guide.
By default, an ECV monitor marks a virtual server as unavailable immediately after receiving a down response from the virtual server. If you want to configure a Global Traffic Manager ECV monitor to allow more than one probe attempt before a failure is detected, you can enable the Ignore Down Response setting on the monitor. When you enable this option, the monitor ignores a down response from the system it is monitoring. Assuming the Interval value is a fraction of the Timeout value, the system sends multiple probes per timeout period. The monitor only marks the system down if it does not receive an up response within the specified monitor timeout period.
1.
On the Main tab of the navigation pane, expand Global Traffic and click Monitors.
The main screen for monitors opens.
2.
Click the name of the monitor that you want to configure.
The properties screen for the monitor appears.
3.
From the Configuration list, select Advanced.
Additional fields display with default settings.
4.
For Ignore Down Response setting, click the Yes button.
5.
Click the Update button to save your changes.
Once you create a monitor and configure its settings, the final task is to associate the monitor with the resources to be monitored. The resources that can be monitored are nodes, servers, pools, pool members, and links.
When you associate a monitor with a resource, the Global Traffic Manager automatically creates an instance of that monitor for that resource. Therefore, you can have multiple instances of the same monitor.
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.
Some monitor types are designed for association only with nodes (IP address), while other monitor types are intended for association only with pools and virtual servers (IP address and service port). Therefore, when you use the Configuration utility to associate a monitor with a pool or virtual server, the utility displays only those pre-configured monitors that are designed for association with that object type. For more information about the monitors that you can assign to different objects, see Table 11.1.
Monitor-to-pool association
Links 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 the pool my_pool, thus ensuring that all members of that pool are checked.
Monitor-to-pool member association
Links a monitor with a pool member within a given pool. For example, you can create an instance of the monitor FTP for specific pools within the pool my_pool, ensuring that only specific pool members are verified as available through the FTP monitor.
Monitor-to-virtual server association
Links a monitor with a specific virtual server. In this case, the monitor checks only the virtual server itself, and not any services running on that virtual server. For example, you can create an instance of the monitor http for virtual server 10.10.10.10. In this case, the monitor checks the specific virtual server only, and not any services running on that virtual server.
The procedures for adding and removing monitors are specific to the resource. See Chapter 5, Defining the Physical Network, and Chapter 6, Defining the Logical Network, for information on adding and removing monitors from a resource.
In addition to adding and removing monitors from network resources, you can interact with monitors in the following ways:
Because you can create a large number of monitors to accurately track the performance and availability of your network resources, it is helpful to view monitor settings to determine if a given monitor is the correct one for a given resource.
1.
On the Main tab of the navigation pane, expand Global Traffic and click Monitors.
The main monitors screen opens.
2.
Click a monitor name.
The properties screen of the monitor opens.
In the event that your configuration of the Global Traffic Manager no longer requires a specific monitor, you can delete the monitor. You cannot delete a monitor that has one or more instances assigned to resources on your network. See Chapter 5, Defining the Physical Network, and Chapter 6, Defining the Logical Network, for information on adding and removing monitors from a resource.
1.
On the Main tab of the navigation pane, expand Global Traffic and click Monitors.
The main monitors screen opens.
3.
Click the Delete button.
A confirmation message opens.
4.
Click the Delete button to delete the monitor.
When you add a monitor to a resource, the Global Traffic Manager creates a copy of that monitor, or instance, and assigns it to that resource. You can enable or disable these instances as needed. For example, if you wanted to temporarily suspend the monitoring of a given virtual server that is undergoing maintenance, you can disable the monitor for that virtual server and then re-enable it when the maintenance is complete.
1.
On the Main tab of the navigation pane, expand Global Traffic and click Monitors.
The main monitors screen opens.
2.
Click a monitor name in the list.
The properties screen for the monitor opens.
3.
On the menu bar, click Instances.
The monitor instance screen opens.
5.
Click the Enable or Disable button, as appropriate.
6.
Click the Update button to save your changes.
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)