【HAProxy 数据面】Health-check 引擎：探活调度、httpchk/tcp-check 与 agent-check 边界
内容提要
本文介绍HAProxy健康检查机制与数据面调度分离的架构。探活通过TCP/HTTP/agent-check更新服务器状态，影响候选集而非客户端路径。默认TCP检查仅验证端口，httpchk/tcp-check支持L7多步探测，agent-check提供平行控制通道。disable-on-404、drain等可将探活用于发布排空。排障时需区分检查失败与队列问题，注意检查风暴风险。
延伸解读
探活与数据面分离：排障先看候选集
健康检查引擎独立于数据面请求路径，探活结果只更新服务器状态，影响候选集，而非在客户端请求时同步执行探针。因此，遇到503时，应先确认stats中服务器是否仍为UP。若仍UP，问题可能出在队列或maxconn，而非检查失败。加长检查间隔并不能解决队列问题，需区分检查失败与数据面拥塞。
检查层级选择：L4通不等于L7通
默认TCP检查仅验证端口连通，应用卡死但端口监听时仍可能被判定为UP。httpchk可发送完整HTTP请求，但默认成功条件为2xx/3xx，若应用返回404或401，需用http-check expect显式收窄，否则可能误判。选择L4、L6还是L7检查，决定了假阳性或假阴性落在哪一侧，需根据应用特性权衡。
agent-check：平行控制通道的边界
agent-check提供独立于常规健康检查的控制通道，可动态调整权重、maxconn及管理状态。但连不上agent本身不算错误，连通性应由常规检查覆盖。若agent报down后停掉agent，可能造成运维死锁，需对称恢复。此外，agent设置的DRAIN或DOWN状态不会因TCP检查变绿而自动取消，需明确谁负责撤销。
检查风暴风险：短间隔与大规模农场的隐患
每个并行检查占用连接与调度配额，若将inter设得很短且农场很大，可能先引发检查风暴，再表现为业务延迟。归因时不应只盯应用CPU，需关注检查资源消耗。可通过tune项限制并发检查或排队延后探针，避免探活自身拖垮进程。
Q&A
HAProxy的健康检查与数据面调度是什么关系？
HAProxy的健康检查与数据面调度是分离的：健康检查引擎周期性地发起独立探测，更新服务器的运行状态（如UP/DOWN），从而改变数据面可见的候选服务器集合；数据面在处理客户端请求时，从当前可用的服务器中选择目标，不会在请求路径上同步执行探针。
HAProxy默认的健康检查是什么？httpchk有什么不同？
默认健康检查只尝试建立TCP连接，验证端口是否可达。启用option httpchk后，在TCP连接建立成功后，会发送完整的HTTP请求，默认将2xx/3xx响应视为成功，其他响应或无响应视为失败。httpchk支持自定义方法、URI、版本、Host等参数，并可配合http-check指令进行多步定制。
tcp-check健康检查有什么特点？
tcp-check允许将健康检查编排成多步脚本，可对多个端口依次连接，支持SSL/SNI/ALPN，可使用字符串或正则表达式进行expect匹配，并可通过ok-status/error-status区分L4/L6/L7的成功语义。它适用于需要多服务会签的场景，例如同一服务器对象背后需要POP和IMAP都就绪。
agent-check与常规健康检查有何不同？
agent-check是独立于常规健康检查的辅助通道，HAProxy通过agent端口建立TCP连接，读取ASCII行并解析关键词，可动态调整服务器权重、maxconn，或设置管理状态（如drain、maint）。它表达的是应用或侧车进程的意图，而常规检查表达外部探测是否成功。连不上agent本身不算错误，但错误使用可能导致无法恢复。
disable-on-404是如何用于发布排空的？
disable-on-404配合httpchk使用，当服务器对健康检查返回HTTP 404时，会从负载均衡中排除，但保留持久连接，stats上报NOLB；若后续返回2xx/3xx，则立即恢复。这允许应用在下线前将探活URI改为返回404，实现优雅下线，属于排空工具箱之一。
健康检查失败与数据面503有什么关系？排障时如何区分？
健康检查失败可能导致服务器被移出候选集，从而引发503；但503也可能由队列满、maxconn限制等问题引起。排障时应先检查stats中服务器是否仍为UP，若UP则问题可能在队列或连接复用，而非健康检查。
什么是检查风暴？如何避免？
检查风暴是指健康检查本身消耗过多资源，导致进程过载，进而影响业务。当检查间隔设置过短且服务器数量大时，可能发生。可通过调整tune参数限制并发检查数，或使用spread-checks等机制分散检查时间，避免探活打满进程。
