6.4 监控、持久化治理与性能优化

6.4 监控、持久化治理与性能优化

本节摘要：把前几案的排查手段前置为监控与治理：核心指标清单与告警阈值、快照与事务日志的日常治理、写延迟高的按序排因，以及容量规划的经验公式。本节是运维 ZooKeeper 的常备手册。

从救火到巡检

前三个案件的排查命令有个共同问题：都是事后取证。本节把它们改造成事前巡检——同样的指标，从"出事后翻日志"变成"每天看曲线、越线就告警"。ZooKeeper 的运维面不大，指标十几个就够，但每个指标的曲线形态都对应明确的病理，值得逐个认识。

核心指标与告警线

第一梯队四项，缺一不可：

第二梯队三项：zk_open_file_descriptor_count（接近进程文件描述符上限即扩 limit，客户端规模增长最先撞的墙）、zk_packets_sent 与 received（秒级突刺对照羊群效应时段）、fsync 延迟（日志盘的 P99，写延迟病根的最终答案）。采集方式两种：定时抓 mntr 输出解析成时序指标，或开启 JMX 从进程内部取——前者简单通用，后者指标更全，团队已有 Prometheus 栈就选前者加 exporter。

# 最小可用巡检脚本骨架（定时任务每分钟跑）
$ for h in node1 node2 node3; do
    state=$(echo mntr | nc $h 2181 | findstr "zk_server_state")
    lat=$(echo mntr | nc $h 2181 | findstr "zk_avg_latency")
    echo "$h -> $state / $lat"
  done
node1 -> zk_server_state leader / zk_avg_latency 0
node2 -> zk_server_state follower / zk_avg_latency 0
node3 -> zk_server_state follower / zk_avg_latency 0
# 告警规则示例：avg_latency 连续 3 个采样点大于 10ms 触发提醒
#              synced_followers < followers 持续 5 分钟触发排查
​

图：写延迟排因决策路径

持久化治理：日志与快照的日常

2.3 节给过结论（autopurge 两行配置），这里补齐治理视野。事务日志是写路径的一部分，永远不要让它与快照、与其他应用的 IO 混布在同一块盘；快照是恢复的起点，3 份保留够用但必须验证可恢复。一项被普遍忽略的演练：每季度做一次真恢复——拿最近快照与日志在测试机起一个单机实例，验证数据完整。恢复演练没做过的集群，备份等于没备份。

# 恢复演练的标准动作（每季度一次，测试环境执行）
$ ls /var/lib/zookeeper/version-2
snapshot.2a0000004f  log.2a00000040
# 把最近一次快照与其后日志拷到测试机的 dataDir，启动单机实例
$ bin/zkServer.sh start-foreground
$ zkCli.sh -server 127.0.0.1:2181 ls /services/pay
# 子节点与生产一致即演练通过；全过程记录耗时，作为 RTO 依据
​

优化清单：按投入产出比排序

给一份按性价比排序的优化清单，前两项覆盖绝大多数案例：一、事务日志独立高速盘（写延迟的根治术，4.1 节原理）；二、autopurge 开启加定期恢复演练（防盘满假死与备份失效）；三、JVM 堆内存 8 GB 以内、用 G1（快照与大目录遍历是堆内操作，堆过大反而拖长 GC——ZooKeeper 的内存占用有界，不需要大堆）；四、客户端治理（6.2 节闸门加 3.3 节 namespace 隔离）；五、 升级到当前稳定版本（3.5 之后默认用的选举协议与稳定性均有实质改进，升级前在测试集群压测）。

反清单同样重要——不要做的事：给 ZooKeeper 换 NVMe 阵列不如先把混布的日志挪走；给读扩展狂加 Observer 不如先查羊群；调大 jute.maxbuffer 放行大节点不如把大数据请出去。优化先治滥用，再谈硬件。

要点回顾

• 监控四金标：平均延迟、outstanding、落队 Follower 数、zxid 增速，曲线形态对应明确病理。
• 写延迟三连查：fsync 盘、快照时机、羊群滥用，按命中率排序，独立日志盘是第一处方。
• 持久化治理两件事：日志与快照分盘隔离，每季度真恢复演练验证备份有效性。
• 容量按写入预算规划：写扩容靠减少写入而非堆机器，读扩展才考虑加节点。

常见疑问

问：有没有一键巡检工具？ 社区有第三方监控模板（Prometheus exporter 配套的告警规则集）可用作起点，但阈值必须按自己的业务写入节奏校准——别人的阈值是别人的流量形状喂出来的。

冤案复查完结。最后一章跳出单座法庭，看看 ZooKeeper 在整个分布式生态里的位置与未来。

变更管理：滚动升级的标准动作

运维手册里不能只有监控，还得有变更纪律。ZooKeeper 的版本升级或配置变更走标准五步：

1. 变更前：全量备份配置与数据目录快照，记录当前角色分布
2. 单台滚动：先动 Follower，观察 mntr 全绿后再动下一台
3. Leader 最后动：先手动触发换届（停 Leader 让其自然让位），旧主降级后再升级它
4. 全程窗口：每步之间至少观察十分钟，盯 avg_latency 与 synced_followers
5. 收尾：conf 四字命令核对生效配置，恢复演练一次验证数据完整
​

第三步的细节值得强调：别在 Leader 在任时直接重启它，虽然协议允许，但那是把"计划内变更"造成"计划外换届"。先用停机让位的方式把换届安排在可控时刻，是老运维的体面。

延伸追问

问：指标都健康，但用户还是反映"偶尔慢"，怎么查？ 指标是服务端视角，用户慢可能在客户端：SDK 重试风暴、回调阻塞、连接池配置不当。此时抓客户端侧的 ConnectionLoss 频率与 GC 日志（6.3 节对时间线的方法），别在服务端死磕。