11.9.8 监控数据保留与容量规划

在 ZooKeeper 监控体系中，监控数据保留与容量规划需要结合业务重要性、合规要求与成本控制，确定指标采集粒度、保留周期、压缩策略与存储规模。ZooKeeper 本身不存储监控数据，容量规划以 Prometheus/TSDB、日志与告警历史为核心，同时评估四字命令与 JMX 指标的采集频率对性能的影响。

一、原理草图：监控数据流与存储分层

二、采集粒度与保留策略（含示例）
- 实时告警指标（延迟、连接数、堆内存、请求数）：建议 15s–30s 采集，保留 7–30 天
- 运营与容量趋势指标（节点数、watch 数、平均延迟）：可 1–5 分钟采集，保留 90–180 天
- 关键变更记录（版本、配置、角色切换）：以事件日志形式保留 180 天以上
- 合规要求：按行业标准执行（如 180–365 天）

示例：Prometheus 采集与保留配置
文件：/etc/prometheus/prometheus.yml

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'zookeeper'
    metrics_path: /metrics
    static_configs:
      - targets:
        - 10.0.0.11:7000
        - 10.0.0.12:7000
        - 10.0.0.13:7000

Prometheus 启动参数（保留 30 天，TSDB 路径）：

prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --storage.tsdb.retention.time=30d \
  --web.listen-address=0.0.0.0:9090

命令解释
- --storage.tsdb.retention.time=30d：控制数据保留周期
- --storage.tsdb.path：TSDB 数据目录，容量规划依据此目录大小

三、指标裁剪与降采样（含脚本示例）
- 仅保留有告警意义或趋势价值的指标，避免全量 JMX 指标
- 对历史长周期数据降采样（如 5m/1h）
- 对高基数标签（如客户端 IP、会话 ID）进行限制或去标签化

示例：限制高基数标签（Prometheus relabel）

scrape_configs:
  - job_name: 'zookeeper'
    static_configs:
      - targets: ['10.0.0.11:7000']
    metric_relabel_configs:
      - source_labels: [client_ip]
        action: labeldrop

四、Prometheus/TSDB 存储容量估算（含命令与计算）
估算公式（经验值）：
容量 ≈ 指标序列数 × (86400/采样间隔秒) × 保留天数 × 2 bytes
示例：
- 3 节点、每节点 300 条指标、采样 15s、保留 30 天
- 指标序列数 = 900
- 容量 ≈ 900 × (86400/15) × 30 × 2 bytes ≈ 31 GB
- 加上索引与 WAL，按 2–3 倍预留 60–90 GB

示例：查看当前 TSDB 大小

du -sh /var/lib/prometheus

五、存储与性能建议（含安装与分盘示例）
- Prometheus 本地盘：SSD 优先，预留 2–3 倍扩展空间
- 远程存储：对接 Thanos/Cortex 提升长期存储与多副本能力
- WAL 与 TSDB 分盘，避免写放大
- 定期清理告警历史与无效序列

示例：WAL/TSDB 分盘挂载

mkdir -p /data/prometheus /data/prometheus_wal
mount /dev/nvme1n1 /data/prometheus
mount /dev/nvme2n1 /data/prometheus_wal

Prometheus 配置（WAL 分离）：

prometheus \
  --storage.tsdb.path=/data/prometheus \
  --storage.tsdb.wal-compression \
  --storage.tsdb.retention.time=30d

六、ZooKeeper 相关日志容量规划（含配置与命令）
- 事务日志（txn log）：1–3 天
- 快照（snapshot）：保留 3–5 份
- 运维操作日志：集中到日志平台，保留 90 天以上

示例：配置自动清理 txn log 与 snapshot
文件：/opt/zookeeper/conf/zoo.cfg

autopurge.snapRetainCount=5
autopurge.purgeInterval=1

命令解释
- autopurge.snapRetainCount=5：保留 5 份快照
- autopurge.purgeInterval=1：每天清理一次

七、安装示例：ZK JMX Exporter

# 1) 下载 JMX Exporter
wget -O /opt/jmx_exporter/jmx_prometheus_javaagent.jar \
  https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.20.0/jmx_prometheus_javaagent-0.20.0.jar

# 2) 配置 jmx_exporter
cat >/opt/jmx_exporter/zookeeper.yml <<'EOF'
startDelaySeconds: 0
hostPort: 127.0.0.1:2181
rules:
  - pattern: "org.apache.ZooKeeperService<name0=ReplicatedServer_id(\\d+), name1=replica.(\\d+)><>(\\w+)"
EOF

# 3) 在 ZooKeeper JVM 中加载
export JVMFLAGS="$JVMFLAGS -javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent.jar=7000:/opt/jmx_exporter/zookeeper.yml"

预期效果
- curl http://127.0.0.1:7000/metrics 输出 ZooKeeper 指标
- Prometheus 中出现 job=zookeeper 的时间序列

八、常见故障与排错（含命令）
1) Prometheus 磁盘满

df -h /var/lib/prometheus

处理：缩短保留期或清理历史数据

# 临时缩短保留期
# 重启 Prometheus 并设置更短保留时间

2) 指标缺失或采集失败

curl -s http://10.0.0.11:7000/metrics | head

处理：检查 exporter 端口、Prometheus target 状态

# 访问 Prometheus Targets 页面
# http://prometheus:9090/targets

3) 高基数导致内存暴涨

# 检查目标序列数
curl -s http://prometheus:9090/api/v1/status/tsdb | jq '.data.seriesCount'

处理：使用 metric_relabel_configs 去除高基数标签

九、练习与验证
1) 计算容量：假设 5 节点、每节点 400 指标、采样 30s、保留 60 天，估算容量
2) 配置保留策略：将 Prometheus 保留时间从 30d 调整为 15d
3) 验证采集：执行 curl http://<zk_host>:7000/metrics，确认指标字段存在
4) 故障模拟：停止一个 exporter，观察 Prometheus target 状态并恢复

通过控制采集粒度、指标基数与保留周期，可在保障告警及时性与长期趋势分析的同时，降低监控平台存储压力与成本。