技能介绍

告警噪音的工程化解法

Prometheus AlertManager 把原始指标异常转换成告警事件，但当集群规模扩张时，一个微服务抖动就能在短时间内触发几十甚至上百条通知。运维团队常见的痛点是：所有告警都涌进同一个 Slack 频道，值班人员需要人工判断哪些需要立即响应，哪些可以等到第二天复盘。PagerDuty 和 Opsgenie 虽然支持高优先级提醒，但如果缺乏统一的路由策略，要么漏掉关键事件，要么把所有人的手机都变成噪音源。

路由规则与升级链路

这个技能解决的核心问题是把 AlertManager 的静态接收组，替换为基于严重程度和标签匹配器的动态路由逻辑。

具体来说，技能的工作流程如下：

解析告警元数据：从 AlertManager 推送的事件中提取 severity 标签和自定义标签集，作为路由决策的输入。
标签匹配器匹配规则：根据预定义的匹配条件，将告警映射到不同的接收端。例如，severity=critical 的告警可以同时触发 PagerDuty 和 Opsgenie，而 severity=warning 且 team=backend 的告警只发送到对应的 Slack 频道。
多渠道事件升级：当告警满足特定条件时，技能可以同时调用 PagerDuty、Opsgenie 和 Slack webhook API，实现跨平台的并行通知。对于需要人工介入的 Critical 级别事件，可以通过 Opsgenie 的 priority 字段直接指定响应窗口。

关键能力清单：

基于 Prometheus 告警标签的灵活匹配规则，支持 =、=~、!=、!~ 四种操作符。
原生集成 PagerDuty Events API v2、Opsgenie REST API 以及 Slack Incoming Webhooks。
支持按团队、服务、环境等维度拆分接收组，避免告警跨组泄漏。

适用边界与注意点

这个技能不是一个「开箱即用」的告警机器人，它的有效性高度依赖两件事：

AlertManager 的标签体系：如果上游监控没有规范 severity、team、service 等关键标签的取值，路由规则会退化成摆设。
Webhook 的权限配置：Slack webhook 通常绑定单一频道，无法实现基于用户组的精细化投递；PagerDuty 的 Service 需要预先配置 routing key；Opsgenie 需要提前创建 Alert 模板，否则所有事件都会以默认格式发送。

另外，技能只负责「路由」，不负责告警抑制、静默或自动恢复。如果需要基于告警拓扑做根因分析，需要额外引入 alertmanager-webhook 生态中的其他组件。