Manual Chapter : BIG-IP Reference Guide v4.5: Monitors

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 4.6.1, 4.6.0, 4.5 PTF-08, 4.5 PTF-07, 4.5 PTF-06, 4.5 PTF-05, 4.5 PTF-04, 4.5 PTF-03, 4.5 PTF-02, 4.5 PTF-01, 4.5.9, 4.5.0
Manual Chapter


11

Monitors


Introducing monitors

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

  • Monitor types
    The BIG-IP system includes several types of monitors from which to choose, depending on the type of node or service to be monitored. For example, an http monitor allows you to monitor the availability of the HTTP service on a node. A wmi monitor allows you to monitor the performance of a node that is running the Windows Management Instrumentation (WMI) software. An icmp monitor simply determines whether the status of the node address itself is up or down. For more information on monitor types, see Summary of monitor types and Choosing a monitor .
  • Monitor attributes
    Each monitor type contains a set of attributes to which default values are assigned. For example, the icmp monitor has the following attributes and values:


    monitor icmp {
    #type icmp
    interval 5
    timeout 16
    dest *
    }
     


    The attributes above specify that the icmp monitor is configured to check the status of an IP address every five seconds, and to time out every 16 seconds. The destination IP address that the monitor checks is specified by the dest attribute. In the above example, all IP addresses with which the monitor is associated are checked. For more information on monitor attributes, see Summary of monitor attributes and Choosing a monitor .

  • Monitor implementation
    To implement a monitor, you simply open the Confguration utility, display the Monitors screen, and select a monitor for the type of node or service you want to check. If you want to adjust the default values of the monitor attributes, you can do that, thus creating a monitor that is customized for your particular needs. You then associate the monitor with the appropriate node. For more information on implementing a monitor, see Configuring a monitor .

Summary of monitor types

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

 

Monitors

Description

Simple monitors

icmp

Checks the status of a node, using Internet Control Message Protocol (ICMP).

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.

https_443

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 the BIG-IP system.

pop3

Verifies the Post Office Protocol (pop3) service by attempting to connect to a node, log on as the specified user, and log off.

smtp

Checks the status of a node by issuing standard Simple Mail Transport Protocol (SMTP) commands.

nntp

Verifies the Usenet News protocol (NNTP) service by attempting to retrieve a newsgroup identification string from the server.

sql

Verifies SQL-based services by attempting to perform an SQL login to a service.

imap

Verifies the Internet Message Access Protocol (IMAP) by attempting to retrieve a specified message number. This monitor is similar to the pop3 monitor.

radius

Verifies the Remote Access Dial-in User Service (RADIUS) service by attempting to authenticate the specified user.

ldap

Verifies the Lightweight Directory Access Protocol (LDAP) service by attempting to authenticate the specified user.

udp

Verifies the User Datagram Protocol (UDP) service by attempting to send UDP packets to a node and receiving a reply.

real_server

Checks the performance of a node that is running the RealServer data collection agent and then dynamically load balances traffic accordingly.

wmi

Checks the performance of a node that is running the Windows Management Infrastructure (WMI) data collection agent and then dynamically load balances traffic accordingly.

snmp_dca

Checks the current CPU, memory, and disk usage of a 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 node that is running an SNMP data collection agent and then dynamically load balances traffic accordingly.

 

Summary of monitor attributes

Table 11.2 contains a complete list of all possible monitor attributes, along with their definitions. Note that each monitor template contains only a subset of these attributes.

 

Attribute

Definition

interval <seconds>

Ping frequency time interval in seconds.

timeout <seconds>

Ping timeout in seconds.

dest <node_addr>

Ping destination node. Usually has a value of * for node address monitors and *:* for all others, causing the monitor instance to ping the address or address:port for which it is instantiated. Specifying address and/or port forces the destination to that address/port.

send <string>

Send string for ECV. Default send and recv values are empty (""), matching any string.

recv <string>

Receive expression for ECV. Default send and recv values are empty (""), matching any string.

get <string>

For the http and https monitors get replaces the recv statement, automatically filling in "GET". For the ftp monitor get can be used to specify a full path to a file. This automatically fills in dest.

url

For the http and https, and ftp monitors, url replaces the recv statement, supplies a URL and automatically fills in dest with the URL address.

reverse

A mode that sets the node down if the received content matches the recv string.

transparent

A mode that forces pinging through the node to the dest address for transparent nodes, such as firewalls.

run <program>

An external user-added EAV program.

args <program_args>

List of command line arguments for external program. The args are quoted strings set apart by spaces.

username <username>

User name for services with password security. For ldap this is a distinguished, that is, LDAP-format user name.

password <password>

Password for services with password security.

newsgroup <newsgroup>

Newsgroup, for type nntp EAV checking only

database <database>

Database name, for type sql EAV checking only.

domain <domain_name>

Domain name, for type smtp EAV checking only

secret

Shared secret for radius EAV checking only.

folder

Folder name for imap EAV checking only.

message_num

Optional message number for imap EAV.

base

Starting place in the LDAP hierarchy from which to begin the query, for ldap EAV checking only.

filter

LDAP-format key of what is to be searched for, for ldap EAV checking only.

sendpackets <num>

Number of packets to send when using the udp monitor.

timeoutpackets <seconds>

Timeout in seconds for receiving UDP packets.

 

Working with monitor templates

The BIG-IP system provides a variety of monitors in template form. A monitor template consists of a set of attributes, with default values assigned to them. Some of these monitors are usable as is (assuming that their default values are acceptable). These are called default monitors. In most cases, however, a monitor template is used strictly as a basis for creating a new monitor that changes the attribute values. These monitors are called custom monitors.

Once you have chosen or created the monitor you want to use to monitor a node, you use the Configuration utility or the bigpipe node command to associate the monitor with that node.

All monitor templates are contained in one of the following read-only files, depending on your licensed product:

  • /etc/base_monitors.3dns
  • /etc/base_monitors.flb
  • /etc/base_monitors.lb
  • /etc/base_monitors.clb
  • /etc/base_monitors.ha
  • /etc/base_monitors.ssl
  • /etc/base_monitors.lc

Default monitors

A default monitor is a monitor template that is used as is, that is, with the default values assigned to its attributes. An example of a default monitor is the icmp monitor, which uses the default values contained in the icmp monitor template. A health monitor of the simplest type, the icmp monitor is automatically associated with every node in a pool and checks a node address through a ping response. This automatic association is in the form of the following entry in the bigip.conf file:

node * monitor use icmp

Figure 11.1 shows the icmp monitor template.

Figure 11.1 The icmp monitor template


monitor type icmp {
interval 5
timeout 16
dest *
}
 

The icmp monitor template has three attributes, interval, timeout, and dest, each with a default value. (All monitor templates have these three basic attributes. Other monitor templates have additional attributes as required by the service type.)

To change the interval and timeout values of a default monitor, you need to configure a custom monitor, as described in the following section.


Custom monitors

A custom monitor inherits the attributes and the default values of a monitor template. Once you have created the custom monitor, you can change the attribute values as required.

For example, you can create a custom monitor called my_icmp, based on the icmp monitor template. When creating the my_icmp custom monitor, you can specify those attribute values that you want to change. For example, if you want to change the timeout value from the default value of 16 to a value of 20, you can define the custom monitor as follows:

b monitor my_icmp '{ use icmp timeout 20 }'

This creates a new monitor called my_icmp, based on the monitor template icmp, with a timeout value of 20. As shown in Figure 11.2 , you can display the custom monitor using the command b monitor my_icmp show.

Figure 11.2 Custom icmp monitor


monitor my_icmp{
#type icmp
"icmp"
interval 5
timeout 20

dest *
}
 

Selecting a template is straightforward. Like icmp, each of the templates has a type 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 templates, like https_443, and the external template, which calls a user-supplied program.)

To select a template, simply choose the one that corresponds in name and/or type to the service you want to check. If more than one service is to be checked, for example http and https, more than one monitor can be placed on the node. (This creates a rule, namely that the node will not be considered up unless both monitors run successful checks.) You may not want to check all services available on a node specifically. 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 templates, icmp or tcp_echo. If you want to verify TCP only, use the monitor template tcp.

For procedures on selecting and configuring a monitor template, see Configuring a monitor .

Choosing a monitor

The first task in implementing a BIG-IP monitor is to select a monitor template. Monitor templates fall into three categories:

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

The following sections list and describe these monitor types.


Simple monitors

Simple monitors are those that check only node addresses, and verify only simple connections. Templates for these monitors are icmp and tcp_echo.

Note


The templates icmp and tcp_echo are both usable as is, that is, they may be associated with nodes. It is important to understand, however, that using a template as is means that you are using the default attribute values. To change any of these values, you have to configure a custom monitor based on the template.
icmp

The icmp template uses Internet Control Message Protocol to make a simple node check. The check is successful if a response to an ICMP_ECHO datagram is received. The icmp template has no attributes other than the standard interval, timeout, and dest.

Figure 11.3 The icmp monitor template


monitor icmp {
#type icmp
interval 5
timeout 16
dest *
}
 

The transparent mode is an option for monitors derived from the icmp template. For more information about transparent mode, refer to Using transparent and reverse modes .


tcp_echo

The tcp_echo template verifies Transmission Control Protocol (TCP) connections. The check is successful if the BIG-IP system receives a response to a TCP ECHO message. The tcp_echo template 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 tcp_echo, you must ensure that TCP ECHO is enabled on the nodes being monitored.

Figure 11.4 The tcp_echo monitor template


monitor tcp_echo {
#type tcp_echo
interval 5
timeout 16
dest *
transparent
}
 

The transparent mode is an option for monitors derived from the tcp_echo template. For more information about transparent mode, refer to Using transparent and reverse modes .


Extended Content Verification (ECV) monitors

ECV monitors use send and recv statements in an attempt to retrieve explicit content from nodes. These monitors include http, https and tcp.

Note


The templates http, https, https_443, and tcp are all usable as is, and you may associate them with nodes. It is important to understand, however, that using a template as is means that you are using the default attribute values. To change any of these values, you have to configure a custom monitor based on the template.
tcp

A tcp monitor attempts to receive specific content sent over TCP. The check is successful when the content matches the recv expression. A tcp monitor takes a send string and a recv expression. If the send string is left blank, the service is considered up if a connection can be made. A blank recv string matches any response. Both transparent and reverse modes are options. For more information about transparent and reverse modes, refer to Using transparent and reverse modes .



Figure 11.5 The tcp monitor template


monitor tcp {
#type tcp
interval 5
timeout 16
dest *:*
send ""
recv ""
//
//transparent
}
 

http

The http template is used to monitor 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, sends a user name and password. The check is successful when the content matches the recv expression. An http monitor uses a send string, a recv expression, a username, a password, and optional get, url, and transparent statements. (If there is no password security, use blank strings [""] for username and password.) The optional get statement replaces the send statement, automatically filling in the string "GET". Thus the following two statements are equivalent:

send "GET/"
get "/"

The optional url statement takes the HTTP URL as a value and automatically fills in the dest value with the address to which the URL resolves. Both transparent and reverse modes are also options. For more information about transparent and reverse modes, refer to Using transparent and reverse modes . For more information about the get and url statements, refer to Using send, receive, url, and get statements .

Figure 11.6 The http monitor template


monitor http {
#type http
interval 5
timeout 16
dest *:*
send "GET /"
recv ""
username ""
password ""
//get
//url
//
//transparent

//reverse
}
 
Figure 11.6 shows the http monitor template.
https and https_443

The https and https_443 templates are used to monitor Hypertext Transfer Protocol Secure (HTTPS) traffic. An https or https_443 monitor attempts to receive specific content from a web page protected by SSL security. The check is successful when the content matches the recv expression. An https or https_443 monitor uses a send string, a recv expression, and a username and password. (If there is no password security, use blank strings [""] for username and password.) The optional get statement replaces the send statement, automatically filling in the string "GET". Thus, the following two statements are equivalent:

send "GET/"
get "/"

The optional url statement takes the HTTPS URL as a value and automatically fills in the dest value with the address to which the URL resolves

Figure 11.7 The https monitor template


monitor https {
#type https
interval 5
timeout 16
dest *:*
send "GET /"
recv ""
//get
//url
username ""
password ""

//reverse
}
 
. Figure 11.7 shows the https monitor template.

Figure 11.8 shows the https_443 monitor template.

Figure 11.8 The https_443 monitor template


monitor https_443 {
#type https
interval 5
timeout 16
dest *:443*
send "GET /"
recv ""
//get
//url
username ""
password ""

//reverse
}
 

The reverse mode is an option for monitors derived from the https and https_443 templates. For more information about reverse mode, refer to Using transparent and reverse modes .


External Application Verification (EAV) monitors

EAV monitors verify applications on the node by running those applications remotely, using an external service checker program located in the directory /user/local/lib/pingers. These include ftp, pop3, smtp, sql, nntp, imap, ldap, and radius. Also included is the template external, which has a run attribute to specify a user-added external monitor.


external

The BIG-IP system allows you to create your own monitor types. The external template is then used to find these user-supplied monitors and execute them.

The external monitor template includes a run attribute that you use to specify the name of your user-supplied monitor. By default, the external monitor searches the directory /user/local/lib/pingers for that monitor name. If the user-supplied monitor resides elsewhere, a fully qualified path name must be entered.

The run attribute of an external monitor requires the executable name of the user-supplied monitor, and the args attribute allows you to specify any command line arguments required.

Figure 11.9 shows the external monitor template, with the default attribute values.


monitor external {
#type external
interval 5
timeout 16
dest *:*
run ""
args ""
}
 

Figure 11.9 The external monitor template

For example, suppose the program my_pinger is to be run with a -q option, so that it is entered on the command line as follows:

my_pinger -q

This monitor might be specified as follows:

b monitor custom '{ use external run "my_pinger" args "-q" }'

Alternatively, you may pass arguments to the external monitor as environment variables. For example, you might want to enter this command:

/var/my_pinger /www/test_files/first_test

This could be specified in the conventional manner:

b monitor custom '{ use external run "/var/my_pinger" args "www/test_files/first_test" }'

It could also be specified in this way:

b monitor custom '{ use external run "/var/my_pinger" DIRECTORY "www/test_files" FILE "first_test" }'

This defines the monitor as shown in Figure 11.10 .

Figure 11.10 A monitor derived from the external monitor template


monitor custom {
use external
run "/var/my_pinger"
DIRECTORY "www/test_files"
FILE "first_test" }
 

This frees the monitor definition from the rigidity of a strictly ordered command line entry. The arguments are now order-independent and may be used or ignored by the external executable.


ftp

The ftp template is used to monitor File Transfer Protocol (FTP) traffic. The monitor attempts to download a specified file to the /var/tmp directory, and if the file is retrieved, the check is successful. The ftp monitor takes a get statement, a username, and a password. The get statement takes the full path to the file as a value. The optional url statement may be used in place of get. The url takes the FTP URL as a value and automatically fills in the dest value with the address the URL resolves to. (For more information about the get and url statements, refer to Using send, receive, url, and get statements .)

Figure 11.11 shows the ftp monitor template, with the default attribute values.


monitor ftp {
#type ftp
interval 10
timeout 31
dest *:*
username ""
password ""
get ""
//url
}
 

Figure 11.11 The ftp monitor template


imap

The imap template is used to monitor Internet Message Access Protocol (IMAP) traffic. The imap monitor is essentially a pop3 monitor with the addition of the attribute folder, which takes the optional key message_num. The check is successful if the specified message number is retrieved. An imap monitor requires username, password, and a folder. It also takes an optional message number, message_num.

Figure 11.12 The imap monitor template


monitor imap {
#type imap
interval 5
timeout 16
dest *:*
username ""
password ""
folder ""
//message_num ""
}
 

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

The ldap template is used to monitor Lightweight Directory Access Protocol (LDAP) servers. LDAP 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 username, a password, and a base and a filter string. The username is a distinguished name, that is, an LDAP-format user name. The base is the starting place in the LDAP hierarchy from which to begin the query. The filter is an LDAP-format key of the search item.

Figure 11.13 The ldap monitor template


monitor ldap {
#type ldap
interval 5
timeout 16
dest *:*
username ""
password ""
base ""
filter ""
}
 

nntp

The nntp template is used to monitor 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 username and password.



Figure 11.14 The nntp monitor template


monitor nntp {
#type nntp
interval 5
timeout 16
dest *:*
username ""
password ""
newsgroup ""
}
 
Figure 11.14 shows the nntp monitor attributes and their default values.
pop3

The pop3 template is used to monitor 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. The pop3 monitor requires username and password.

Figure 11.15 The pop3 monitor template


monitor pop3 {
#type pop3
interval 5
timeout 16
dest *:*
username ""
password ""
}
 

radius

The radius template is used to monitor Remote Access Dial-in User Service (RADIUS) servers. The check is successful if the server authenticates the requesting user. A radius monitor requires a username, a password, and a shared secret string secret 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 11.16 The radius monitor template


monitor radius {
#type radius
interval 5
timeout 16
dest *
username ""
password ""
secret ""
}
 

real_server

The real_server performance monitor checks the performance of a node that is running the RealSystem Server data collection agent and 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, Pools .

Note


Unlike health monitors, performance monitors do not report on the status of a node.
smtp

The smtp template is used to monitor Simple Mail Transport Protocol (SMTP) servers. An smtp monitor is an extremely simple 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.

Figure 11.17 The smtp monitor template


monitor smtp {
#type smtp
interval 5
timeout 16
dest *:*
domain ""
}
 

snmp_dca

The snmp_dca performance monitor is used for load balancing traffic to servers that are running an SNMP agent, such as UC Davis or Windows 2000. In addition to defining ratio weights for CPU, memory, and disk use, you can also define weights for use by users. Figure 11.18 shows the snmp_dca monitor template, with the default attribute values.

Figure 11.18 snmp_dca monitor template


monitor type snmp_dca {
#type snmp_dca
interval 10
timeout 30
dest *:161
agent_type "UCD"
cpu_coefficient "1.5"
cpu_threshold "80"
mem_coefficient "1.0"
mem_threshold "70"
disk_coefficient "2.0"
disk_threshold "90"
}
 

Performance monitors are generally used with dynamic ratio load balancing. For more information on performance monitors and dynamic ratio load balancing, see Chapter 4, Pools .

Note


Unlike health monitors, performance monitors do not report on the status of a node.
snmp_dca_base

Like the snmp_dca monitor, the snmp_dca_base performance monitor is for load balancing traffic to servers that are running an SNMP agent, such as UC Davis or Windows 2000. However, this template should be used only when you want the load balancing destination to be based solely on user data, and not CPU, memory, or disk use. Figure 11.19 shows the snmp_dca_base monitor template, with the default attribute values.

Figure 11.19 snmp_dca_base monitor template


monitor type snmp_dca_base {
#type snmp_dca_base
interval 10

timeout 30
dest *:161
}
 

Performance monitors are generally used with dynamic ratio load balancing. For more information on performance monitors and dynamic ratio load balancing, see Chapter 4, Pools .

Note


Unlike health monitors, performance monitors do not report on the status of a node.
sql

The sql template is used for service checks on SQL-based services such as Microsoft SQL Server versions 6.5 and 7.0, and also Sybase. The service checking is accomplished by performing an SQL login to the service. An executable program, tdslogin performs the actual login. The check is successful if the login succeeds.

An sql monitor requires a database (for example, "server_db"), username, and password.

Figure 11.20 The sql monitor template


monitor sql {
#type sql
interval 5
timeout 16
dest *:*
username ""
password ""
database ""
}
 

SQL service checks may require manual testing before being implemented in a monitor, as follows:

cd /usr/local/lib/pingers

./tdslogin 192.168.1.1 1433 mydata user1 mypass1

Replace the IP address, port, database, user, and password in this example with your own information.

You should receive the message:

Login succeeded!

If you receive the connection refused message, verify that the IP and port are correct.

If you are still having trouble, you should verify that you can log in using another tool. For example, if you have Microsoft NT SQL Server version 6.5, there is a client program ISQL/w included with the SQL software. This client program performs simple logins to SQL servers. Use this program to test whether you can login using the ISQL/w program before attempting logins from the BIG-IP system.

On the SQL Server, you can run the SQL Enterprise Manager to add logins. When first entering the SQL Enterprise Manager, you may be prompted for the SQL server to manage.

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

Underneath 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 open an option to Add login. 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.


udp

The udp template is used when sending User Datagram Protocol (UDP) packets. Designed to check the status of a UDP service, the udp monitor sends one or more UDP packets to a target node. Figure 11.21 shows the attributes of a udp monitor template, with the default values. As shown in this figure, the value in seconds of the timeoutpackets attribute should be lower than the value of the interval attribute

Figure 11.21 The udp monitor template


monitor udp {
#type udp
interval 5
timeout 16
dest *:*
send ""
sendpackets "2"

timeoutpackets "3"
}
 
.

When using a udp monitor to monitor a node address, you must also enable another node address monitor, such as icmp, to monitor the node address.


 

If the udp monitor reports node status as

And the node address monitor reports node address status as

Then the UDP service is...

up

up

up

up

down

down

down

up

down

down

down

down

 

Until both the udp monitor and the other node address monitor report the status of the UDP service as up, the UDP service receives no traffic.


wmi

The wmi performance monitor checks the performance of a node that is running the Windows Management Infrastructure (WMI) data collection agent and 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, Pools .

Note


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

Configuring a monitor

The second task in creating a monitor and placing it in service is to configure the monitor from the monitor template. Configuring a monitor consists of giving it a name distinct from the monitor template name and assigning values to any attributes for which default values need to be changed. You can also add any optional attributes, such as transparent or reverse, that are not present by default.

For special considerations related to changing the default values of monitor attributes, see Changing attribute values .


Configuration procedures

You can configure a monitor from a template using the Configuration utility or the bigpipe monitor command.


To configure a monitor using the Configuration utility
  1. In the navigation pane, click Monitors.
    The Network Monitors screen opens.
  2. Click the Add button.
    The Add Monitor screen opens.
  3. In the Add Monitor screen, type in the name of your monitor (it must be different from the monitor template name), and select the monitor template you want to use.
  4. Click the Next button and you are guided through the configuration of your monitor.
  5. When you have finished configuring the monitor, click Done.

To configure a monitor from the command line

Use the bigpipe monitor command to configure the monitor at the command line. If you are defining the monitor with all attributes set to their default values, type:

b monitor <name> { use <template_name> }

If you want to set one or more attributes to a new value, specify only those attributes and their values. For example, to create a tcp_echo monitor my_tcp_echo in bigpipe using the default values for the attributes interval, timeout, and dest, you type:

b monitor my_tcp '{ use tcp_echo }'

If you are changing any of the default values, you need to specify only these changes. For example:

b monitor my_tcp-echo '{ use tcp_echo interval 10 timeout 20 }'

If you are using an optional attribute, such as transparent, add it to the list:

b monitor my_tcp-echo '{ use tcp_echo interval 10 timeout 20 transparent dest 198.192.112.13:22}'


Changing attribute values

Each monitor has a set of attributes with default values assigned. The following sections contain information that is useful when changing these default values.


Entering string values

Except for interval, timeout, and dest, you should enter all attribute values as quoted strings, even if they are numeric, as in the case of code numbers.


Setting destinations

By default, the value for the dest attribute in all monitor templates is set to the wildcard "*" or "*:*". This value causes the monitor instance created for a 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 dest value, by creating a custom monitor. This is referred to as node and port aliasing. An explicit value for the dest attribute is used to force the instance destination to a specific address and/or port which may not be that of the node.

Specifying an explicit value for the dest attribute causes the monitor to ping that forced destination by an unspecified path. Suppose, for example, that the association that was performed using http instead used the custom monitor my_http with a dest value of *:443. The node association command is identical except that http is now replaced with my_http:

b node 11.12.11.20:80 11.12.11.21:80 11.12.11.22:80 monitor use my_http

This creates three instances of the monitor with the following dest values as shown in Figure 11.22 .

Figure 11.22 Node ports aliased


+- NODE 11.12.11.20:80 UP
| |
| +- my_http
| 11.12.11.20:443 up enabled
|
+- NODE 11.12.11.21:80 UP
| |
| +- my_http
| 11.12.11.21:443 up enabled
|
+- NODE 11.12.11.22:80 UP
|
+- my_http
11.12.11.22:443 up enabled
 

This is referred to as port aliasing. The node itself can also be aliased, by assigning an explicit address to dest. For example, dest could be set to 11.11.11.1:80. This is called node aliasing and for the nodes 11.12.11.20:80, 11.12.11.21:80, and 11.12.11.22:80 it produces the following instances, (which are in fact one instance associated with three different nodes) as shown in Figure 11.23 .

Figure 11.23 Node addresses aliased


+- NODE 11.12.11.20:80 ADDR UP
| |
| +- my_http
| 11.11.11.1:80 checking enabled
|
+- NODE 11.12.11.21:80 ADDR UP
| |
| +- my_http
| 11.11.11.1:80 checking enabled
|
+- NODE 11.12.11.22:80 ADDR UP
|
+- my_http
11.11.11.1:80 checking enabled
 

Using send, receive, url, and get statements

The ECV monitor templates http, https, and tcp have the attributes send and recv for the send string and receive expression, respectively.

The most common send string is "GET /" which retrieves a default HTML page for a web site. To retrieve a specific page from a web site, enter a fully qualified path name:

"GET /www/support/customer_info_form.html"

The receive expression is the text string the monitor looks for in the returned resource. The most common receive 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 recv value "". In this case, any content retrieved is considered a match. If both send and recv are left empty, only a simple connection check is performed.

For http and ftp, the special attributes get or url may be used in place of send and recv statements. For the ftp monitor, the get attribute specifies the full path to the file to retrieve.

The attribute url takes the URL as a value and automatically fills in the dest value with the address to which the URL resolves. The third statement below is equivalent to the first two combined:

dest 198.192.112.13:22
get "/"

url "ftp://www.my_domain.com/"


Using transparent and reverse modes

The normal and default behavior for a monitor is to ping the dest node by an unspecified route and to mark the node up if the test is successful. However, two other modes, transparent and reverse, are also available. These modes are optional and are specified by the transparent and reverse attributes.

Figure 11.4 shows the monitors that have the transparent and reverse attributes.


 

Monitor

Attribute

tcp

transparent

reverse

http

transparent

reverse

https

 

reverse

tcp_echo

transparent

 

icmp

transparent

 
 
  • Transparent mode
    Sometimes it is necessary to ping the aliased destination through a transparent node. In transparent mode, the monitor is forced to ping through the node with which it is associated (usually a firewall) to the dest node. (In other words, if there are two firewalls in a load balancing pool, the destination node is always pinged through the node specified and not through the node selected by the load balancing method.) In this way, the transparent node is tested--if there is no response, the transparent 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 specify 10.10.10.53:80 as the monitor dest address (a node alias) and add the flag transparent:

    b monitor http_trans '{ use http dest 10.10.10.53:80 transparent }'

    Then you associate the monitor http_trans with the transparent node:

    b node 10.10.10.101:80 monitor use http_trans

    This causes the address 10.10.10 53:80 to be checked through 10.10.10.101:80. (In other words, the check of 10.10.10.53:80 is routed 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 nodes, see Associating monitors with nodes .

  • Reverse mode
    In reverse mode, the monitor marks the 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.

Associating monitors with nodes

Now that you have created a monitor, the third and final task is to associate the monitor with the nodes to be monitored. This creates an instance of the monitor for each node. Associating a monitor with a node can be done either using the Configuration utility or the bigpipe node command.

While the term node association is applied generally with respect to associating monitors with nodes, there are actually three types of associations, based on whether the monitor is associated with an IP address and service, an IP address only, or a service only. These types are node association, node address association, and service association.

  • Node association is the association of a monitor with an IP address and a service.
  • Node address association is the association of a monitor with an IP address only.
  • Service association is the association of a monitor with a service only. For a service association, a wildcard character (*) is used to represent all IP addresses.

    To illustrate, the following is an example of a node association, where the monitor http is being associated with nodes 11.12.11.20:80, 11.12.11.21:80, and 11.12.11.22:80.

    b node 11.12.11.20:80 11.12.11.21:80 11.12.11.22:80 monitor use http

    This creates a monitor instance of http for each of these nodes. You can verify this association using the following command:

    b node monitor show

    The above command produces the output shown in Figure 11.24 .

    Figure 11.24 The output of the b node monitor show command


    +- NODE 11.12.11.20:80 UP
    | |
    | +- http
    | 11.12.11.20:80 up enabled
    |
    +- NODE 11.12.11.21:80 UP
    | |
    | +- http
    | 11.12.11.21:80 up enabled
    |
    +- NODE 11.12.11.22:80 UP
    |
    +- http
    11.12.11.22:80 ip enabled
     

    The actual monitor instance for each node is represented by the output lines highlighted with bold text in Figure 11.24 .

    Other ways to associate monitors with nodes are through wildcard specification, and through logical grouping.


Specifying wildcards

You can also use the wildcard character * to specify node addresses. You can use a wildcard node address association to create instances of the monitor for all node addresses load balanced by the BIG-IP system. For example:

b node * monitor use my_tcp_echo

A wildcard with a service association creates instances of the monitor for every node address configured to service that port:

b node *:80 monitor use my_http:

For detailed procedures on associating monitors with nodes, see Configuration procedures .


Using logical grouping

In the preceding examples, only one monitor has been associated with the nodes. You may associate more than one monitor with a node or nodes by joining them with the Boolean operator and. This creates a rule, and the node is marked as down if the rule evaluates to false, that is, if not all the checks are successful. The most common example is the use of an HTTP monitor and an HTTPS monitor:

b node 11.12.11.20:80 monitor use my_http and my_https

The monitors themselves must be configured with the grouping in mind. For example, if the dest values of both monitors are set to *:*, then both monitor instances try to ping the default port 80. This both defeats the purpose of the HTTPS monitor, and causes a configuration error, since two monitors are trying to ping the same address and port simultaneously.

Instead,you should give monitor my_http a dest value of *:* and give monitor my_https a dest value of *:443. This causes only the my_http monitor instances to default to 80. The my_https monitor instances are forced to the explicit port 443, avoiding a conflict as shown in Figure 11.25 .

Figure 11.25 Use of a monitor rule


MONITOR my_http and https_443
|
+- NODE 11.12.11.20:80 UP
| |
| +- my_http
| | 11.12.11.20:80 up enabled
| |
| +- https_443
11.12.11.20:443 up enabled
 

Configuration procedures

Using the Configuration utility or the bigpipe node command, you can create, show, or delete an association between a monitor and a node, node address, or service.


To associate a monitor using the Configuration utility
  1. In the navigation pane, click Monitors.
    The Monitors screen opens.
  2. Click the tab corresponding to the type of association you want:

    • If you are associating the monitor with a node (the IP address plus the port) click the Node Associations tab.
    • If you are associating the monitor with a node address only (the IP address minus the port), click the Node Address Associations tab.
    • If you are associating the monitor with a service only (that is, the service minus the IP address), click the Service Associations tab.
  3. Regardless of the selection you made in step 2, a dialog box opens. In the Choose Monitor box, type the monitor name or select one from the list.
  4. If you want to associate more than one monitor, click the Move >> button to add the monitor name to the Monitor Rule box.
  5. Repeat the previous two steps for each monitor you want to associate with a node.
  6. Click Apply to associate the monitor(s).
    For additional information associating a monitor, click the Help button.

To associate a monitor from the command line

Use the bigpipe node command to associate a monitor with a node. For example:

b node 10.10.10.53:80 monitor use my_http


To show or delete associations using the Configuration utility
  1. In the navigation pane, click Monitors.
    The Monitors screen opens.
  2. Click the tab corresponding to the type of association you want:

    • If you are showing or deleting a node association (a node is the IP address plus the service) click the Node Associations tab.
    • If you are showing or deleting a node address association (the IP address minus the port), click the Node Address Associations tab.
    • If you are showing or deleting a service association (the service minus the IP address), click the Service Associations tab.
      Regardless of the selection you made in step 2, a dialog box opens showing existing associations.
  3. In the Delete Existing Associations check box, delete associations by checking the box, and then clicking Apply.
Note: For wildcard address associations, the wildcard (*) association itself is shown in addition to each of the individual associations it produces. To delete all these associations, you must delete the wildcard association.
To show associations from the command line

You can display a selected node association or all node associations using the bigpipe node command:

b node <addr:port> monitor show

b node monitor show


To delete associations from the command line

You can delete a selected node association or all node associations using the bigpipe node monitor delete command:

b node <addr:port> monitor delete

In deleting specific monitor associations, it is important to consider how the association was made. If a monitor association was created using a wildcard address, the wildcard must be deleted. For example, if multiple associations were created by typing the command b node *:80 monitor use my_tcp_echo, you must delete the assocations by typing:

b node *:80 monitor delete

If multiple associations were created by typing b node * monitor use my_tcp_echo, you must delete the assocations by typing:

b node * monitor delete

Showing, disabling, and deleting monitors

You can show, disable, and delete monitors using the Configuration utility or from the command line.

  • Deleting a monitor removes the monitor from the /config/bigip.conf file.
  • Disabling a monitor instance simply removes that instance from service until it is re-enabled.
  • Disabling a monitor (which you can do only at the command line) disables all instances of the monitor. All monitor instances are enabled by default.

To show or delete a monitor using the Configuration utility
  1. In the navigation pane, click Monitors.
    A screen opens that lists monitors in two columns, System Supplied and User Defined.
  2. To show a monitor, click the monitor name.
  3. To delete a monitor, click the Delete button for the monitor. Note that only user-defined monitors can be deleted.

To show a monitor from the command line

You can display a selected monitor or all monitors using the bigpipe monitor show command:

b monitor <name> show

b monitor show all


To delete a monitor from the command line

You can delete a selected monitor using the bigpipe monitor delete command:

b monitor <name> delete


To disable a monitor instance using the Configuration utility
  1. In the navigation pane, click Monitors.
    The Monitors screen opens.
  2. Click the appropriate tab for the monitor instances: Basic Associations, Node Associations, or Node Address Associations. The resulting screen shows the existing associations (monitor instances).
  3. Click the node you want to disable.
    The Properties screen for that node opens.
  4. In the Monitor Instances portion of the screen, clear the Enable check box.
  5. Click Apply.
    The monitor instance is now disabled.

To disable a monitor or monitor instance from the command line

To disable a monitor, use the bigpipe monitor <name> disable command:

b monitor <name> disable

This has the effect of disabling all instances of the monitor, as shown in Figure 11.26 .

Figure 11.26 All monitor instances disabled


+- NODE 11.12.11.20:80 UP
| |
| +- http
| 11.12.11.20:80 up disabled
|
+- NODE 11.12.11.21:80 UP
| |
| +- http
| 11.12.11.21:80 up disabled
|
+- NODE 11.12.11.22:80 UP
|
+- http
11.12.11.22:80 ip disabled
 

To disable a monitor instance, use the bigpipe monitor instance <addr:port> disable command:

b monitor instance <addr:port> disable

You can re-enable disabled monitors and instances as follows:

b monitor <name> enable

b monitor instance <addr:port> enable


To delete a monitor with no node associations from the command line

You can delete a monitor if it has no existing node associations and no references in a monitor rule. To delete a monitor, use the bigpipe monitor <name> delete command:

b monitor my_http delete

If the monitor has instances, the instances must first be deleted using the bigpipe node <addr:port> monitor delete command.