Reference: Monitor Management

Monitors are used to assess the availability and performance of devices, links, and services within a network. If a monitored device, link, or service fails to respond within a defined timeout period, or if its performance is degraded or under excessive load, the BIG-IP Next system can automatically redirect traffic to a different resource.

Monitors gather information about your network. The information that the monitors gather is available for you to view. You can use this information to troubleshoot problems and determine what resources in your network are in need of maintenance or reconfiguration.

Default or custom monitors can be used to implement monitors. There are several default monitors that can be connected to the pool:

  • http: A type of health monitor used to check the availability and performance of web services by sending HTTP requests to a specified URL or IP address. This type of monitor is particularly useful for ensuring that web servers and applications are operational and serving content correctly.

  • https: A specialized type of HTTP monitor designed to check the availability, performance, and security of web services that use HTTPS (Hypertext Transfer Protocol Secure). HTTPS uses SSL/TLS encryption to safeguard the confidentiality and accuracy of data transmitted between the client and server.

  • http2: A special type of HTTP monitor that checks the availability and performance of web services that use the HTTP2 protocol. HTTP2 is a more advanced version of the HTTP protocol, offering improved performance through features like multiplexing, header compression, and server push.

  • icmp: A type of health monitor used in network management to check the availability of devices, such as servers or network equipment. It does this by sending ICMP “ping” requests to the target device.

  • inband: A passive monitor that checks and observes live traffic rather than actively probing endpoints. It can mark an endpoint as down based on connection failures but cannot detect when it recovers or when network issues prevent new connections while keeping existing ones intact. Due to these limitations, inband monitors are often used alongside active monitors.

  • tcp: This method uses the three-way handshake process, consisting of SYN (Synchronize), SYN-ACK (Synchronize-Acknowledgment), and ACK (Acknowledgment). It is a type of health monitor used to check if a service is available by connecting to a specific port on a device, such as a server or network service, using the Transmission Control Protocol (TCP). It is commonly used to monitor services like web servers, mail servers, and other TCP-based applications.

  • tcp half-open: A technique that involves starting a TCP connection but not completing the entire handshake to confirm the accessibility of a service. By avoiding a complete connection, this technique assesses a service’s reachability and responsiveness without significantly impacting its performance. It reduces time and possible stress on the monitored service.

  • udp: A type of health monitor used to check the availability and responsiveness of services that use the User Datagram Protocol (UDP). UDP monitoring differs from TCP monitoring as it sends UDP packets to the service and waits for a specific response or behavior. Unlike TCP, UDP does not establish a connection before sending data and does not guarantee packet delivery.

To modify the monitor properties or create a new monitor, click the Edit button at the top right of the panel in the GUI. The default monitors will show various parameters, which are organized into Active and Passive categories.

Active Monitors Parameters:

  • Interval (in seconds): The time of connection attempts before the server marks the pool member as down.

  • Timeout (in seconds): The timeout for a monitor request to the server.

  • (http, https, http2, tcp, udp) Send string and Receive string: Specifies the string value for the monitor to send, and the expected received value. For Receive string, specifically, it is a regular expression representing the text string that the monitor looks for in the response.

  • (http, https, http2, tcp) Receive Disable String: A value used in conjunction with the Receive String value to determine the endpoint state. When configured, this adds a second monitor response match to determine the endpoint state.

  • (http, http2, and https) Username and Password: Values are not provided by default. These are optional fields that are not required.

  • (tcp and http) TCP Profile type: If the advanced option is enabled for http and tcp monitors, two additional parameters can be configured:

    • IP ToS to Client: Specifies the Layer 3 (L3) Type of Service (ToS) level that the system inserts in the TCP packets destined for clients. Enter a number between 0 and 255; this specifies the IP ToS setting that the system inserts in the IP packet header.

    • Indirect Source IP: An Indirect source IP typically refers to the handling of traffic where the source IP address has been altered or is not the direct address of the original sender due to network configurations or a proxy.

  • (udp) UDP Profile type: If the advanced option is enabled for udp monitors, two additional parameters can be configured:

    • IP ToS to Client: Specifies the Layer 3 (L3) Type of Service (ToS) level that the system inserts in the UDP packets destined for clients. Enter a number between 0 and 255; this specifies the IP ToS setting that the system inserts in the IP packet header.

    • Indirect Source IP: An Indirect source IP typically refers to the handling of traffic where the source IP address has been altered or is not the direct address of the original sender due to network configurations or a proxy.

Passive Monitors Parameters:

Note: These parameters are related to inband monitors.

  • Failures: The number of failures (TCP RSTs or delayed responses) in a Failure Interval that trigger a down state.

  • Failure Interval (in seconds): The period in which the allowed number of failures must occur to trigger a down state.

  • Response Time (in seconds): The period in which the endpoint must respond to a packet from the BIG-IP system before the packet is delayed and considered a failure.

  • Retry Time (in seconds): The time before a reconnection attempt is sent to the endpoint for load balancing when the endpoint is in a down state.