04 Health Monitors

A health monitor periodically checks a pool member or node and marks it up or down. BIG-IP only sends traffic to members that are up, so monitors are what turn a list of servers into a resilient application. This note covers where monitors apply, the monitor types, timers, and the settings used in real deployments.

Where monitors apply

• Pool — every member inherits the pool’s monitor (most common).
• Pool member — overrides the pool monitor for one member.
• Node — checks the server IP regardless of service (usually ICMP).

Node monitors affect every pool

If the monitor on a node fails, every member using that node goes down in every pool. A pool/member monitor only affects that service.

Mixed monitors

ICMP monitor on 5 nodes + HTTP monitor on the pool. The ICMP check fails on one server → that member shows Offline, the other four stay Available.

Status icons

Icon	Status	Meaning
🟢 green circle	Available	Monitor passes
🟡 yellow triangle	Unavailable	Temporarily can’t take traffic (e.g. connection limit)
🔴 red diamond	Offline	Monitor failed, or the parent node is down
🟦 blue square	Unknown	No monitor assigned — BIG-IP assumes it’s up
⚫ black/grey	Disabled	Disabled by an administrator

The Network Map (Local Traffic → Network Map) shows virtual servers, pools and members with these icons in a single view.

Monitor types

Type	Checks	Notes
ICMP / gateway_icmp	Host answers ping	Says nothing about the service
TCP	The port accepts a connection (optionally send/receive strings)	L4
TCP half-open	SYN → SYN-ACK only	Lightweight; no full connection
HTTP / HTTPS	Sends a request and checks the response	Supports Send and Receive strings
UDP, DNS, LDAP, RADIUS, SQL, SMTP, FTP…	Protocol-specific checks
External	Custom script	Most flexible

ICMP doesn't prove an application works

A server can answer ping while its web service is dead. Use a monitor at the level of the service you publish.

Content monitors

An HTTP monitor with a Send String and a Receive String proves that the application — and often its database — actually works:

• Send: GET /health HTTP/1.1\r\nHost: app1.f5lab.int\r\nConnection: close\r\n\r\n
• Receive: OK (text that must appear in the response)

Custom monitors

Don’t edit the built-in system monitors. Create a custom monitor using the built-in one as parent and change only what you need.

Timers

• Interval — how often the check runs.
• Timeout — how long without a valid answer before marking the member down.
• Rule of thumb: Timeout = (3 × Interval) + 1 → default HTTP monitor: 5 s / 16 s.
• Monitors are executed by the bigd daemon (control plane). Very short intervals across many members add load to BIG-IP and to the servers.

Advanced monitor settings

Setting	What it does
Receive Disable String	If found, the member goes to disabled (drains gracefully) instead of down — lets app teams take a server out for maintenance
Reverse	Mark down when the receive string is found (e.g. “ERROR”)
Time Until Up	Must pass checks for X seconds before being marked up (avoids flapping)
Up Interval	Different check interval while the member is up
Manual Resume	After going down, it stays down until an admin enables it
Alias Address / Alias Service Port	Check a different IP/port than the member’s
Transparent	Check through a device (firewall/cache) to a destination

Avoid unnecessary monitoring

• Checking the same thing twice (ICMP on the node + TCP on the member + HTTP on the member) wastes bigd resources and generates extra traffic to the servers.
• Keep the most meaningful monitor — usually the application-level one on the pool.
• Very aggressive intervals across hundreds of members load both BIG-IP and the servers.

Monitoring two services on one member

To mark a member up only if HTTP on 80 and a service on TCP 8080 both work:

1. Assign the HTTP monitor.
2. Add a TCP monitor with alias port 8080.
3. Set the pool’s Availability Requirement = All.

Common mistake

If the requirement is set to At Least 1, the member stays up when only one of the two monitors passes. With All (the usual default when you add several monitors) every monitor must pass.

Testing a service by hand

From the BIG-IP bash prompt (or any Linux host):

• curl — HTTP/HTTPS (curl -v http://10.10.101.101/health).
• telnet — TCP port open?
• netcat (nc) — TCP and UDP (nc -vzu for UDP).

Self-check

Q1 — Are ICMP monitors good for checking that an HTTPS service is running?

Respuesta

No. ICMP only proves the host answers ping.

Q2 — Is it common practice to edit the default system monitors?

Respuesta

No. Create custom monitors with the default as parent.

Q3 — Do members inherit the monitor configured on their pool?

Respuesta

Yes.

Q4 — Monitors can be assigned to which three objects?

Respuesta

Pools, pool members and nodes.

Q5 — You take a node offline for maintenance and get an alert that a pool member went offline. Why?

Respuesta

The node is the parent of the member; disabling it takes down every member linked to it.

Q6 — HTTP + TCP 5555 monitors are assigned, but the member stays up when 5555 fails. Why?

Respuesta

The pool’s Availability Requirement isn’t set to All.

Q7 — Which tool tests whether a UDP service answers?

Respuesta

netcat (nc).

Q8 — With a 5-second interval, what timeout follows the rule of thumb?

Respuesta

16 seconds (3 × 5 + 1).