Applies To:

Show Versions Show Versions

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

12 
The BIG-IP® local traffic management system can monitor the health or performance of either pool members or nodes. The local traffic management system supports these methods of monitoring:
Simple monitoring
Simple monitoring merely determines whether the status of a node is up or down. Simple monitors do not monitor pool members (and therefore, individual protocols, services, or applications on a node), but only the node itself. The system contains two types of simple monitors, ICMP and TCP_ECHO.
Active monitoring
Active monitoring checks the status of a pool member or node on an ongoing basis, at a set interval. If a pool member or node being checked does not respond within a specified timeout period, or the status of a pool member or node indicates that performance is degraded, the BIG-IP system can redirect the traffic to another pool member or node. There are many types of active monitors. Each type of active monitor checks the status of a particular protocol, service, or application. For example, one type of monitor is HTTP. An HTTP type of monitor allows you to monitor the availability of the HTTP service on a pool, pool member, or node. A WMI type of monitor allows you to monitor the performance of a pool, pool member, or node that is running the Windows Management Instrumentation (WMI) software. Active monitors fall into two categories: Extended Content Verification (ECV) monitors and Extended Application Verification (EAV) monitors.
Passive monitoring
Passive monitoring occurs as part of a client request. This kind of monitoring checks the health of a pool member based on a specified number of connection attempts or data request attempts that occur within a specified time period. If, after the specified number of attempts within the defined interval, the system cannot either connect to the server or receive a response, or if the system receives a bad response, the system marks the pool member as down. There is only one type of passive monitor, called an Inband monitor.
To assist you in deciding which monitoring method to use, Table 12.1, shows the benefits and constraints of each monitoring method.
Works well when you only need to determine the up or down status of a node.
Creates additional network traffic beyond the client request and server response
Creates no additional network traffic beyond the client request and server response
Can mark a pool member as down quickly, as long as there is some amount of network traffic
The local traffic management system includes a wide variety of monitors. You can choose which types of monitors you want to associate with a given pool, pool member, or node.
Table 12.2 lists and describes all monitor types available with the BIG-IP system.
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.
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.
Verifies the File Transfer Protocol (FTP) service by attempting to download a specific file to the /var/tmp directory on an BIG-IP system. Once downloaded successfully, the file is not saved.
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.
Enables Global Traffic Manager and Local Traffic Manager systems to load balance in a proportional manner to Local Traffic Manager virtual servers associated with the Web Accelerator and Application Security Manager modules.
Verifies Microsoft® Windows® SQL-based services. Before using this type of monitor, you must install a set of Microsoft® JDBC JavaTM Archive (JAR) files. For information on installing these files, see Appendix B, Additional Monitor Considerations.
Verifies services based on Oracle® by attempting to perform an Oracle login to a service.
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.
Checks the current CPU, memory, and disk usage of a pool, pool member, or node that is running an SNMP data collection agent, and then dynamically load balances traffic accordingly.
Checks the current user usage of a pool, pool member, or node that is running an SNMP data collection agent, and then dynamically load balances traffic accordingly. The way that you configure the monitor settings determines the data that the BIG-IP system collects.
Checks the performance of a pool, pool member, or node that is running the Windows Management Infrastructure (WMI) data collection agent and then dynamically load balances traffic accordingly.
Every monitor consists of settings with values. The settings and their values differ depending on the type of monitor. In some cases, the BIG-IP system assigns default values. For example, Figure 12.1 shows that an ICMP-type monitor has these settings and default values.
Name my_icmp
Type ICMP
Transparent No
Alias Address * All Addresses
The settings in Figure 12.1 specify that an ICMP type of 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 Alias Address setting, with the value * All Addresses. Thus, in the preceding example, all IP addresses with which the monitor is associated are checked. For more information on monitor settings, see Special configuration considerations.
You implement monitors using either the Configuration utility or a command line utility. The task of implementing a monitor varies depending on whether you are using a pre-configured monitor or creating a custom monitor. A pre-configured monitor is an existing monitor that the BIG-IP system provides for you, with its settings already configured. A custom monitor is a monitor that you create based on one of the allowed monitor types.
If you want to implement a pre-configured monitor, you need only associate the monitor with a pool, pool member, or node, and then configure the virtual server to reference the relevant pool. If you want to implement a custom monitor, you must first create the custom monitor. Then you can associate the custom monitor with a pool, pool member, or node, and configure the virtual server to reference the pool.
For the procedure on creating a custom monitor, see Creating a custom monitor. For the procedure on associating a monitor with a pool or pool member, or with a node, see Associating monitors with pools and nodes.
For a subset of monitor types, the BIG-IP system includes a set of pre-configured monitors. You cannot modify pre-configured monitor settings, as they are intended to be used as is. The purpose of a pre-configured monitor is to eliminate the need for you to explicitly create a monitor. You use a pre-configured monitor when the values of the settings meet your needs as is.
An example of a pre-configured monitor is the icmp monitor. Figure 12.2 shows the icmp monitor, with values configured for its Interval, Timeout, and Alias Address settings. Note that the Interval value is 5, the Timeout value is 16, the Transparent value is No, and the Alias Address value is * All Addresses.
Figure 12.2 The icmp pre-configured monitor
Name icmp
Type ICMP
Interval 5
Transparent No
Alias Address * All Addresses
If the Interval, Timeout, Transparent, and Alias Address values meet your needs, you simply assign the icmp pre-configured monitor directly to a pool, pool member, or node, using the Pools or Nodes screens within the Configuration utility. In this case, you do not need to use the Monitors screens, unless you simply want to view the values of the pre-configured monitor settings.
Important: All pre-configured monitors reside in partition Common. For information on partitions, see the TMOSTM Management Guide for BIG-IP® Systems.
You create a custom monitor when the values defined in a pre-configured monitor do not meet your needs, or no pre-configured monitor exists for the type of monitor you are creating. (For information on monitor types, see Summary of monitor types.)
If a pre-configured monitor exists that corresponds to the type of custom monitor you are creating, you can import the settings and values of that pre-configured monitor into the custom monitor. You are then free to change those setting values to suit your needs. For example, if you create a custom monitor called my_icmp, the monitor can inherit the settings and values of the pre-configured monitor icmp. This ability to import existing setting values is useful when you want to retain some setting values for your new monitor but modify others.
Figure 12.3, shows an example of a custom ICMP-type monitor called my_icmp, which is based on the pre-configured monitor icmp.
Note that the Interval value has been changed to 10, and the Timeout value to 20. The other settings retain the values defined in the pre-configured monitor.
Name my_icmp
Type ICMP
Alias Address * All Addresses
You can import settings from another custom monitor instead of from a pre-configured monitor. This is useful when you would rather use the setting values defined in another custom monitor, or when no pre-configured monitor exists for the type of monitor you are creating. For example, if you create a custom monitor called my_oracle_server2, you can import settings from an existing Oracle-type monitor such as my_oracle_server1. In this case, because the BIG-IP system does not provide a pre-configured Oracle-type monitor, a custom monitor is the only kind of monitor from which you can import setting values.
Selecting a monitor is straightforward. Like icmp, each of the monitors has a Type setting based on the type of service it checks, for example, http, https, ftp, pop3, and takes that type as its name. (Exceptions are port-specific monitors, like the external monitor, which calls a user-supplied program.)
When you create a custom monitor, you use the Configuration utility or a command line utility to: give the monitor a unique name, specify a monitor type, and, if a monitor of that type already exists, import settings and their values from the existing monitor. You can then change the values of any imported settings.
You must base each custom monitor on a monitor type. When you create a monitor, the Configuration utility displays a list of monitor types. To specify a monitor type, simply choose the one that corresponds to the service you want to check. For example, if you want to want to create a monitor that checks the health of the HTTP service on a pool, you choose HTTP as the monitor type.
If you want to check more than one service on a pool or pool member (for example HTTP and HTTPS), you can associate more than one monitor on that pool or pool member. For more information, see Chapter 4, Configuring Load Balancing Pools.
Checking services is not the only reason for implementing a monitor. If you want to verify only that the destination IP address is alive, or that the path to it through a transparent node is alive, use one of the simple monitors, icmp or tcp_echo. Or, if you want to verify TCP only, use the monitor tcp.
Important: When you create a custom monitor, the BIG-IP system places the monitor into your current administrative partition. For more information on administrative partitions, see the TMOSTM Management Guide for BIG-IP® Systems.
1.
On the Main tab of the navigation pane, expand Local Traffic, and click Monitors.
The Monitors screen opens.
2.
In the upper right corner of the screen, click Create.
The New Monitor screen opens.
Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a custom monitor.
3.
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.
If Import Settings appears, choose a monitor name from the list.
If a monitor of the type you selected does not exist, in the Name box, type a unique name for the custom monitor.
5.
In the Configuration section of the screen, select Advanced. This allows you to modify additional default settings.
7.
Click Finished.
Important: When defining values for custom monitors, make sure you avoid using any values that are on the list of reserved keywords. For more information, see solution number 3653 (for 9.0+ systems) on the AskF5sm technical support web site.
Every pre-configured or custom monitor has settings with some default values assigned. You will find certain topics useful when changing these default values:
Setting destinations
For more information, see Setting destinations, following.
By default, the value for the Alias Address setting in the monitors is set to the wildcard * Addresses, and the Alias Service Port setting is set to the wildcard * Ports. This value causes the monitor instance created for a pool, pool member, or node to take that nodes address or address and port as its destination. You can, however, replace either or both wildcard symbols with an explicit destination value, by creating a custom monitor. An explicit value for the Alias Address and/or Alias Service Port setting is used to force the instance destination to a specific address and/or port which may not be that of the pool, pool member, or node.
The ECV monitors http, https, and tcp have the settings Send String and Receive String for the send string and receive expression, respectively.
The most common Send String value is GET /, which retrieves a default HTML page for a web site. To retrieve a specific page from a web site, you can enter a Send String value that is a fully qualified path name:
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 and FTP monitors, you can use the special settings get or hurl in place of Send String and Receive String statements. For FTP monitors specifically, the GET setting specifies the full path to the file to retrieve.
The normal and default behavior for a monitor is to ping the destination pool, pool member, or node by an unspecified route, and to mark the node up if the test is successful. However, with certain monitor types, you can specify a route through which the monitor pings the destination server. You configure this by specifying the Transparent or Reverse setting within a custom monitor.
Important: You cannot use a monitor that includes the Transparent feature if you are using the IPv6 addressing or the route domains features.
Transparent setting
Sometimes it is necessary to ping the aliased destination through a transparent pool, pool member, or node. When you create a custom monitor and set the Transparent setting to Yes, the BIG-IP system forces the monitor to ping through the pool, pool member, or node with which it is associated (usually a firewall) to the pool, pool member, or node. (That is, if there are two firewalls in a load balancing pool, the destination pool, pool member, or node is always pinged through the pool, pool member, or node specified; not through the pool, pool member, or node selected by the load balancing method.) In this way, the transparent pool, pool member, or node is tested: if there is no response, the transparent pool, pool member, or node is marked as down.
Common examples are checking a router, or checking a mail or FTP server through a firewall. For example, you might want to check the router address 10.10.10.53:80 through a transparent firewall 10.10.10.101:80. To do this, you create a monitor called http_trans in which you specify 10.10.10.53:80 as the monitor destination address, and set the Transparent setting to Yes. Then you associate the monitor http_trans with the transparent pool, pool member, or node.
This causes the monitor to check the address 10.10.10 53:80 through 10.10.10.101:80. (In other words, the BIG-IP system routes the check of 10.10.10.53:80 through 10.10.10.101:80.) If the correct response is not received from 10.10.10.53:80, then 10.10.10.101:80 is marked down. For more information on associating monitors with pool members or nodes, see Associating monitors with pools and nodes.
Reverse setting
With the Reverse setting set to Yes, the monitor marks the pool, pool member, or node down when the test is successful. For example, if the content on your web site home page is dynamic and changes frequently, you may want to set up a reverse ECV service check that looks for the string "Error". A match for this string means that the web server was down.
Figure 12.3 shows the monitors that contain the Transparent setting, the Reverse setting, or both.
Table 12.3 Monitors that contain the Transparent or Reverse settings
By default, when a monitor detects that a resource (that is, a node or a pool member) is unavailable, the BIG-IP system marks the resource as down and routes traffic to the next appropriate resource as dictated by the active load balancing method. When the monitor next determines that the resource is available again, the BIG-IP system marks the resource as up and immediately considers the resource to be available for load balancing connection requests. While this process is appropriate for most resources, there are situations where you want to manually designate a resource as available, rather than allow the BIG-IP system to do that automatically. You can manually designate a resource as available by configuring the Manual Resume setting of the monitor.
For example, consider a monitor that you assigned to a resource to track the availability of an HTML file, index.html, for a web site. During the course of a business day, you decide that you need to restart the system that hosts the web site. The monitor detects the restart action and informs the BIG-IP system that the resource is now unavailable. When the system restarts, the monitor detects that the index.html file is available, and begins sending connection requests to the web site. However, the rest of the web site might not be ready to receive connection requests. Consequently, the BIG-IP system sends connection requests to the web site before the site can respond effectively.
To prevent this problem, you can configure the Manual Resume setting of the monitor. When you set the Manual Resume setting to Yes, you ensure that the BIG-IP system considers the resource to be unavailable until you manually enable that resource.
To summarize, if you set the Manual Resume setting of a monitor to Yes and then associate the monitor with a resource, and the resource subsequently becomes unavailable, the resource remains offline until you manually re-enable it.
You can configure the Manual Resume setting when you create a custom monitor or you can modify the Manual Resume setting of an existing custom monitor. For information on creating a custom monitor, see Creating a custom monitor. For information on modifying the Manual Resume setting of an existing customer monitor, see the following procedure.
1.
On the Main tab of the navigation pane, expand Local Traffic and then click Monitors.
The main monitors screen opens.
2.
Click the name of the appropriate monitor.
The properties screen for the monitor opens.
3.
From the Configuration list, select Advanced.
4.
For the Manual Resume option, click Yes.
5.
Click Update.
If you have a resource (such as a pool member or node) that a monitor marked as down, and the resource has subsequently become available again, you must manually re-enable that resource if the monitors Manual Resume setting is set to Yes. Manually re-enabling the resource allows the BIG-IP system to resume sending connections to that resource.
The procedure for manually re-enabling a resource varies depending on whether the resource is a pool, a pool member, or a node. For more information, see Chapter 3, Configuring Nodes, and Chapter 4, Configuring Load Balancing Pools.
When you implement both active and passive monitoring on a pool member, you can enable the Check Until Up setting on an active monitor. Enabling the Check Until Up setting when you have configured active and passive monitoring causes the active monitor to check the health of the pool member only until the pool member is determined to be up. Once the pool member is determined to be up, the BIG-IP system disables active health checks for the pool member, leaving it to the Inband monitor to discover a down pool member.
Table 12.4 shows the difference between enabling and disabling the Check Until Up feature on an active monitor when passive monitoring is configured.
Table 12.4 Effect of Check Until Up setting on active monitor when passive monitoring is configured
The active monitor refrains from checking the health of the pool member until the Inband monitor marks the pool member as down.
The active monitor checks the health of the pool member until it reports the pool member as up. Then the Inband monitor is used to monitor the pool member.
Important: When using this setting in conjunction with an Inband monitor, you must set the Inband monitor Retry Time setting to 0.
Once you have created a monitor and configured its settings, the final task is to associate the monitor with the server or servers to be monitored. The server or servers can be either a pool, a pool member, or a node, depending on the monitor type.
Monitor-to-pool association
This type of association associates a monitor with an entire load balancing pool. In this case, the monitor checks all members of the pool. For example, you can create an instance of the monitor http for every member of the pool my_pool, thus ensuring that all members of that pool are checked.
Monitor-to-pool member association
This type of association associates a monitor with an individual pool member, that is, an IP address and service. In this case, the monitor checks only that pool member and not any other members of the pool. For example, you can create an instance of the monitor http for pool member 10.10.10.10:80 of my_pool.
Monitor-to-node association
This type of association associates a monitor with a specific node. In this case, the monitor checks only the node itself, and not any services running on that node. For example, you can create an instance of the monitor icmp for node 10.10.10.10. In this case, the monitor checks the specific node only, and not any services running on that node.
You can designate a monitor as the default monitor that you want the BIG-IP system to associate with one or more nodes. In this case, any node to which you have not specifically assigned a monitor inherits the default monitor.
Some monitor types are designed for association with nodes only, and not pools or pool members. Other monitor types are intended for association with pools and pool members only, and not nodes. Node-only monitors specify a destination address in the format of an IP address only, with no service port (for example, 10.10.10.2). Conversely, monitors that you can associate with nodes, pools, and pool members specify a destination address in the format of an IP address and service port (for example, 10.10.10.2:80). Therefore, when you use the Configuration utility to associate a monitor with a pool, pool member, or node, the utility displays only those pre-configured monitors that are designed for association with that server. For example, you cannot associate the monitor icmp with a pool or its members, since the icmp monitor is designed to check the status of a node itself and not any service running on that node.
When you associate a monitor with a server, the BIG-IP system automatically creates an instance of that monitor for that server. A monitor association thus creates an instance of a monitor for each server that you specify. Therefore, you can have multiple instances of the same monitor running on your servers.
The Configuration utility allows you to disable an instance of a monitor that is running on a server. This allows you to suspend health or performance checking, without having to actually remove the monitor association. When you are ready to begin monitoring that server again, you simply re-enable that instance of the monitor.
For more information on associating monitors with pools and pool members, see Chapter 4, Configuring Load Balancing Pools. For more information on associating monitors with nodes, see Chapter 3, Configuring Nodes.
When managing existing monitors, you can display or delete them, or you can enable and disable an instance of a monitor. Prior to deleting a monitor, you must remove all existing monitor associations.
Note: You can manage only those monitors that you have permission to manage, based on your user role and partition access assignment.
1.
On the Main tab of the navigation pane, expand Local Traffic, and click Monitors.
The Monitors screen opens.
2.
Click a monitor name.
This displays the monitor settings and their values.
1.
On the Main tab of the navigation pane, expand Local Traffic, and click Monitors.
The Monitors screen opens.
3.
Click Delete.
A confirmation message appears.
4.
Click Delete.
1.
On the Main tab of the navigation pane, expand Local Traffic, and click Monitors.
The Monitors screen opens.
3.
On the menu bar, click Instances.
This lists any existing monitor instances.
5.
Click Enable or Disable.
Note: Because instances of monitors are not partitioned objects, a user can enable or disable an instance of a monitor without having permission to manage the associated pool or pool member. For example, a user with the Manager role, who can access partition AppA only, can enable or disable monitor instances for a pool that resides in partition Common. However, that user cannot perform operations on the pool or pool members that are associated with the monitor. Although this is correct functionality, the user might not expect this behavior. You can prevent this unexpected behavior by ensuring that all pools and pool members associated with monitor instances reside in the same partition.
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)