Beacon健康码怎样接入监控？

一个Beacon客户端进程还活着，不代表它适合承担读取、验证或出块相关流量。标准健康端点把状态压缩成HTTP码：200表示节点就绪；206表示Beacon正在同步，或执行节点处于optimistic或offline；503表示未初始化或其它问题。监控要按含义分流，不能把206只理解为同步。

端点本身非常轻量

Beacon API健康端点为GET /eth/v1/node/health。

GET /eth/v1/node/health通常不需要响应体，适合高频探针。调用仍应设置短超时、记录状态码与延迟，并避免把反向代理生成的错误页当成客户端响应。健康检查路径应直达目标实例或携带可识别的上游标签。

200、206和503对应三类动作

节点就绪时返回HTTP 200，该端点通常不需要响应体。

HTTP 206表示Beacon节点正在同步，或其执行节点处于optimistic或offline；此时服务的数据可能不正确。

HTTP 503表示节点未初始化或存在其它问题；syncing_status查询参数仅用于把默认206改成指定状态码。

状态	解释	负载均衡	告警建议
200	节点就绪	可进入读流量池	持续监测延迟
206	同步中，或EL乐观/离线	不接正常关键流量	读取三字段后分流
503	未初始化或其它问题	立即摘除	按持续时间升级

206不是普通的“部分内容响应”，也不只代表共识同步。规范明确把执行节点optimistic或offline纳入206，并提醒此时服务的数据可能不正确。任何默认接受全部2xx的负载均衡规则，都可能把降级节点放进正常流量池。

存活与就绪必须分开

liveness只判断进程和HTTP栈是否能响应，过于严格会让编排系统在追赶或执行层短暂恢复时反复重启。readiness决定是否承接正常业务流量，应要求200；若业务允许降级读取，也必须明确标记数据可能不正确。

启动探针可以给予数据库打开、状态迁移和初始同步足够时间。重启不是206的默认修复动作；只有进度长时间不动、错误日志或磁盘网络指标共同异常时，才进入故障处置。

206后读取三类诊断字段

调用/eth/v1/node/syncing读取head_slot、sync_distance、is_syncing、is_optimistic和el_offline。is_syncing解释共识追赶，is_optimistic说明乐观跟随链头，el_offline指示执行客户端离线；三者需要分别路由到共识同步、执行层校验或EL连接故障。

将客户端head与可信外部参考比较时，要避免单点依赖。参考节点也可能落后；至少使用多个来源或共识指标，并把网络升级和计划维护窗口写入告警抑制。

503要先区分客户端与代理

检查响应头、上游日志和直接实例请求，确认503由Beacon客户端还是网关产生。常见根因包括数据库初始化失败、磁盘只读、端口冲突和配置错误。执行层离线在现行规范中属于206的可能原因，不能笼统塞进503。

监控面板同时展示最近状态序列、请求延迟、同步距离、进程重启数、磁盘和执行层连接。单个绿色方块不足以证明验证者职责安全，签名器、时钟和duty还需要独立监控。

探针本身也需要被监控：记录超时、DNS失败、TLS错误和上游选择，避免把采集器网络故障误判为全部Beacon节点同时离线。多实例部署时逐实例检查，再由服务层汇总可用容量；只探测负载均衡地址会隐藏某个后端长期处于206或503的情况。

与其它共识层信号组合

对等连接可参考Beacon peer_count，重组和事件流见Beacon事件流监控重组，响应字段核验可对照Beacon RANDAO响应。本文提供API探针设计，不替代客户端版本说明或验证者运行手册。

Beacon探针规范

Ethereum Beacon API getHealth：端点、200/206/503语义与syncing_status参数。
Ethereum Beacon API getSyncingStatus：is_syncing、is_optimistic与el_offline诊断字段。

资料访问时间为2026-08-14。仍需保留的边界：具体客户端可能在启动窗口或代理层覆盖状态码；监控应记录客户端版本、反向代理行为，并在206时继续读取is_syncing、is_optimistic与el_offline。