13.10.7 典型案例复盘与经验总结

本节通过典型故障案例复盘，归纳HAProxy在生产环境中的常见问题与经验要点，形成可复用的排障与优化方法论，并给出可执行的排查命令、配置示例与练习。

文章图片

案例一：高并发场景下连接耗尽导致服务不可用#

现象：流量突增后，业务端大量超时，HAProxy日志出现“Proxy xxx reached maxconn”。
排查过程：
- 确认前端maxconn与后端maxconn配置不匹配。
- 观察系统级ulimit -n与net.core.somaxconn未按高并发场景调优。
- 后端应用实例处理能力不足，出现大量排队。

命令与解释 

# 查看当前HAProxy进程最大连接数与限制
echo "show info" | socat stdio /run/haproxy/admin.sock | egrep "Maxconn|Maxsock|CurrConns"

# 查看系统文件描述符限制
ulimit -n
cat /proc/$(pidof haproxy | awk '{print $1}')/limits | grep "open files"

# 查看内核TCP队列与连接参数
sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog

# 查看当前连接数与状态
ss -s
ss -ant | head

配置示例（/etc/haproxy/haproxy.cfg） 

global
    maxconn 40000
    stats socket /run/haproxy/admin.sock mode 660 level admin
    user haproxy
    group haproxy

defaults
    mode http
    timeout connect 3s
    timeout client 30s
    timeout server 30s
    timeout queue 5s

frontend fe_http
    bind *:80
    maxconn 30000
    default_backend be_app

backend be_app
    balance roundrobin
    server app1 10.0.0.11:8080 maxconn 8000 check
    server app2 10.0.0.12:8080 maxconn 8000 check
    server app3 10.0.0.13:8080 maxconn 8000 check

系统调优示例 

# /etc/sysctl.d/99-haproxy.conf
net.core.somaxconn=65535
net.ipv4.tcp_max_syn_backlog=65535

# 生效
sysctl -p /etc/sysctl.d/99-haproxy.conf

验证与预期效果 

# 平滑重载
haproxy -f /etc/haproxy/haproxy.cfg -c && systemctl reload haproxy

# 预期：Maxconn与系统FD上限匹配，连接溢出告警消失
echo "show info" | socat stdio /run/haproxy/admin.sock | egrep "Maxconn|CurrConns"

经验总结：连接耗尽往往是系统参数、配置策略、后端能力三者不匹配导致，需在容量评估阶段完成联动配置。

练习
1. 将maxconn提升到60000，观察系统FD是否成为瓶颈。
2. 使用ab -n 50000 -c 200压测，记录CurrConns变化与超时率。

案例二：健康检查误判引发大量摘除#

现象：后端服务短暂抖动后被大量剔除，流量集中到少数实例，整体吞吐下降。
排查过程：
- 健康检查inter过短，fall过小，瞬时抖动被判定为故障。
- 后端服务启动慢，未配置slowstart导致瞬时负载过高。

配置示例（/etc/haproxy/haproxy.cfg） 

backend be_app
    balance roundrobin
    option httpchk GET /healthz
    http-check expect status 200
    default-server inter 3s fall 5 rise 3 slowstart 30s
    server app1 10.0.0.11:8080 check
    server app2 10.0.0.12:8080 check
    server app3 10.0.0.13:8080 check

命令与解释 

# 观察后端UP/DOWN状态
echo "show stat" | socat stdio /run/haproxy/admin.sock | awk -F, '$1=="be_app"{print $2,$18,$19,$37}'
# 字段含义：$18=状态, $19=检查状态, $37=最近一次检查结果

# 手动探测健康检查接口
curl -i http://10.0.0.11:8080/healthz

验证与预期效果
- 抖动期间后端不会被快速摘除
- 恢复后slowstart逐步放量

经验总结：健康检查策略需与业务特性匹配，避免过度敏感导致误判与雪崩效应。

练习
1. 将inter从3s改为1s并对后端施加抖动，观察摘除比例。
2. 关闭slowstart对比恢复阶段的响应时延。

案例三：会话保持失效引发登录态丢失#

现象：用户频繁掉线，登录态不稳定，问题随扩容出现。
排查过程：
- 使用roundrobin算法但未启用粘性会话。
- 客户端与代理之间存在多级NAT，source方式失效。

配置示例一：Cookie会话保持 

backend be_web
    balance roundrobin
    cookie SRVID insert indirect nocache
    server web1 10.0.0.21:8080 check cookie w1
    server web2 10.0.0.22:8080 check cookie w2

配置示例二：Stick-table会话保持 

backend be_web
    balance roundrobin
    stick-table type ip size 200k expire 30m
    stick on src
    server web1 10.0.0.21:8080 check
    server web2 10.0.0.22:8080 check

命令与解释 

# 查看stick-table状态
echo "show table be_web" | socat stdio /run/haproxy/admin.sock | head

验证与预期效果
- 用户请求连续命中同一后端
- 登录态稳定

经验总结：粘性会话策略需考虑网络拓扑与业务会话存储机制，避免单点绑定导致扩缩容风险。

练习
1. 使用curl -I检查响应头Set-Cookie是否插入。
2. 切换为stick-table并对比多级NAT场景下的命中率。

案例四：证书更新导致SSL终止失败#

现象：证书更新后HTTPS握手失败，大量502。
排查过程：
- 证书链不完整或权限不足。
- bind配置中证书路径变更未重载生效。

配置示例与更新流程 

# 1) 拼接证书链（fullchain + key）
cat /etc/ssl/certs/site.crt /etc/ssl/certs/ca.crt > /etc/haproxy/ssl/site.pem
cat /etc/ssl/private/site.key >> /etc/haproxy/ssl/site.pem
chmod 600 /etc/haproxy/ssl/site.pem

# 2) 配置文件
# /etc/haproxy/haproxy.cfg
frontend fe_https
    bind *:443 ssl crt /etc/haproxy/ssl/site.pem
    default_backend be_app

# 3) 语法检查与平滑重载
haproxy -f /etc/haproxy/haproxy.cfg -c && systemctl reload haproxy

排错命令 

# 验证证书链
openssl s_client -connect 127.0.0.1:443 -showcerts < /dev/null

# 检查HAProxy加载的证书
echo "show ssl cert" | socat stdio /run/haproxy/admin.sock

经验总结：SSL证书更新需标准化流程与预检机制，避免在高峰期直接替换。

练习
1. 模拟证书链缺失，观察握手失败报错。
2. 使用平滑重载验证不中断切换。

案例五：日志与监控缺失导致问题定位缓慢#

现象：响应慢与错误率上升但无明确根因。
排查过程：
- 未开启httplog与关键字段，无法定位慢请求。
- 监控缺乏queue、retries、sess_rate等指标。

配置示例（日志与监控） 

global
    log /dev/log local0
    stats socket /run/haproxy/admin.sock mode 660 level admin

defaults
    log global
    option httplog
    option logasap
    timeout connect 3s
    timeout client 30s
    timeout server 30s

listen stats
    bind *:8404
    stats enable
    stats uri /stats

日志样例与字段解释 

Oct 01 10:20:01 haproxy[1234]: 10.0.0.5:51514 [01/Oct/2024:10:20:01.123] fe_http be_app/app1 0/0/5/20/25 200 512 - - ---- 1/1/0/0/0 0/0 "GET /api/v1/users HTTP/1.1"
# Tq/Tw/Tc/Tr/Tt：队列/等待/连接/响应/总耗时（ms）

指标排查命令 

# 统计队列与重试
echo "show stat" | socat stdio /run/haproxy/admin.sock | awk -F, '$1=="be_app"{print $2,$5,$7,$13,$14}'
# $5=当前会话, $7=队列长度, $13=连接重试, $14=重试失败

经验总结：可观测性决定排障效率，日志与指标要覆盖端到端性能路径。

练习
1. 观察Tq/Tw/Tc/Tr/Tt的变化，定位慢请求瓶颈位置。
2. 增加timeout queue并比较队列指标变化。

复盘原则与通用经验#

  • 变更可回滚：所有配置变更需具备快速回退策略，优先使用灰度发布。
  • 容量先行：性能调优必须建立在容量评估与压测基础上。
  • 一致性配置：多节点HAProxy必须使用配置管理工具保证一致性。
  • 健康检查与限流联动：故障转移需要与限流、熔断策略协同。
  • 自动化排障：建立常用排障脚本库，标准化日志检索与指标分析流程。

通过系统化复盘与经验沉淀，能显著降低HAProxy运维风险，提高高可用架构的稳定性与可恢复性。