Prometheus 用户很容易先从 Alertmanager 开始做告警通知。
这是合理的。Alertmanager 是 Prometheus 告警体系里的标准组件，负责接收 Prometheus 发出的告警，并完成去重、分组、路由、静默、抑制和通知发送。对于单团队、规则清晰、通知链路不复杂的场景，Alertmanager 已经能解决很多问题。
但 Alertmanager 不是完整的 On-call 平台。
它更像告警通知链路中的调度器：把什么告警，在什么条件下，发给哪个 receiver。专业 On-call 平台要解决的是另一组问题：谁正在值班，谁认领了故障，没人响应怎么办，处理过程有没有时间线，管理者能不能看到 MTTA、MTTR、响应比例和人员负载。
所以问题不是“Alertmanager 好不好”，而是：团队的问题到底停留在告警路由，还是已经进入故障响应管理。
Alertmanager 适合解决什么问题
Alertmanager 的核心能力可以概括为五类。
第一，去重。多个 Prometheus 实例或多个相同告警不会无限重复通知。
第二，分组。相似告警可以合并到一个通知里。例如同一个集群里大量实例同时无法访问数据库时，可以按 cluster、alertname 等标签分组，减少通知数量。
第三，路由。Alertmanager 使用 routing tree，把不同标签、不同严重程度、不同业务的告警发送到不同 receiver。
第四，静默。维护窗口、已知问题或临时不需要通知的告警，可以通过 silence 在指定时间内停止通知。
第五，抑制。某个更高层级故障已经发生时，可以抑制一批派生告警。例如整个集群不可达时，抑制该集群内其他服务的连通性告警。
这些能力非常实用。
如果你的团队只有一个 SRE 小组，Prometheus 规则数量不多，告警标签规范比较统一，通知目标也相对固定，那么 Alertmanager 可能已经够用。
什么时候 Alertmanager 会开始吃力
问题通常不是从第一天出现的。
一开始，团队可能只有几十条告警规则，一个默认 receiver，一个 IM 群，几条 silence。Alertmanager 配置很清楚，大家也知道告警来了该找谁。
随着业务增长，情况会变复杂：
- 一个 Prometheus 变成多个 Prometheus。
- 一个团队变成多个业务团队。
- 一个 IM 群变成多个群、多个负责人、多个通知策略。
- 告警从基础设施扩展到应用、数据库、中间件、Kubernetes、云服务。
- 告警处理从“有人看一眼”变成“必须有值班、升级、复盘和指标”。
这时候 Alertmanager 仍然能路由告警，但它不负责完整响应流程。
它不会天然回答这些问题：
今天晚上谁值班？
主值班没响应时，什么时候升级给备值班？
这个故障是否已经被认领？
值班人暂缓处理后，是否还应该继续升级？
故障过程里通知了谁，通知是否成功？
本月哪个服务产生了最多告警噪音？
哪个团队 MTTA 变长了？
哪些告警经常在睡眠时间打断值班人？
如果这些问题开始影响团队效率，就说明告警系统已经不只是“通知配置”问题，而是 On-call 机制问题。
边界一：从 receiver 到值班表
Alertmanager 的 route 最终会把告警发送到 receiver。receiver 可以是邮件、Webhook、PagerDuty、Opsgenie、Slack 等通知目标。
但 On-call 里真正重要的是“当前应该通知谁”。
这不是一个静态名单。
同一个服务在工作日白天可能通知研发值班，夜间通知 SRE 主备值班，周末通知专项值班组。关键业务可能需要主值班和备值班同时在岗。有人请假时，还要临时调班。轮换还要尽量公平，避免某个人长期在周末或夜间值班。
Flashduty 的值班表用于把故障和人连接起来。值班规则支持按小时、天、周、月轮换，支持白班/夜班、主备值班、日期掩码、临时调班和公平轮换。分派策略可以把故障通知给值班表里的当前值班人，也可以按角色只通知主值班或备值班。
这类能力不是为了把配置做复杂，而是为了让团队不用把“谁今天负责”写死在 Alertmanager receiver 里。
边界二：从通知发送到自动升级
Alertmanager 可以把告警发出去。
但发出去不等于有人响应。
真实故障里，最危险的情况不是没有告警，而是告警已经发了，但没有人认领。群里有人看见，有人以为别人会处理，最后故障被拖住。
专业 On-call 平台需要把响应动作显式化。
Flashduty 的分派策略可以配置触发条件、通知对象、通知方式、延迟窗口、通知模板和升级规则。升级条件支持“未关闭”和“未关闭且未认领”，可以在指定时间后自动升级到下一环节。通知对象可以是值班表、团队、个人，也可以组合使用。通知方式支持电话、短信、邮件、App 推送、IM 私聊和群聊。
这解决的是一个核心问题：关键故障不能只依赖“大家应该会看到”。
例如：
severity=critical 的支付告警，先通知支付 SRE 主值班；10 分钟未认领，升级给备值班；30 分钟未关闭，升级给支付研发负责人；低级别 Warning 只进入 IM 群，不触发电话。
这类策略如果全部放在 Alertmanager 配置里维护，很快会变成一组难以审计的 YAML 约定。放到 On-call 平台里，分派、通知、认领和升级会进入同一条可追踪链路。
边界三：从 alert 到 incident
Alertmanager 处理的是 alert。
On-call 平台处理的是 incident。
这个差异很关键。
一个真实故障往往不是一条告警。可能先出现接口错误率升高，随后数据库连接池耗尽，再出现服务不可用，最后还有恢复通知。值班人需要处理的是“支付服务不可用”这个故障，而不是逐条处理每个告警事件。
Flashduty 把监控系统推送过来的原始通知称为事件，事件触发告警，相似告警可以聚合为一条故障。故障是主要处理对象，可以被分派、通知、认领、暂缓、关闭、合并和复盘。
告警降噪发生在“告警到故障”这一层。
Flashduty 支持规则聚合和智能聚合。规则聚合按指定标签或属性精确匹配；智能聚合基于标题、描述、labels.service、labels.resource 等字段计算相似度。后续告警合入已有故障后，不会重复触发通知。
此外，Flashduty 还支持风暴预警、抖动检测、静默策略和抑制策略。抖动检测可以识别同一故障频繁触发和恢复，并按配置减少通知干扰。延迟窗口可以在首次通知前等待一段时间，如果故障自动恢复，就不再通知。
Alertmanager 也有分组、静默和抑制能力。区别在于，专业 On-call 平台会把降噪结果落到故障对象上，后续围绕故障继续做分派、认领、升级、时间线和指标统计。
边界四：从群消息到可操作协同
很多团队把 Alertmanager 告警发到飞书、钉钉、企业微信或 Slack 群里。
这一步很容易做，但也很容易失控。
群消息的问题是：它能通知，但很难管理状态。消息被刷掉后，没人知道有没有人处理；有人回复“我看下”，但系统里不一定有认领状态；故障恢复后，过程也不一定留下完整记录。
Flashduty 的故障可以在控制台、IM 应用消息和语音电话中被认领。语音告警播报结束时，可以通过按键认领。IM 应用消息卡片可以提供认领、关闭等操作。故障详情页会记录时间线，包括触发、分派、通知、认领、暂缓、关闭、评论等动作。
这对故障协同很重要。
因为故障响应不只是“谁收到了消息”，还要回答“谁接手了、现在是什么状态、下一步由谁负责、有没有升级、事后能不能回溯”。
边界五：从配置文件到数据化管理
Alertmanager 配置可以告诉你告警怎么路由。
它很难直接告诉你团队响应效率是否变好了。
SRE 负责人通常需要看这些指标：
- 本月产生了多少故障？
- 哪些服务、团队或协作空间告警最多？
- MTTA 和 MTTR 是多少？
- 哪些故障没有被认领？
- 哪些人员被短信、电话、App 推送打断最多？
- 告警集中发生在工作时间、休息时间还是睡眠时间？
- 哪些告警检查项和告警对象最频繁？
Flashduty 的分析看板支持按团队、协作空间、个人等维度查看故障数据，支持 MTTA、MTTR、响应比例、响应投入、中断次数等指标。时间维度可以拆分为工作时间、休息时间和睡眠时间。全局维度可以查看告警检查项和告警对象 TOP 20，并支持数据下载和 CSV 导出。
这类数据对管理者很关键。
没有数据时，告警治理只能靠体感。
有数据后，团队可以明确知道应该优化哪条规则、哪个服务、哪个值班策略，以及哪些告警正在消耗最多响应时间。
什么情况下 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 接入 Flashduty
接入路径很直接：Alertmanager 通过 Webhook receiver 把告警推送到 Flashduty。
Flashduty 支持 Prometheus 告警集成，适配 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 告警等级也会被映射到 Flashduty 的严重程度。系统会依次提取告警事件标签中的 severity、priority 和 level。例如 critical 映射为 Critical，warning 或 warn 映射为 Warning，info 映射为 Info，ok 映射为 Ok。
这意味着团队不需要替换 Prometheus，也不需要放弃 Alertmanager。先把 Alertmanager 作为上游告警源，接入 Flashduty 做响应闭环即可。
14 天试用应该验证什么
评估 On-call 平台，不建议只看功能表。
用真实 Prometheus 告警跑一次更有价值。
可以按这个顺序验证：
- 选择一个业务服务，接入 Alertmanager Webhook。
- 确认 Critical、Warning、Info 等告警等级是否正确映射。
- 为该服务创建协作空间和值班表。
- 配置分派策略：Critical 电话或短信，Warning 只进 IM。
- 配置未认领升级：例如 10 分钟未认领升级给备值班。
- 开启规则聚合或智能聚合，观察重复告警是否合入同一故障。
- 触发一条测试告警，验证 IM、电话、短信、App 的触达路径。
- 在 IM 或控制台认领、暂缓、关闭故障。
- 查看故障时间线，确认通知、认领、关闭动作是否完整记录。
- 观察分析看板里的故障数量、MTTA、MTTR、响应比例和中断次数。
如果这十步能跑通，团队就能清楚判断：Alertmanager 是否已经够用，还是需要把响应流程交给专业 On-call 平台。
结论：不要替换 Alertmanager，要补齐响应闭环
Prometheus Alertmanager 是优秀的告警路由组件，不应该被简单替代。
它适合做告警分组、路由、静默、抑制和通知发送。真正需要补齐的是 Alertmanager 之后的响应链路：值班、分派、升级、认领、协同、时间线、分析和复盘。
对于小团队，Alertmanager 可能就是最合适的方案。
对于多团队、7x24 值班、关键业务、复杂通知和数据化管理场景，专业 On-call 平台会更合适。
最稳妥的判断方式不是争论工具边界，而是拿一组真实告警试 14 天。
保留 Prometheus 和 Alertmanager。
把告警接入 Flashduty。
让团队跑完一次从告警触发、通知、认领、升级、处理到数据分析的完整流程。
资料依据：
- Prometheus Alertmanager 官方文档：去重、分组、路由、静默、抑制和 HA。https://prometheus.io/docs/alerting/latest/alertmanager/
- Prometheus Alerting overview：Prometheus 告警规则与 Alertmanager 的职责边界。https://prometheus.io/docs/alerting/latest/overview/
- Flashduty Prometheus 告警集成：通过 Alertmanager Webhook 接入 Flashduty。https://docs.flashcat.cloud/zh/on-call/integration/alert-integration/alert-sources/prometheus
- Flashduty 告警降噪：事件、告警、故障模型，聚合、风暴预警、抖动检测、静默和抑制。https://docs.flashcat.cloud/zh/on-call/channel/noise-reduction
- Flashduty 分派策略和值班管理：值班表、通知方式、延迟窗口、升级规则和主备值班。https://docs.flashcat.cloud/zh/on-call/channel/escalation-rule
- Flashduty 分析看板：MTTA、MTTR、响应比例、响应投入、中断次数和数据导出。https://docs.flashcat.cloud/zh/on-call/analytics/insights
