负载均衡的健康检查间隔设成一秒、超时一秒，四台后端每秒被探测八次，nginx 访问日志里健康检查请求占了总请求数的三成。
一开始怀疑是「七层检查每次都要建连，开销比四层大」，查了一圈，方向不对。
把日志和配置对完，能解释这个现象的基本就这几处。检查间隔太短，探测本身变成了业务负载。还有一种是检查路径走完整业务逻辑，每次都查数据库。
不容易想到的是，后端只剩两台，探测占比被进一步放大。
上来先统计健康检查请求的占比
awk '{print $7}' /var/log/nginx/access.log | grep -c healthz接着把探测间隔放宽到五秒
curl -s http://slb.console/api/lb/lb-xxx/healthcheck | head -c 300健康检查走轻量路径不碰数据库
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' http://10.0.1.10/healthz复核故障摘除时间是否可接受
tail -50 /var/log/nginx/error.log | grep -i upstream别只看报错消失，验证要多做一步。健康检查请求占比降到百分之五以内，后端 QPS 下降三成后业务延迟同步改善，故障摘除仍在十秒内。
探测间隔要在发现速度和额外负载之间取平衡，十台以上后端五秒足够；健康检查接口不要碰数据库和外部依赖。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。