上篇我们完成了 Pool / VS / Profile 三板斧，一个 VIP 从创建到上线的全流程已经能跑了。
但这套流程中有一个贯穿始终的关键角色------Monitor（健康检查）。它决定了后端 Member 是活着工作还是被踢出。不懂 Monitor，你建的 VIP 可能跑着跑着就挂了而不自知。
一、Monitor 的核心模型
Monitor 的本质就一句话：F5 定期发探测包给后端 Member，根据响应决定它是 up 还是 down。
一条公式决定所有参数
timeout = interval × 3 + 1这是 F5 的硬性规则，配 Monitor 时永远记住它：
| 你想要的探测节奏 | interval | timeout |
|---|---|---|
| 每 5 秒探一次（高可用） | 5 | 16 |
| 每 10 秒探一次（通用） | 10 | 31 |
| 每 30 秒探一次（慢检测） | 30 | 91 |
为什么 timeout 必须大于 interval？
interval 是两次探测的间隔 ，timeout 是单次探测的最长等待时间。如果 timeout < interval，意味着"我等得比下次探测时间还短"，逻辑不自洽，F5 会直接报错。
Monitor 的生命周期
创建 Monitor → 关联 Pool → 开始探测 Pool 中的每个 Member
│
┌─────────┼─────────┐
▼ ▼ ▼
Member A Member B Member C
┌───────┐ ┌───────┐ ┌───────┐
│探测请求│ │探测请求│ │探测请求│
│ ─────→│ │ ─────→│ │ ─────→│
│ ←──── │ │ ↑ timeout │ │ ↑ timeout │
│ 200OK │ │ 无响应 │ │ 无响应 │
└───────┘ └───────┘ └───────┘
up down down-
探测成功 → 绿色
up，参与负载均衡 -
探测超时 → 红色
down，踢出负载均衡 -
再探测成功 → 恢复绿色
up，重新加入
二、五种 Monitor 选型和配置
① TCP Monitor------最轻量、最快
tmsh create ltm monitor tcp my-tcp-monitor \
interval 5 \
timeout 16 \
time-until-up 0原理： F5 发 SYN → 后端回 SYN-ACK → 建连成功 → 标记 up。不发任何应用层数据，纯三次握手。
适用场景：
-
TCP 透传（MySQL、Redis、SSH）
-
只关心端口是否在监听，不关心业务层
-
需要高频探测（interval 可设 3-5 秒，开销极低）
优点： 开销最小，不占用后端 CPU 缺点： 端口活着不代表业务正常（比如进程死锁但端口还在）
② HTTP Monitor------最常用、最推荐
tmsh create ltm monitor http my-http-monitor \
interval 10 \
timeout 31 \
time-until-up 0 \
send "GET /health HTTP/1.1\r\nHost: myapp.example.com\r\nConnection: close\r\n\r\n" \
recv "200 OK"原理： F5 建立 TCP 连接 → 发送 HTTP 请求 → 检查响应是否包含 recv 字符串。
核心参数详解：
| 参数 | 作用 | 示例 | 新手常见错误 |
|---|---|---|---|
send |
F5 发给后端的 HTTP 请求内容 | GET /health ... |
忘了写 \r\n，请求格式不对 |
recv |
响应必须包含的字符串 | 200 OK |
检测后端返回 {"status":"up"} 没有 200 |
recv disable |
如果响应包含此字符串 → 标记 down | "error" |
后端返回 "no error occurred"，反而被踢 |
send 字符串的格式------容易出错的地方：
# 标准格式（必须带 \r\n）
send "GET /health HTTP/1.1\r\nHost: 你的域名\r\nConnection: close\r\n\r\n"
# 注意点：
# 1. \r\n 是 HTTP 协议要求的换行符，不是普通 \n
# 2. Connection: close 让后端响应后主动关闭连接，避免连接泄漏
# 3. 最后两个 \r\n\r\n 表示请求头结束
# 4. Host 头一定要写，有些后端根据 Host 做虚拟主机路由③ HTTPS Monitor------和 HTTP 几乎一样
tmsh create ltm monitor https my-https-monitor \
interval 10 \
timeout 31 \
time-until-up 0 \
send "GET /health HTTP/1.1\r\nHost: myapp.example.com\r\nConnection: close\r\n\r\n" \
recv "200 OK"和 HTTP Monitor 的区别： F5 先建 TCP → TLS 握手（F5 自己会做，不需要你额外配证书）→ 再发 HTTP 请求。
④ TCP Echo Monitor
tmsh create ltm monitor tcp-echo my-echo-monitor \
interval 5 \
timeout 16原理： F5 发送一串数据 → 后端原样返回 → 对比是否一致 → 一致则 up。不需要后端暴露 HTTP 接口。 适用场景： 需要确认后端不仅能连，还能正常收发数据的自定义 TCP 协议服务。
⑤ Gateway ICMP Monitor
tmsh create ltm monitor gateway-icmp my-ping-monitor \
interval 10 \
timeout 31原理： F5 直接 ping Node IP，能通就算 up。 适用场景： Node 层面做连通性检测，但几乎不单独用，通常配合其他 Monitor 使用。
三、Monitor 选择和配置决策树
你的后端是什么？
│
├── TCP 协议服务（MySQL/Redis/SSH/自定义 TCP）
│ └── TCP Monitor（interval 5s，纯端口检测）
│
├── HTTP 服务
│ ├── 后端是 HTTP（明文） → HTTP Monitor
│ └── 后端是 HTTPS → HTTPS Monitor
│
├── HTTP 服务 + 需要检查健康页面
│ └── HTTP/HTTPS Monitor，send GET /health
│
└── 需要确认"能收发数据"
└── TCP Echo Monitorinterval 配置策略
| 场景 | interval 推荐 | 理由 |
|---|---|---|
| 高可用要求严格的业务 | 5s | 后端挂了 5 秒内踢掉 |
| 普通 Web 业务 | 10s | 兼顾检测速度和后端压力 |
| 非关键业务 | 30s | 减少不必要的探测 |
| 后端压力敏感的 | 20~30s | 防止频繁探测拖垮后端 |
经验之谈：
不要把 interval 设到 1-2 秒。Member 一多，F5 和后端都会被探测包淹没。
time-until-up设 5-10 秒。后端刚重启完，进程起来了但业务还没就绪，不加延迟会"先绿后红"来回抖动。一定要用
/health或/status这种轻量端点，不要用首页（包含数据库查询，开销大）。
四、Member 状态全解
颜色含义
| 颜色 | 状态 | 说明 |
|---|---|---|
| 🟢 绿色 | up（available） | Monitor 探测通过，正常接收流量 |
| 🔴 红色 | down（unavailable） | Monitor 探测失败，流量绕过 |
| ⚪ 灰色 | unchecked | 没配 Monitor，默认可用 |
| 🟡 黄色 | disabled | 管理员手动禁用，不接新连接 |
| 🔵 蓝色 | forced online | 强制上线，绕过 Monitor（慎用） |
状态转换路径
创建 Member → unknown（初始）
│
├── 没配 Monitor → unchecked（默认可用）
│
└── 配了 Monitor → 开始探测
│
├── 成功 → green up → 接收流量
│ │
│ ├── 超时 → red down → 踢出
│ │ │
│ │ └── 再成功 → green up
│ │
│ └── 手动禁用 → yellow disabled
│
└── 失败 → red down → 不接收流量
│
└── 再成功 → green up常用操作命令
# 查看 Monitor 配置
tmsh list ltm monitor http myapp-monitor
# 查看 Member 状态（最常用）
tmsh show ltm pool myapp-pool members
# 禁用 Member（优雅下线，等现有连接完成）
tmsh modify ltm pool myapp-pool members modify { 10.0.0.10:80 { session user-disabled } }
# 强制下线 Member（立即踢出）
tmsh modify ltm pool myapp-pool members modify { 10.0.0.10:80 { state user-down } }
# 恢复 Member
tmsh modify ltm pool myapp-pool members modify { 10.0.0.10:80 { session user-enabled } }
# 实时查看检测日志
tmsh tail -f /var/log/ltm | grep -i "monitor\|pool_name"五、常见问题排查
Q：Member 一直红色 down，但后端明明是活的？
排查步骤：
1. tmsh show ltm monitor http my-monitor ← 看 Monitor 配置
2. 检查 send 字符串的 Host 头对不对 ← 虚拟主机依赖 Host
3. 检查 recv 字符串是否真的在响应里 ← curl 手动验证
4. 检查 interval 和 timeout 是否满足 3×+1 公式 ← 不满足直接报错
5. 检查后端防火墙有没有放行 F5 的源 IP ← F5 发探测包的 IP 是 self IPQ：Member 在 up 和 down 之间来回抖动？
原因： time-until-up 没设或太小 解决： 设到 5-10 秒，让后端稳定后再标记 up
Q：用 TCP Monitor，端口正常但业务挂了？
原因： TCP Monitor 只检查端口，不检查业务层 解决： 换成 HTTP Monitor，检查 /health 端点
六、进阶：多个 Monitor 组合
# 先建一个 ICMP Monitor 做网络层检测
tmsh create ltm monitor gateway-icmp my-icmp \
interval 10 timeout 31
# 再建一个 HTTP Monitor 做应用层检测
tmsh create ltm monitor http my-http \
interval 10 timeout 31 \
send "GET /health HTTP/1.1\r\nHost: app\r\nConnection: close\r\n\r\n" \
recv "200 OK"
# 绑定：任意一个通过就算 up（宽松）
tmsh modify ltm pool myapp-pool \
monitor min 1 of { my-icmp my-http }
# 或：全部通过才算 up（严格）
tmsh modify ltm pool myapp-pool \
monitor min all of { my-icmp my-http }七、小结
Monitor 是整个 F5 运维中最容易被忽视但又最关键的部分。一次配置不当，可能导致流量打到已经挂掉的后端（502）、或者明明能用的后端被踢出（资源浪费）。
记住核心公式和三种选型，就能应对 90% 的场景。
相关阅读：
-
F5 BIG-IP 学习路线：一张图理清核心技术与架构关系
-
F5 VIP 上线全流程：Pool / VS / Profile 三板斧
-
下一篇：F5 SSL Profile 证书卸载深入篇