Prometheus 告警规则构建器

解决什么问题

手写 Prometheus 告警规则时，最常见的痛点是规则写得对不对没人知道。一条 alert: HighCPUUsage 规则里的 PromQL 表达式少一个边界、阈值写反、for 时长配置不当，往往要到告警风暴或该响不响时才会暴露。与此同时，Alertmanager 的路由树配置是另一层负担：route、group_by、continue 这些字段与 receiver 的匹配关系一旦写错，告警就会静默丢失。接入 PagerDuty、Slack、OpsGenie 等通知渠道还要各自维护 receiver 模板，手工拼配置既慢又容易不一致。

核心能力与工作方式

这个技能围绕两条主线工作：

• 告警规则构建：根据监控目标用 PromQL 表达式生成告警规则，覆盖阈值判断、持续时间（for）和标签标签（labels）等要素。
• 规则校验：借助 Prometheus HTTP API 对规则做校验，在规则落盘前暴露语法与逻辑问题，避免把错误配置直接推给线上环境。
• Alertmanager 路由配置：生成路由树结构，处理告警的分组、抑制与分发路径。
• 通知渠道集成：配置 PagerDuty、Slack、OpsGenie 三类 receiver，把不同严重级别的告警送到对应的处理通道。

典型使用流程是：先明确要监控的指标和判定条件，技能据此产出 PromQL 与规则结构；再通过 HTTP API 验证规则的有效性；最后补齐 Alertmanager 的路由与 receiver 配置，形成一条从指标到通知的完整链路。

适用边界与注意点

• 依赖可用的 API 环境：规则校验依赖 Prometheus HTTP API 可达，部署在隔离网络或 API 未开启时校验步骤无法执行。
• 只负责配置，不负责设计监控体系：指标怎么选、阈值怎么定，仍然需要运维人员结合业务判断，技能提供的是规则与路由的生成和校验能力。
• Receiver 集成取决于环境配置：PagerDuty、Slack、OpsGenie 的凭证和端点需要使用者自行在环境中准备好。
• 规则语义需回归验证：通过校验只说明规则结构合法，阈值与持续时间是否贴合实际负载，建议在测试环境做回归观察后再上线。