迁移避坑：从 Zabbix/CloudWatch 到 Prometheus 的告警规则重构之道

在监控系统迁移中，最常见也最致命的错误是：直接把旧系统的阈值规则复制到新平台。这种“复制粘贴”思维往往导致告警泛滥、疲劳，甚至掩盖真实问题。本文基于多次实战迁移经验，总结核心原则与落地步骤，帮助你避开陷阱，实现告警体系的平滑升级。

为什么“映射而非复制”是生死线？

Zabbix 和 CloudWatch 的告警模型与 Prometheus + Alertmanager 有本质差异：

• 指标模型不同：Zabbix/CloudWatch 通常是数值型指标（如 CPU 使用率），而 Prometheus 是多维时间序列，告警需基于 rate()、histogram_quantile() 等函数计算 SLI（服务等级指标）。
• 拉取 vs 推送：Prometheus 主动拉取，告警规则需考虑 scrape 失败、目标 down 等情况，旧规则可能忽略这些。
• 告警处理分离：Alertmanager 负责分组、抑制、路由，旧系统往往内置简单路由，需重新设计流程。

因此，旧规则清单应作为 “需求参考源” —— 它告诉你“业务关心什么”，但不告诉你“在新体系下如何实现”。

第一步：基于 SLO 重新设计告警规则

1. 梳理业务 SLO
   与业务方对齐关键目标，例如：

   • 服务可用性 99.9%
   • P99 延迟 < 200ms
   • 错误率 < 0.1%

2. 定义 SLI 与 PromQL 映射

   • 可用性：使用 probe_success（黑盒监控）或 up（目标健康）

     sum(up{job="your_service"}) / count(up{job="your_service"}) < 0.999
     

   • 延迟：基于 http_request_duration_seconds（Histogram 指标）

     histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, job))
     

   • 错误率：基于 http_requests_total 的 code 标签

     sum(rate(http_requests_total{code=~"5..",job="your_service"}[5m])) 
     / 
     sum(rate(http_requests_total{job="your_service"}[5m])) > 0.001
     

3. 编写告警规则（示例）

   groups:
   - name: service_slo
     rules:
     - alert: ServiceHighErrorRate
       expr: |
         sum(rate(http_requests_total{code=~"5..",job="your_service"}[5m])) 
         / 
         sum(rate(http_requests_total{job="your_service"}[5m])) > 0.001
       for: 2m
       labels:
         severity: critical
         service: your_service
       annotations:
         summary: "服务 {{ $labels.service }} 错误率过高"
         description: "错误率 {{ $value }}，持续 2 分钟"
   

第二步：配置 Alertmanager 路由、分组与抑制

告警规则只负责“触发”，Alertmanager 负责“送达”。合理配置可大幅减少噪音。

路由设计（按服务/严重性分组）

route:
  group_by: ['service', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'team-webhook'
  routes:
  - match:
      severity: critical
    receiver: 'critical-pager'
    continue: false
  - match:
      service: database
    receiver: 'dba-team'

抑制规则（避免连锁告警）

例如，当“机房网络中断”时，抑制所有“服务不可达”告警：

inhibit_rules:
- source_match:
    alertname: InstanceDown
  target_match:
    severity: critical
  equal: ['instance']

第三步：旧规则清单的正确使用

1. 提取业务意图：分析旧规则，问“这条规则想保护什么业务指标？”（如“磁盘使用率 >90%”实际是“避免存储耗尽导致服务中断”）。
2. 映射到新指标：在 Prometheus 中找到等效或更优指标（如 node_filesystem_avail_bytes 计算可用空间百分比）。
3. 重新评估阈值：旧阈值可能过时或不适用于新架构（如微服务下“主机 CPU”不再是关键，应关注“服务延迟”）。

常见陷阱与应对

迁移检查清单

• 梳理所有旧告警规则，标注业务意图。
• 定义关键 SLO，并确定对应 SLI 的 PromQL 表达式。
• 编写告警规则，设置合理 for 持续时间和标签。
• 设计 Alertmanager 路由树（按团队、服务、严重性）。
• 配置分组（group_by）和抑制（inhibit_rules）。
• 在非生产环境模拟触发，验证告警链路。
• 并行运行新旧系统 1-2 周，对比告警有效性。
• 根据反馈调整阈值和路由，逐步切换流量。

总结

迁移不是工具替换，而是监控理念的升级：从“监控基础设施”转向“保护业务目标”。牢记“映射而非复制”，以 SLO 为纲，用 PromQL 精确描述 SLI，再通过 Alertmanager 实现智能送达。这样，你的告警系统才能真正成为运维的“哨兵”，而非“噪音发生器”。