11.9.6 常见告警场景与处置流程

本节聚焦 ZooKeeper 常见告警场景的识别、影响评估与标准化处置流程，确保告警可执行、可复盘、可持续优化。告警处置遵循“确认范围—研判影响—临时止血—根因修复—复盘优化”的闭环。

原理草图（告警闭环流程）

文章图片

统一检查命令与脚本（先执行，后进入对应场景）

# 1) 四字命令快速检查角色、延迟、会话（需四字命令启用）
echo ruok | nc 127.0.0.1 2181
echo stat | nc 127.0.0.1 2181
echo mntr | nc 127.0.0.1 2181
echo srvr | nc 127.0.0.1 2181

# 2) 进程与端口
ps -ef | grep -E 'org.apache.zookeeper|QuorumPeerMain'
ss -lntp | grep 2181

# 3) 关键日志
tail -n 200 /var/log/zookeeper/zookeeper.log

# 4) 资源与磁盘
top -b -n 1 | head -n 20
df -h /data/zookeeper /data/zookeeper/logs
iostat -x 1 3

# 预期效果：
# - stat/srvr 显示 Mode: leader/follower
# - mntr 显示 zk_avg_latency, zk_packets_received 等指标

一、节点存活与仲裁相关告警
- 典型告警：集群可用节点数低于法定多数、Leader 丢失、频繁选举。
- 影响评估：写入不可用或高延迟，短时抖动导致客户端频繁重连。
- 处置流程与示例：
1) 确认在线节点与角色分布
bash # 在每个节点执行 echo stat | nc 127.0.0.1 2181 | egrep 'Mode|Clients|Connections' # 预期：1个 leader + 其余 follower
2) 检查宕机节点进程与端口
bash systemctl status zookeeper journalctl -u zookeeper -n 200
3) 磁盘或资源耗尽时先恢复
bash df -h /data/zookeeper /data/zookeeper/logs # 清理旧快照与日志（谨慎） ls -lt /data/zookeeper/version-2/ | head ls -lt /data/zookeeper/logs/ | head
4) 排查网络抖动与时钟偏差
bash ping -c 3 zk-node2 chronyc sources -v
5) 修复后观察选举次数是否回落（mntr）
bash echo mntr | nc 127.0.0.1 2181 | egrep 'leader|followers|zk_server_state'

  • 排错提示：频繁选举常见于网络抖动、GC 暂停、磁盘 I/O 高。
  • 练习：模拟关闭一个 follower，观察 leader 是否稳定，记录恢复时间。

二、连接数与会话异常告警
- 典型告警：活跃连接数突增、会话超时率升高、客户端频繁重连。
- 影响评估：会话风暴导致负载激增，影响其他客户端可用性。
- 处置流程与示例：
1) 识别异常客户端来源与连接分布
bash echo cons | nc 127.0.0.1 2181 | head -n 20 # 预期：可见客户端IP、会话id、待处理请求数
2) 检查应用侧重试策略与超时配置（示例配置）
properties # 应用配置示例 zookeeper.session.timeout.ms=60000 zookeeper.connection.timeout.ms=15000 zookeeper.retry.backoff.ms=1000 zookeeper.retry.max=5
3) 临时限流或隔离异常客户端（iptables 示例）
bash iptables -A INPUT -s 10.0.0.99 -p tcp --dport 2181 -j DROP iptables -L -n | grep 2181
4) 优化客户端重连退避、心跳配置；核对近期发布或流量激增。

  • 排错提示：大量临时节点创建失败或短连接抖动时，连接数会异常突增。
  • 练习：在测试环境使用脚本反复创建临时节点，观察连接数变化。

三、延迟与请求超时告警
- 典型告警：响应时间升高、请求失败率上升、队列积压。
- 影响评估：业务读写延迟，依赖组件阻塞扩散。
- 处置流程与示例：
1) 观察 JVM GC 与 I/O 指标
bash echo mntr | nc 127.0.0.1 2181 | egrep 'zk_avg_latency|zk_max_latency|zk_outstanding_requests' iostat -x 1 3
2) 检查快照与日志刷盘是否造成 I/O 拥塞
bash lsof | grep zookeeper | grep log
3) 临时调整写入负载（业务侧限流）
4) 优化磁盘与 JVM 参数（示例）
properties # /etc/zookeeper/zoo.cfg autopurge.snapRetainCount=5 autopurge.purgeInterval=1
5) 必要时扩容或迁移高负载节点，滚动重启验证恢复效果。

  • 排错提示：延迟高但 CPU 低常指向磁盘或网络瓶颈。
  • 练习：调整 autopurge 参数后观察日志目录增长速率变化。

四、磁盘与数据持久化告警
- 典型告警：磁盘使用率超阈值、事务日志增长异常、快照失败。
- 影响评估：写入失败、数据不一致风险增加、节点退出。
- 处置流程与示例：
1) 识别数据目录与日志目录占用
bash grep -E 'dataDir|dataLogDir' /etc/zookeeper/zoo.cfg du -sh /data/zookeeper /data/zookeeper/logs
2) 清理旧快照与日志（谨慎执行）
bash # 示例：保留最近5份快照与日志 ls -1t /data/zookeeper/version-2/snapshot.* | tail -n +6 | xargs -r rm -f ls -1t /data/zookeeper/logs/log.* | tail -n +6 | xargs -r rm -f
3) 若磁盘性能下降，切换到高性能盘或独立数据盘。
4) 调整快照频率与日志滚动参数（zoo.cfg）。
5) 验证快照生成与日志清理是否恢复稳定。

  • 排错提示：快照失败常伴随磁盘满或权限错误。
  • 练习：模拟磁盘占用达到 90%，观察快照告警是否触发。

五、内存与 JVM GC 告警
- 典型告警：堆内存持续上升、Full GC 频繁、GC 暂停时间过长。
- 影响评估：请求延迟和超时增加，选举抖动风险。
- 处置流程与示例：
1) 采集 JVM GC 日志与内存使用
bash jcmd $(pgrep -f QuorumPeerMain) GC.heap_info jcmd $(pgrep -f QuorumPeerMain) VM.flags
2) 检查临时节点泄漏或 Watcher 风暴
bash echo wchs | nc 127.0.0.1 2181 # 输出显示 watcher 数量
3) 临时降低客户端 Watch 订阅；限制临时节点数量。
4) 调整堆大小与 GC 参数（示例）
bash # /etc/zookeeper/java.env export JVMFLAGS="-Xms2g -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"
5) 必要时重启释放内存并观察恢复。

  • 排错提示：watcher 数量异常增长常来自客户端重复注册。
  • 练习：对比调优前后 zk_avg_latency 与 GC 暂停时间。

六、数据一致性与状态异常告警
- 典型告警：节点状态不一致、同步延迟过高、事务 zxid 落后。
- 影响评估：读写一致性风险，主从切换异常。
- 处置流程与示例：
1) 通过统计指标确认落后节点与同步差距
bash echo stat | nc 127.0.0.1 2181 | egrep 'Zxid|Latency|Mode'
2) 检查网络延迟与磁盘 I/O
bash ping -c 5 zk-node1 iostat -x 1 3
3) 对落后严重节点执行重同步或滚动重启
bash systemctl restart zookeeper
4) 若存在长时间分区，先恢复网络再校验一致性。
5) 优化网络与存储，避免跨机房不稳定链路。

  • 排错提示：Follower 长期落后可能是磁盘抖动或网络丢包。
  • 练习：断开某 follower 网络 1 分钟后恢复，观察 zxid 追赶情况。

七、安全与权限相关告警
- 典型告警：认证失败率上升、ACL 校验错误、非法访问。
- 影响评估：服务可用性与数据安全风险。
- 处置流程与示例：
1) 核对客户端认证方式与变更记录
2) 检查证书或凭据过期情况
3) 临时阻断异常来源 IP
bash iptables -A INPUT -s 203.0.113.5 -p tcp --dport 2181 -j DROP
4) 规范 ACL 变更流程与审批
5) 复盘审计日志，完善访问控制策略

  • 排错提示：ACL 失败常由客户端未携带正确凭据。
  • 练习：使用 zkCli.sh 测试带认证与不带认证访问差异。

八、处置流程标准化要点
- 告警分级：P1（不可用）、P2（性能严重下降）、P3（轻微异常）。
- 响应 SLA：P1 15 分钟内响应，P2 30 分钟内响应，P3 当班处理。
- 临时止血优先：先保障集群可用，再处理根因。
- 处置记录：包含起因、指标变化、关键操作、恢复时间与复盘结论。
- 改进闭环：针对重复告警调整阈值、优化监控维度与自动化脚本。

附：简单巡检脚本（可用于定时任务）

#!/usr/bin/env bash
# /usr/local/bin/zk_healthcheck.sh
HOST=127.0.0.1
PORT=2181

ruok=$(echo ruok | nc $HOST $PORT)
mode=$(echo stat | nc $HOST $PORT | awk '/Mode/ {print $2}')
lat=$(echo mntr | nc $HOST $PORT | awk '/zk_avg_latency/ {print $2}')

echo "ruok=$ruok mode=$mode avg_latency=$lat"
# 预期输出：ruok=imok mode=leader/follower avg_latency=xx