Consul：排障、恢复与场景自检

Consul 运维取证与发现排错

空结果排查

Consul 空结果排查 应依次记录调用身份、数据中心、服务名、passing 参数和 ACL 过滤头。目录无记录检查注册 agent、ID 与反熵同步；目录有记录而健康为空检查节点检查和服务检查；健康非空而应用失败检查返回业务地址、端口、网络和业务认证。不能只看到 HTTP 200 就判定发现链路正常，也不能把读权限不足造成的空集合当作全局实例下线。

TTL 与注销

Consul TTL 超时 首先核对续报是否由正确 agent 接受、check ID 是否对应 service:实例ID、是否被 ACL 拒绝以及服务是否真正就绪。将 TTL 调大只能延长故障可见延迟，不能修复续报归属错误。DeregisterCriticalServiceAfter 是清理策略；删除后续报旧 check 可能找不到对象，应用需要明确重新注册策略。退出前主动注销缩短残留时间，但崩溃时仍依赖检查状态收敛。

重试与恢复

Consul 恢复游标 需在 index 回退后归零；传输超时应保留最后可用快照并标记陈旧时间，采用退避和抖动重连，避免大量客户端同时打满 server。是否在发现不可用时继续使用旧地址取决于业务容错预算，应有最大陈旧期限。示例遇错退出 1，只适合阅读协议，不实现生产缓存策略。

备份与恢复保护的是集群状态，不能保证业务端连接瞬间切换。恢复前要有有效备份与成员规划，恢复后验证目录、ACL 和检查归属，并让客户端重新建立游标。旧文“出错先清理 data-dir”会破坏恢复证据，不能作为通用排错步骤。多数派不可用时，不应靠随意 bootstrap 新 server 强行宣称已恢复一致性。

权限与证据

Consul 权限排查 对比 HTTP token 与 DNS agent default token，它们是两条身份链路。read-policy.hcl 只允许 notes-api 读取并允许节点读取，不包含注册写权限。实际生产可按节点范围继续收窄。保存请求状态、过滤标记、检查输出和时间线，日志中隐藏 token，避免复制管理凭据进入文档。DNS 缓存问题要区分 agent 响应和应用进程缓存，修改注册后立刻刷新 HTTP 并不能清除后者。

操作演练与解答

题目：同事建议把 read token 换成管理 token，空数组立即消失，是否完成修复？答：只证明权限与结果有关，应恢复最小权限并补齐必要 service/node 规则，不能留下管理凭据。题目：失去多数派后业务仍能连接旧实例是否证明注册中心正常？答：不证明，它可能使用缓存地址，应分别记录目录写入、只读可见性和业务调用可用性。

适用 Consul 1.20.x，核对 2026-10-17；官方依据为 ACL rules 和 blocking queries。本页只提供推演与取证顺序，示例未执行，未做恢复演练。

启动地址、单节点与状态目录

Consul 出错先清空 data-dir 能恢复吗，client 与 advertise 相同吗？ Consul 的 server/client agent 角色与 HTTP 客户端不是同一分类。bind 是集群通信监听，advertise 是向其他节点公布的可达地址，client 对应客户端接口监听；UI 的可见性不等于服务发现或业务调用成功。0.0.0.0 扩大监听范围，不是可分发给远端的目标地址。跨数据中心、gossip 加密、HTTP 身份与业务认证也不是同一能力。

旧 Docker/dev/bootstrap 命令只有单节点启动参数，没有给出多节点故障域或恢复验收。bootstrap-expect 表达预期引导成员数，不能用一个节点获得高可用；nohup 也不提供集群托管。旧参数表的默认值、协议号、UI 目录和 INI/JSON 路径应按所选版本重新核对，不能把整张旧表当成当前完整手册。

data-dir 保存 agent 状态；错误时先清空该目录会丢失状态和排错证据，不能作为通用修复。先保存日志、版本、成员身份与现有备份，判断多数派和目录状态，再按匹配版本的恢复流程处理。历史 /tmp 数据目录、公网 client/advertise、固定镜像及清目录建议均撤回为生产部署方案；本课的发现客户端示例不宣称已经交付 server 集群安装。

Consul 自检与服务发现设计复盘

综合复盘

Consul 综合复盘 从一条请求的实际链路出发：注册进 agent，经状态同步进入目录，健康检查决定筛选集合，ACL 决定调用者能看见哪些记录，HTTP 或 DNS 将地址交给消费者，消费者最终调用业务端口。每层都能独立失败，所以“UI 里有服务”不是端到端成功证据。请按这条链路解释一个“UI 有两台、程序返回零台”的事故，而不要把所有异常都归因于 Raft。

参考答案：先确认 UI 与程序身份、数据中心和筛选条件一致；再看 critical 检查和 ACL 过滤头；之后核对程序是否命中 DNS 缓存。只有前面证据排除了权限与过滤差异，才进一步调查目录状态同步。UI 可见性与程序可见性从来不是同一合同。

决策题与解答

Consul 设计自检 包含四问。第一，何时选 DNS？当应用已有可靠 DNS/SRV 消费能力且接受缓存边界；需要检查详情、ACL 过滤证据和阻塞查询时优先 HTTP。第二，能否从 passing 推出所有依赖正常？只有检查明确覆盖的依赖才在其含义内，仍存在检查窗口。第三，阻塞查询是变更日志吗？不是，消费者拿到的是快照，不能依靠它计数所有上下线事件。第四，为什么不把管理 token 放入示例配置？配置可能被复制入版本控制，权限面超过发现需求。

独立练习与评分

Consul 故障推演 要求针对“TTL 过期但目录仍有服务”写出预期 catalog、passing health、DNS 三种观察，并指出下一条证据。参考解法：catalog 仍可见，passing 可能为空，DNS 依据健康与缓存可能继续短时返回旧结果；接着看检查时间与解析缓存 TTL。每答对一层得一分，解释过滤和缓存各得一分。将 critical 当立即删除、把 TTL 当注销延迟都说明机制仍需复习。

第二题：响应 index 从 80 变成 20，客户端是否继续等 index=80？参考解法：不能，应重建游标并重新读取快照，避免等待未来本不该等待的索引；返回零时加最小等待与速率控制。能说明“快照变化不等于每次业务事件”才算完成。

交付边界

本课程交付目录与健康、TTL、DNS、ACL 和阻塞查询理论及独立 Node 项目。没有实现服务网格、跨数据中心故障转移、TLS 证书轮换或生产守护进程，不应据此宣称生产方案已验收。所有示例未执行；静态语法检查不证明网络、权限、时序或集群一致性。读者应在自己的隔离环境验证所选补丁版本和权限策略。

适用 Consul 1.20.x，核对日期 2026-10-17；复盘事实可追溯至官方 Health API、DNS 与 ACL。