19.5.5 监控数据治理与容量规划

监控数据治理与容量规划的目标是在“数据质量、成本可控、可用性与可检索性”之间找到平衡。关键抓手包括数据分级与生命周期策略、指标命名与标签治理、采集边界与降噪、容量模型与扩容阈值、以及持续的清理与优化闭环。以下以 Prometheus 体系为主线，结合日志与链路数据给出可执行示例。

1. 数据分级与命名规范（示例）#

示例命名与标签规范（文件路径与注释可落地执行）：

# 命名规范示例（metrics.md）
# 1) 指标名称：<系统>_<模块>_<含义>_<单位>
# 2) 标签：固定枚举优先，禁止高基数（user_id/request_id）

# 好例子:
http_server_requests_total{service="order",env="prod",code="200"}

# 坏例子:
http_requests_total{user_id="123456789"}  # 高基数

Prometheus 录入前过滤高基数标签（用 relabel 控制）：

# /etc/prometheus/prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "app"
    static_configs:
      - targets: ["10.0.0.11:9100"]
    metric_relabel_configs:
      # 删除高基数标签
      - action: labeldrop
        regex: "user_id|request_id|trace_id"
      # 只保留明确白名单指标
      - action: keep
        source_labels: [__name__]
        regex: "http_server_requests_total|process_cpu_seconds_total|node_cpu_seconds_total"

预期效果：减少时序膨胀，查询更一致，存储可控。

2. 采集边界与降噪（示例）#

对噪声指标进行采样与聚合：

# 通过 recording rules 降采样与聚合
# /etc/prometheus/rules/recording.yml
groups:
- name: app_agg
  rules:
  - record: job:http_server_requests_rate5m
    expr: sum by (job,code) (rate(http_server_requests_total[5m]))

应用后可在查询中使用 job:http_server_requests_rate5m，减少高频查询成本。

3. 数据质量校验（示例）#

使用 promtool 校验规则：

# 安装（Ubuntu）
sudo apt-get update && sudo apt-get install -y prometheus
promtool --version

# 校验规则文件
promtool check rules /etc/prometheus/rules/recording.yml

预期效果：提前发现语法错误与规则冲突，避免告警失效。

4. 容量规划模型与估算（示例）#

核心估算模型：
容量 ≈ 指标数 × 采集频率 × 保留周期 × 压缩率

示例估算脚本（以 Prometheus TSDB 为例）：

cat <<'EOF' > /opt/ops/capacity_estimate.sh
#!/usr/bin/env bash
# 参数说明:
# metrics: 指标数
# interval: 采集间隔秒
# days: 保留天数
# sample_bytes: 单样本平均字节（Prometheus 常用 1.5~2.0）
metrics=${1:-200000}
interval=${2:-15}
days=${3:-15}
sample_bytes=${4:-1.7}

samples_per_day=$(( 86400 / interval ))
total_samples=$(python3 - <<PY
m=$metrics
s=$samples_per_day
d=$days
print(m*s*d)
PY
)

gb=$(python3 - <<PY
samples=$total_samples
b=$sample_bytes
print(samples*b/1024/1024/1024)
PY
)

echo "预计样本数: $total_samples"
echo "预计存储(GB): $gb"
EOF

chmod +x /opt/ops/capacity_estimate.sh
/opt/ops/capacity_estimate.sh 200000 15 30 1.7

预期效果：快速评估存储需求，指导磁盘与远程存储预算。

5. Prometheus 长短期分层（安装与配置示例）#

使用远程写入（Thanos/Cortex/VM 等）实现冷热分层。

安装 Prometheus（示例）：

# 二进制安装
wget https://github.com/prometheus/prometheus/releases/download/v2.49.1/prometheus-2.49.1.linux-amd64.tar.gz
tar -xf prometheus-2.49.1.linux-amd64.tar.gz
sudo mv prometheus-2.49.1.linux-amd64 /opt/prometheus

# systemd 服务
cat <<'EOF' | sudo tee /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus
After=network.target

[Service]
ExecStart=/opt/prometheus/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/data/prometheus \
  --storage.tsdb.retention.time=15d
Restart=always

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now prometheus

远程写入配置（示例）：

# /etc/prometheus/prometheus.yml
remote_write:
  - url: "http://thanos-receive:19291/api/v1/receive"
    queue_config:
      max_shards: 8
      max_samples_per_send: 10000
      capacity: 50000

预期效果：本地 15 天高精度，远端长期保留。

6. 日志/链路索引治理（示例）#

日志按天分索引，控制索引体量：

# Elasticsearch ILM 策略示例（伪配置）
PUT _ilm/policy/logs_policy
{
  "policy": {
    "phases": {
      "hot":   { "actions": { "rollover": { "max_age": "1d", "max_size": "50gb" } } },
      "warm":  { "actions": { "shrink": { "number_of_shards": 1 } } },
      "delete":{ "min_age": "30d", "actions": { "delete": {} } }
    }
  }
}

预期效果：控制索引增长与检索成本。

7. 容量与成本可视化指标（PromQL 示例）#

# 活跃时序量
count({__name__=~".+"})

# 写入速率（近5分钟）
rate(prometheus_tsdb_head_samples_appended_total[5m])

# 存储增长
prometheus_tsdb_head_series

8. 排错与巡检要点（示例）#

常见问题与排查命令：

# 1) 采集失败
curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[]|{job:.labels.job,health:.health,lastError:.lastError}'

# 2) TSDB 块异常
ls -lh /data/prometheus
# 查看 WAL 大小
du -sh /data/prometheus/wal

# 3) 查询过慢
# 使用 Prometheus 自带查询分析
curl -G 'http://localhost:9090/api/v1/query' \
  --data-urlencode 'query=topk(5,rate(prometheus_engine_query_duration_seconds_sum[5m]))'

排查思路：定位采集失败、WAL 爆涨、慢查询规则与高基数标签。

9. 练习（可操作）#

1) 在测试环境中加入一个高基数标签，观察活跃时序变化，并用 labeldrop 修复。
2) 将采集间隔从 15s 调整为 30s，重新估算容量并对比变化。
3) 为业务 HTTP 请求量编写 recording rule 并验证查询性能改善。
4) 编写定期清理策略，将 7 天无访问的告警规则/指标标记为待下线。

通过数据治理与容量规划的持续闭环（指标规范 → 采集治理 → 容量估算 → 成本控制 → 定期清理），可以保证可观测性体系在业务增长中长期稳定与可持续。