【HAProxy 数据面】排障与可观测：五轴清单与 stats / sess / 日志落点
内容提要
本文介绍HAProxy排障方法，提出五轴清单：Accept/bind、Stream/mux、ACL/路由、Upstream/health、Reload/Runtime。排障时先选主轴，再用show info/stat/sess等只读命令定位信号，结合日志判断故障层。强调避免盲目操作，按症状走最短路径，并注意TLS、线程、stick-table等常见误判点。
延伸解读
五轴定位：先选轴再动命令
排障时先根据症状选择主轴，再使用对应的只读命令，避免盲目操作。例如，连接被拒先查Accept/bind轴，卡死或半开查Stream/mux轴，路由错误查ACL/路由轴，503或队列堆积查Upstream/health轴，配置未生效查Reload/Runtime轴。这种结构化方法能快速缩小范围，避免在多个层面空转。
信号分层：聚合与个案互补
stats页面和show stat提供聚合计数，适合判断哪一层计数器在动；日志则记录单个请求的终止状态码和路由结果，是“判决书”；show sess用于深挖活跃会话细节。三者应配合使用，聚合指标用于选轴，个案用日志和sess，避免用高基数指标冒充低基数信号。
常见误判：TLS与线程问题
TLS握手失败常被误报为上游故障，但backend计数器几乎不动，应先用Accept轴分侧。线程过载（如单核打满）可能伪装成上游变慢，若延迟统计正常但show activity显示线程倾斜，应检查nbthread和cpu-map，而非盲目扩容上游。
运维纪律：避免危险操作
高峰时全量show sess all本身就是负载事件，应先用短格式定位再深挖。clear table会瞬间打开放行窗口，需先区分键不存在、计数异常或peers断连三类情况。reload后需用Master CLI核对leaving worker，文件mtime新不等于数据面已加载。
Q&A
HAProxy排障时，如何快速定位问题所在的层次？
HAProxy排障时，应先根据症状选择一个主轴，如Accept/bind、Stream/mux、ACL/路由、Upstream/health或Reload/Runtime，然后使用对应的只读命令（如show info、show stat、show sess等）来定位信号，并结合日志判断故障层。避免盲目操作，按症状走最短路径。
HAProxy的show stat命令主要用来查看什么？
show stat命令用于查看frontend、backend和server的计数器，包括吞吐量、错误数、状态码分布和队列深度等，以CSV或JSON格式输出。它帮助判断哪一层的计数器在变化，从而定位问题所在。
HAProxy日志中的终止状态码有什么作用？
终止状态码是HAProxy日志中表示会话结束状态的字段，它区分了客户端放弃、服务器超时、LB自身拒绝等情况。学会读取该字段有助于快速判断故障类型，缩短MTTR。
HAProxy排障时，为什么不能随意使用show sess all？
show sess all会输出所有活跃会话的详细信息，在高并发主机上执行该命令本身就会造成负载，可能影响性能。因此，生产环境应先使用短格式定位，再针对特定会话ID深入查看。
HAProxy中，如果配置已修改但行为未变，可能的原因有哪些？
可能的原因包括：只修改了Runtime但未连接正确的进程；只修改了文件但未reload；刚reload后leaving worker仍在服务长连接；修改了map/ACL文件但进程内仍是旧内存映像。需要根据具体情况检查文件与内存状态。
HAProxy中，粘滞或限流异常时，应该先检查什么？
应先使用show table查看键是否存在、计数是否符合预期，然后检查peers是否同步、reload是否导致表清空。不要盲目怀疑LB算法，也不要随意清表，以免瞬间打开放行窗口。
HAProxy排障时，如何区分TLS问题与上游故障？
TLS问题常被误报为上游故障。如果握手失败发生在frontend bind或SNI阶段，backend计数器几乎不动，应优先检查accept轴和TLS相关配置，再进入上游轴排查。
HAProxy排障时，为什么不能只依赖Grafana面板？
Grafana面板提供聚合指标，但可能掩盖细节。排障时应结合日志和show sess等命令获取个案信息，聚合指标用于选轴，个案用日志和sess，两套信号不能互相冒充。
