F5 BIG-IP Virtual Server and Health Monitor Setup

A BIG-IP virtual server is only as good as the health checking behind it. If the monitor is wrong, the load balancer keeps sending users to a dead web server, or removes every member from the pool and returns connection errors for a service that is actually healthy. The correct build order is always monitor first, then pool, then virtual server: the monitor defines what "healthy" means, the pool holds the members that pass it, and the virtual server publishes the service. This guide walks that sequence in both the GUI and TMSH, then covers the verification commands that tell you why a member is marked down.

Monitors: Pre-Built versus Custom

F5 ships pre-configured monitors for every common protocol — HTTP, HTTPS, TCP, UDP, ICMP and more. A custom monitor is the right choice when the default check is not a real health signal: a TCP connect against a port can succeed while the application is returning errors, and an HTTP monitor that only checks for 200 OK will miss a page that renders an error inside a successful response.

Create a custom monitor when you need one of these:

• A specific URI that exercises the application, not just the web server.
• A receive string that must appear in the response, which turns the check into a functional test.
• Tighter intervals and timeouts than the defaults, so failures are detected before users notice.

Step 1 - Create the Custom Monitor

In the GUI: Local Traffic > Monitors > Create, then choose the monitor type. Set Configuration to Advanced to expose interval, timeout, send, and receive strings. In TMSH the same object is created directly, which is far easier to version-control:

create ltm monitor http /Common/mon_webapp {
    defaults-from /Common/http
    interval 5
    timeout 16
    send "GET /healthz HTTP/1.1\r\nHost: app.example.com\r\nConnection: close\r\n\r\n"
    recv "STATUS: OK"
    destination *:*
}

Interval and timeout arithmetic

Interval 5 with timeout 16 means a member is marked down after three consecutive failed probes — roughly 15 seconds of failure, fast enough for most production services. Do not set the timeout lower than the interval; the monitor will time out on healthy members under any latency spike.

Step 2 - Build the Pool and Attach the Monitor

A pool must exist before a default pool can be referenced from a virtual server, and the health monitor is attached at pool level so that all members share the same definition of health:

create ltm pool /Common/pool_webapp {
    load-balancing-mode least-connections-member
    monitor /Common/mon_webapp
    members {
        /Common/10.10.30.11:8080 { address 10.10.30.11 }
        /Common/10.10.30.12:8080 { address 10.10.30.12 }
    }
}

In the GUI this is Local Traffic > Pools > Create, then in the Health Monitors area move the monitor from Available into Selected. Note that health monitors come in two flavours: a health monitor checks whether the member is up, and a performance monitor additionally checks whether it is degraded, which is what lets BIG-IP drain a slow member before it fails outright.

Step 3 - Publish the Virtual Server

The virtual server binds a destination address and port to a default pool. The address must be routable on the network and cannot be a loopback address:

create ltm virtual /Common/vs_webapp {
    destination 203.0.113.100:443
    ip-protocol tcp
    profiles {
        /Common/tcp { }
        /Common/http { }
        /Common/clientssl { context clientside }
    }
    source-address-translation { type automap }
    pool /Common/pool_webapp
    persist { /Common/cookie { } }
}

Source address translation and persistence

Two settings deserve attention. source-address-translation automap makes BIG-IP use a self IP as the source toward the pool members, so back-end servers must route return traffic to the BIG-IP, not to the client. And a persistence profile is required whenever the application keeps per-user state — without it, least-connections distribution will break sticky sessions.

Step 4 - Verify Member Health and Traffic

In the GUI, the pool member list shows a green, red, or blue circle per member and, crucially, the monitor status text beneath it. The equivalent TMSH commands are what you want during an incident:

tmsh show ltm pool /Common/pool_webapp members
tmsh show ltm monitor /Common/mon_webapp
tmsh show ltm virtual /Common/vs_webapp
tmsh show ltm pool /Common/pool_webapp detail
tmsh show sys connection cs-server-addr 10.10.30.11
tmsh show ltm node /Common/10.10.30.11

A member shown as down with the reason Monitor /Common/mon_webapp has been marked as down means the probe failed. Work outward: does the application answer that exact URI on that exact port from a host outside the BIG-IP, and does the receive string match byte for byte? Case and whitespace both matter. If the member is down because of address rather than monitor, the node is administratively disabled or unreachable at Layer 3.

Operational Notes

• Be careful with reserved keywords when naming custom monitors; some strings cannot be used as monitor values.
• Always set the monitor on the pool, not per member, unless a specific server genuinely needs different semantics.
• Check that a newly published virtual server is actually receiving traffic with tmsh show ltm virtual — a zero connection count usually means routing or firewall, not the pool.
• Keep monitor intervals and timeouts consistent across the estate; a one-second probe against a shared back end creates measurable load on its own.

Related reading: our nginx stream module TCP/UDP load balancing guide, the keepalived VRRP and HAProxy failover article, and the port-channel hash algorithm tuning guide.

原文链接：https://techdocs.f5.com/en-us/bigip-17-0-0/big-ip-local-traffic-manager-implementations/implementing-health-and-performance-monitoring.html