bigywater.tech
ZooKeeper · 70

ZooKeeper 生产故障排查

生产上出问题时,客户端往往只有一个 ConnectionLoss 或超时,真正的原因在服务端日志里。这篇把前面实验里造出来的几类故障整理成一张速查表:症状 → 第一条命令 → 日志关键字。每一行日志都是真实造出来的。

只看客户端不够
ConnectionLoss / 超时的真正原因几乎都在服务端日志
5 类现造 + 2 类引用
没有多数派、连接超限、写慢、会话过期、请求过大;磁盘满、启动失败引自第 57、58 篇
日志关键字
Cannot open channel / Too many connections / fsync-ing / Invalid session / Len error

速查表

实测 · 本机执行输出
  ■ A. 集群没有多数派(3 个节点只起了 1 个)
    客户端看到:KazooTimeoutError(连接 / 超时)
    先执行:echo srvr | nc 127.0.0.1 7300
      → This ZooKeeper instance is not currently serving requests
    服务端日志:Cannot open channel to 3 at election address /127.0.0.1:7502
    服务端日志:Cannot open channel to 2 at election address /127.0.0.1:7501
  ■ B. 单个 IP 连接数超限(maxClientCnxns=3)
    客户端看到:KazooTimeoutError(连接超时)
    先执行:echo cons | nc 127.0.0.1 7301(会被拒绝,先看日志)
      → (新连接被服务端直接拒绝,四字命令自己也是一个连接)
    服务端日志:Message: Error accepting new connection: Too many connections from /127.0.0.1 - max is 3
  ■ C. 写变慢(这里把 fsync 告警阈值调到 1 ms 来触发日志)
    客户端看到:同步写 p50 约 3 ms
    先执行:echo mntr | nc 127.0.0.1 7302 | grep fsync
      → zk_avg_fsynctime = 2.3762
      → zk_max_fsynctime = 9
    服务端日志:fsync-ing the write ahead log in SyncThread:0 took 3ms which will adversely effect operation latency.File size is 67108880 bytes. See the ZooKeeper tr
  ■ D. 会话过期(服务端被暂停 7 秒,会话超时 4 秒)
    客户端看到:状态变化 ['SUSPENDED', 'LOST', 'CONNECTED']
    先执行:echo dump | nc 127.0.0.1 7303(看 Session Sets 与临时节点)
      → 临时节点 /e 随会话过期被删除:True
    服务端日志:Invalid session 0x1000c5abb610000 for client /127.0.0.1:59524, probably expired
    服务端日志:Invalid session 0x1000c5abb610000 for client /127.0.0.1:59525, probably expired
  ■ E. 请求超过 jute.maxbuffer(写 2 MiB 的 znode)
    客户端看到:ConnectionLoss
    先执行:看服务端日志(客户端只有 ConnectionLoss)
    服务端日志:java.io.IOException: Len error. A message from /127.0.0.1:59533 with advertised length of 2097203 is either a malformed message or too large to proces

这张表不替代前面各篇的细节,是把「现象 → 去哪里看」放在一起。排查时的通用顺序:(1)srvr 看节点是否在服务及角色;(2)mntr 看延迟 / 积压 / 连接数;(3)服务端日志按关键字搜;(4)对照客户端的状态变化(SUSPENDED / LOST)。

引用前面的故障

磁盘满与启动失败的日志关键字直接取自第 57、58 篇保存的实验输出,没有重新造一遍。

分步演示

故障排查
本步的对象

    本文用到的工具与边界

    • 本机 macOS 27 / ZooKeeper 3.9.6(brew 安装的 jar,用 java -cp 直接启动自己的实例,OpenJDK 17 Temurin,JVM 堆 128 MiB)/ 本机回环端口 7300+,数据在临时目录;默认 tickTime=2000;计时用 time.perf_counter,数字每次运行会有小幅抖动。每类故障用一个新节点造出;会话过期用 SIGSTOP 暂停服务端;fsync 告警用 -Dzookeeper.fsync.warningthresholdms=1 触发
    • 没有验证:真实生产环境的复杂场景(多个故障叠加)、日志级别调到 DEBUG 之后的排查信息、Kubernetes / 云环境特有的问题(DNS、Pod IP 变化)
    京ICP备2026067502号-1京公网安备11010502063487号