别让旧告警毁了新系统：Zabbix/CloudWatch 迁移至 Prometheus 的避坑指南
在企业运维架构从传统的虚拟机模式向云原生/容器化演进的过程中，监控系统的迁移是绕不开的一环。许多团队在从 Zabbix 或 AWS CloudWatch 迁移到 Prometheus + Alertmanager 时，往往会习惯性地将旧系统的规则“逐条翻译”过去。
这种做法极其危险。它不仅无法发挥 Prometheus 的性能优势，反而会产生大量的“配置垃圾”，导致严重的告警风暴。
一、 核心误区：复制而非映射
Zabbix 等传统工具大多基于**主机（Host-based）和检查（Check-based）**逻辑。它的思维模式是：“这台服务器的 CPU 是否超过 90%？”
而 Prometheus 是基于**指标（Metric-based）和多维标签（Multi-dimensional labels）**的。它的思维模式应该是：“当前服务集群的 P99 延迟是否影响了 SLO（服务水平目标）？”
**“映射而非复制”**意味着：你不需要在 Prometheus 中为 1000 台机器配置 1000 个告警规则，而应该通过一条 PromQL 聚合出集群层面的异常。
二、 基于业务意图重新设计 SLI
在迁移时，旧系统的告警规则清单应仅作为“需求参考源”。你需要基于新的 SLO（Service Level Objectives）重新设计你的 SLI（Service Level Indicators）。
1. 从“存活检查”到“成功率监控”
旧系统可能在扫描进程是否存在，而在 Prometheus 中，我们优先使用 probe_success（通过 Blackbox Exporter）或业务暴露的 HTTP 请求速率。
- 错误做法： 翻译 Zabbix 的
proc.num[httpd]。 - 正确做法： 使用
rate计算请求成功率。# 计算过去5分钟内非5xx请求的占比 sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m])) < 0.99
2. 从“静态阈值”到“分位数（Quantile）”
不要简单地监控延迟均值。均值会掩盖掉极端的长尾请求。
- 技术进阶： 使用
histogram_quantile计算 P99 延迟。# 监控 99% 的请求是否在 500ms 内完成 histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))) > 0.5
三、 告警治理：Alertmanager 的艺术
Prometheus 负责生成告警（Firing），但如何发送、发给谁、怎么降噪，则全靠 Alertmanager。这是许多迁移团队最容易忽略的部分。
1. 路由（Routing）与分组（Grouping）
在 Zabbix 中，一个主机宕机可能会发 100 封邮件。在 Alertmanager 中，利用 group_by 可以将同一集群、同一类型的告警合并为一条通知。
route:
group_by: ['alertname', 'cluster', 'service']
group_wait: 30s
group_interval: 5m
2. 抑制（Inhibition）
这是解决告警风暴的神器。例如：当数据中心（DataCenter）级别的网络故障发生时，自动抑制掉该机房内所有主机的 CPU/内存告警。
- 场景映射： 如果
DatacenterDown正在报警，则不发送HostDown。
3. 静默（Silences）
针对已知的维护任务，通过 API 或 Web UI 预设静默，而不是去修改 Prometheus 的 Rule 文件。
四、 避坑清单
- 标签膨胀： 不要把变化的 ID（如 UserID）放入 Label，这会导致时间序列爆炸（Cardinality Explosion），拖垮 Prometheus。
- 数据精度： Zabbix 习惯于分钟级采样，Prometheus 可以做到秒级，但告警规则的
for参数（持续时间）要根据采样周期合理设置，避免由于毛刺导致的误报。 - 配置文件管理： 抛弃手动修改。推荐使用 Prometheus Operator（针对 K8s）或通过 CI/CD 自动校验并重载规则。
总结
从旧系统向 Prometheus 迁移，不是一次简单的“搬家”，而是一次监控哲学的升级。
记住：旧规则是你的需求草稿，而 PromQL 和多维标签才是你构建现代化观测平台的武器。 只有真正理解了业务的意图，才能写出既不漏报、也不吵闹的高质量告警。