Alertmanager 够用吗？一张表判断是否需要 On-call 平台

团队只有一个、Prometheus 实例不多、告警发到一个群就有人处理时，Alertmanager 已经够用。一旦出现多个监控源，需要排班和自动升级，或要统计 MTTA，就应在 Alertmanager 之后接入 On-call 平台。Alertmanager 本身无须替换。

Alertmanager 负责告警路由：哪条告警、在什么条件下、发给哪个 receiver。On-call 平台负责故障响应：谁在值班、谁认领了故障、无人响应时怎么办。它还要记录处理时间线，并让管理者看到响应指标。本文先给出对比表和判断清单，再展开五个边界，最后说明接入方法。

一张表看清边界

维度	Alertmanager	专业 On-call 平台
多源接入	以 Prometheus 为主，其余靠 Webhook 自行适配	原生对接多套监控、云监控、日志、APM 等告警源
值班排班	无人员模型，通知目标写死在 receiver	值班表轮换，支持主备、白夜班、临时调班、公平轮换
自动升级	无；未响应只能靠人盯	未认领/未关闭按时间自动升级到备值班或负责人
告警降噪	分组、静默、抑制（停留在告警层）	降噪结果落到故障对象，叠加智能聚合、风暴预警、抖动检测
协同与认领	群消息通知，状态无法管理	控制台/IM/语音电话认领，完整故障时间线
移动端	依赖 IM 机器人消息，操作要回到电脑	App 推送 + 移动端直接认领、评论、关闭
数据化管理	配置即文档，无响应指标	MTTA/MTTR、响应比例、中断次数、人员负载看板
成本与定位	开源、零授权费，定位是告警聚合	SaaS，有免费套餐，定位是故障响应管理

这张表不用于比较强弱。需求落在右列时，把逻辑继续塞进 Alertmanager 配置文件，往往并不省事。

Alertmanager 够用的情况

满足以下条件时，可以继续优先使用 Alertmanager：

只有少数 Prometheus 实例和少量告警规则。
告警接收人基本固定，不需要复杂的值班表。
告警到达后，团队能在同一个群里快速响应。
不需要主备值班、自动升级、电话短信补位。
不需要跨团队协作、工单同步、状态页或复盘。
不需要按团队、人员、服务统计 MTTA、MTTR 和响应投入。
Alertmanager 配置由少数人维护，复杂度可控。

这种情况下，配好 Alertmanager，保持标签规范和规则质量，比过早引入新平台更实际。

应该引入 On-call 平台的信号

出现以下信号时，应评估专业 On-call 平台：

告警来源不止 Prometheus，还有 Zabbix、Nightingale、Grafana、云监控、日志、APM 或自研系统。
多个团队共用一套 Alertmanager 配置，路由和 receiver 越来越难维护。
告警经常进群，但没有明确的认领人。
关键告警需要电话、短信、App、IM 多渠道触达。
值班表靠 Excel、群公告或人工记忆维护。
主值班未响应时，需要自动升级给备值班或负责人。
告警风暴时，值班人员收到大量重复通知。
需要统计 MTTA、MTTR、响应比例、中断次数和人员负载。
故障结束后需要时间线、复盘、工单或审计记录。

这时继续把逻辑塞进 Alertmanager，响应机制会变成配置文件中的隐性流程。维护成本和事故风险都会上升。更稳妥的做法是保留 Prometheus 和 Alertmanager。On-call 响应交给专门的平台处理。

Alertmanager 擅长的五件事

Alertmanager 是 Prometheus 告警体系中的标准组件。它接收 Prometheus 发出的告警，完成以下处理：

去重：多个 Prometheus 实例或多条相同告警不会无限重复通知。
分组：相似告警合并为一条通知。例如同一集群中大量实例无法访问数据库时，按 cluster、alertname 等标签分组。
路由：通过路由树（routing tree），把不同标签、严重程度和业务的告警发给不同的 receiver。
静默：维护窗口、已知问题或暂不需要通知的告警，通过 silence 在指定时间内停止通知。
抑制：更高层级的故障发生时，抑制一批派生告警。例如整个集群不可达时，抑制集群内其他服务的连通性告警。

开源方案中，常与 Alertmanager 对比的是 Zabbix。Zabbix 内置的 PROBLEM 管理完成度很高。通过 Trigger Action 可以按事件属性过滤，把不同事件发给不同的人，还支持多环节升级和认领。只使用 Zabbix 的公司，靠它内置的告警管理就能解决大部分问题。不过，Zabbix 的体系相对封闭，不擅长作为多个监控系统的统一入口。

Alertmanager 从设计之初就不只服务于 Prometheus，它提供统一的告警接收接口。但它没有人员信息，无法排班、认领、升级或协同评论。它更像告警链路中的中间组件，而非公司级的 On-call 平台。

两者都不是专为故障响应设计的。这正是下面五个边界讨论的问题。

五个边界

边界一：从 receiver 到值班表

Alertmanager 的 route 最终把告警发给 receiver，例如邮件、Webhook、PagerDuty、Opsgenie 或 Slack。但 On-call 最关心的是“此刻应该通知谁”，这不是一份静态名单。

同一个服务，工作日白天可能通知研发值班，夜间通知 SRE 主备值班，周末通知专项值班组。关键业务可能要求主备同时在岗。有人请假时需要临时调班，轮换还要尽量公平。

Flashduty 的值班表把故障和人连接起来。值班规则支持按小时、天、周、月轮换。白班/夜班、主备值班、日期掩码、临时调班和公平轮换都能配置。分派策略可以通知值班表中的当前值班人员，也可以只通知主值班或备值班。这样，“今天谁负责”就无须写死在 receiver 中。

边界二：从发送通知到自动升级

告警发出去，不等于有人响应。最危险的情况是告警已发出却无人认领。群里有人看见，都以为别人会处理，故障就被拖延了。

Flashduty 的分派策略可以配置触发条件、通知对象、通知方式、延迟窗口、通知模板和升级规则。升级条件支持“未关闭”和“未关闭且未认领”，到时自动升级到下一环节。通知对象可以是值班表、团队或个人，也可以组合。通知方式包括电话、短信、邮件、App 推送、IM 私聊和群聊。

例如，severity=critical 的支付告警可以按以下规则处理：

先通知支付 SRE 主值班。
10 分钟未认领，升级给备值班。
30 分钟未关闭，升级给支付研发负责人。
级别较低的 Warning 只进入 IM 群，不触发电话。

这类策略全部写在 Alertmanager 配置中，很快会变成一组难以审计的 YAML 约定。放到 On-call 平台中，分派、通知、认领和升级会进入同一条可追踪的链路。

边界三：从 alert 到 incident

Alertmanager 处理的是告警（alert），On-call 平台处理的是故障（incident）。

一次真实故障往往包含多条告警。先是接口错误率升高，随后数据库连接池耗尽，再出现服务不可用，最后还有恢复通知。值班人员要处理的是“支付服务不可用”这一个故障，而非逐条处理告警。

在 Flashduty 中，监控系统推送的原始通知称为事件，事件触发告警，相似告警聚合为故障。故障是主要的处理对象，可以分派、通知、认领、暂缓、关闭、合并和复盘。降噪发生在“告警到故障”这一层，具体做法见告警降噪文档。

Alertmanager 也有分组、静默和抑制。区别在于，On-call 平台把降噪结果落到故障上。后续的分派、认领、升级、时间线和指标都围绕故障展开。

边界四：从群消息到可操作的协作

很多团队把 Alertmanager 告警发到飞书、钉钉、企业微信或 Slack 群。这一步很容易实现，也很容易失控。群消息能通知，却难以管理状态。消息被刷走后，没人知道是否有人处理。有人回复“我看下”，系统中却没有认领状态。

Flashduty 的故障可以在控制台、IM 应用消息和语音电话中认领。语音播报结束时，按键即可认领。IM 消息卡片提供认领、关闭等操作。故障详情页记录时间线，包括触发、分派、通知、认领、暂缓、关闭和评论。

故障响应要回答的不只是“谁收到了消息”。还要回答谁接手了、当前状态如何、下一步由谁负责、是否升级过、事后能否回溯。

边界五：从配置文件到数据化管理

Alertmanager 配置说明了告警如何路由，但无法说明团队的响应效率是否在改善。SRE 负责人通常需要以下数据：

本月产生了多少故障？
哪些服务、团队或协作空间告警最多？
MTTA 和 MTTR 是多少？
哪些故障没有被认领？
哪些人员被短信、电话、App 推送打断最多？
告警集中在工作时间、休息时间还是睡眠时间？
哪些告警检查项和告警对象最频繁？

Flashduty 的分析看板可按团队、协作空间、个人等维度查看故障数据。指标包括平均认领时间（MTTA）、平均恢复时间（MTTR）、响应比例、响应投入和中断次数。时间可拆分为工作、休息和睡眠时段。全局维度可查看告警检查项和告警对象 TOP 20，并支持 CSV 导出。

有了数据，团队就能明确应优化哪条规则、哪个服务和哪个值班策略。也能看清哪些告警消耗了最多的响应时间。

把 Alertmanager 接入 Flashduty

接入方式是 Alertmanager 通过 Webhook receiver 推送告警。该集成适配 Alertmanager 0.16.0 及以上版本。

在 Flashduty 中创建 Prometheus 集成，获取推送地址。然后在 Alertmanager 的 receivers 中增加 Webhook 配置：

receivers:
- name: 'flashcat'
  webhook_configs:
  - url: '<您的集成推送地址>'
    send_resolved: true

如果希望 Alertmanager 默认把告警发到 Flashduty，可以在 route 中指定 receiver：

route:
  receiver: 'flashcat'

为了不影响已有的通知渠道，可以把 Flashduty receiver 放到子路由中。先选一部分服务或告警级别试运行。

Flashduty 支持专属集成和共享集成。专属集成把告警直接投递到某个协作空间。共享集成根据 Payload 配置路由规则，把不同告警投递到不同的协作空间。

Prometheus 告警的 severity 等标签会映射为 Flashduty 的严重程度，例如 critical 映射为 Critical。完整的映射规则见 Prometheus 集成文档。

接入后，团队无须替换 Prometheus，也无须放弃 Alertmanager。Alertmanager 作为上游告警源，Flashduty 承接后续的响应。

用 14 天试用验证

评估 On-call 平台，不应只看功能表。用真实的 Prometheus 告警跑一遍更有价值：

选择一个业务服务，接入 Alertmanager Webhook。
确认 Critical、Warning、Info 等级别映射正确。
为该服务创建协作空间和值班表。
配置分派策略：Critical 用电话或短信，Warning 只进 IM。
配置未认领升级：例如 10 分钟未认领，升级给备值班。
开启规则聚合或智能聚合，观察重复告警是否合入同一故障。
触发一条测试告警，验证 IM、电话、短信、App 的触达。
在 IM 或控制台认领、暂缓、关闭故障。
查看故障时间线，确认通知、认领、关闭都有完整记录。
在分析看板中查看故障数量、MTTA、MTTR、响应比例和中断次数。

十步都能跑通，团队就能判断 Alertmanager 是否够用。对小团队，Alertmanager 可能就是最合适的方案。对多团队、7×24 值班、关键业务和复杂通知场景，On-call 平台更合适。

如需开始试用，可以保留 Prometheus 和 Alertmanager，把告警接入 Flashduty 控制台。

参考资料

Prometheus Alertmanager 文档：去重、分组、路由、静默、抑制和高可用。
Prometheus 告警概述：Prometheus 告警规则与 Alertmanager 的分工。
Flashduty Prometheus 告警集成：把 Alertmanager Webhook 接入 Flashduty。
Flashduty 告警降噪：事件、告警与故障模型，以及聚合、风暴预警、抖动检测、静默和抑制。
Flashduty 分派策略：值班表、通知方式、延迟窗口、升级规则和主备值班。
Flashduty 分析看板：MTTA、MTTR、响应比例、响应投入、中断次数和数据导出。