11.9.5 告警规则设计与分级

告警规则设计与分级#

告警规则需围绕“影响面、可恢复性、业务重要性、处理时效”设计，并落地到可执行的监控与告警配置。以下包含分级原则、规则示例、命令与排错操作，以及练习。

1. 分级原则与级别定义#

P0（致命）：集群不可用或一致性破坏，影响核心业务可用性。
P1（严重）：关键节点异常或性能严重退化，可能触发雪崩。
P2（一般）：性能或容量风险，短期可容忍但需跟进。
P3（提示）：趋势性指标或操作提示，辅助优化与排查。

2. 告警设计原理草图#

3. 规则设计方法与阈值建议#

静态阈值：适用于上限明确的指标，如磁盘使用率、连接数。
动态阈值：适用于波动指标，如延迟、TPS，采用滑动窗口均值/分位数。
组合告警：降低误报，如“延迟升高 + 连接数攀升 + 选举次数增加”。
抑制与降噪：同一事件链路去重、抑制窗口与升级机制。

典型指标分级建议
- P0：alive_servers < quorum、短时多次选举、数据一致性校验失败
- P1：关键节点宕机、Session大量过期、磁盘>90%持续增长
- P2：99分位延迟高于基线、连接数>80%、watcher数量异常
- P3：短时抖动、变更/维护提醒

4. 规则示例（Prometheus Alert Rules）#

文件路径示例：/etc/prometheus/rules/zookeeper_alerts.yml

groups:
- name: zookeeper_alerts
  rules:
  - alert: ZK_Quorum_Lost_P0
    expr: sum(zk_alive) < 2
    for: 1m
    labels:
      severity: P0
    annotations:
      summary: "ZooKeeper quorum不足"
      description: "可用节点数低于法定票数，集群不可用风险"

  - alert: ZK_Election_Storm_P1
    expr: increase(zk_election_count[5m]) > 3
    for: 1m
    labels:
      severity: P1
    annotations:
      summary: "ZooKeeper频繁选举"
      description: "5分钟内选举次数>3，可能出现抖动或脑裂"

  - alert: ZK_Latency_High_P2
    expr: histogram_quantile(0.99, sum(rate(zk_request_latency_bucket[5m])) by (le)) > 200
    for: 5m
    labels:
      severity: P2
    annotations:
      summary: "ZooKeeper 99分位延迟升高"
      description: "99分位延迟>200ms持续5分钟"

  - alert: ZK_Disk_Usage_P1
    expr: node_filesystem_usage_percent{mountpoint="/var/lib/zookeeper"} > 90
    for: 10m
    labels:
      severity: P1
    annotations:
      summary: "ZooKeeper磁盘使用率过高"
      description: "数据目录磁盘使用率>90%"

说明
- zk_alive、zk_election_count、zk_request_latency_bucket为导出器指标。
- node_filesystem_usage_percent来自Node Exporter。
- sum(zk_alive) < 2假设3节点集群，quorum=2。

5. 告警收敛与升级策略示例#

Alertmanager 路由策略（分级通知）
文件路径示例：/etc/alertmanager/alertmanager.yml

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
  - match:
      severity: P0
    receiver: 'oncall'
  - match:
      severity: P1
    receiver: 'oncall'
  - match:
      severity: P2
    receiver: 'duty_group'
  - match:
      severity: P3
    receiver: 'mail_only'

receivers:
- name: 'oncall'
  webhook_configs:
  - url: 'http://oncall-webhook.local/alert'
- name: 'duty_group'
  webhook_configs:
  - url: 'http://duty-group.local/alert'
- name: 'mail_only'
  email_configs:
  - to: 'ops@example.com'

6. 命令与脚本示例（四字命令快速验证）#

安装与准备（四字命令工具）
- 需启用 4lw.commands.whitelist=srvr,stat,ruok,conf（路径：/etc/zookeeper/zoo.cfg）
- 重启服务：

systemctl restart zookeeper

手动验证脚本（检查可用节点与延迟）

#!/usr/bin/env bash
# 文件: /usr/local/bin/zk_health_check.sh
# 用途: 快速检查ZooKeeper节点状态与延迟
ZK_HOST=127.0.0.1
ZK_PORT=2181

echo "== ruok =="
echo ruok | nc ${ZK_HOST} ${ZK_PORT}

echo "== stat =="
echo stat | nc ${ZK_HOST} ${ZK_PORT} | egrep "Mode|Latency|Connections|Node count"

echo "== srvr =="
echo srvr | nc ${ZK_HOST} ${ZK_PORT} | egrep "Mode|Latency|Connections|Zxid"

预期效果
- ruok 返回 imok
- stat 中 Mode: leader/follower、Latency、Connections正常

7. 排错步骤示例#

场景：P0 quorum不足

# 1) 查看节点状态
echo stat | nc zk1 2181 | egrep "Mode|Zxid|Connections"
echo stat | nc zk2 2181 | egrep "Mode|Zxid|Connections"
echo stat | nc zk3 2181 | egrep "Mode|Zxid|Connections"

# 2) 检查进程与端口
ps -ef | grep QuorumPeerMain
ss -lntp | grep 2181

# 3) 检查磁盘与事务日志
df -h /var/lib/zookeeper
ls -lh /var/lib/zookeeper/version-2

常见原因
- 节点宕机、网络分区、磁盘写满、JVM GC过长

8. 练习（动手验证）#

将 zk_request_latency_bucket 阈值从 200ms 调整到 100ms，观察告警触发与抑制。
模拟节点下线（systemctl stop zookeeper），验证 ZK_Quorum_Lost_P0 是否触发。
调整 group_interval，观察告警收敛是否降低重复通知。
编写脚本统计 stat 中 Latency，每分钟输出到日志并对比Prometheus告警。

通过分级策略与可执行规则、命令与排错流程，可建立可操作的ZooKeeper监控告警体系。