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