告警事件 OnCall 平台的选型，本质上是在选择一套“告警事件进入后由谁处理、如何降噪、如何升级、如何协同、如何统计”的工作流。它不是监控系统的替代品，而是监控告警之后的事件响应平台。
核心要点
- 如果公司只有一套 Zabbix，且告警处理主要发生在 Zabbix 内部，Zabbix 自带的 PROBLEM 管理可以覆盖不少基础场景。
- 如果公司有多套监控系统，需要统一接收、分组、抑制和路由告警，Alertmanager 更适合作为中间组件。
- 如果团队需要排班、认领、升级、转派、协同、移动办公和统计分析，专业 OnCall 平台更匹配。
- OnCall 平台选型时，不应只看“能不能发通知”，更要看是否能把告警事件处理闭环。
- Flashduty 的定位是统一告警事件 OnCall 平台，适合多监控系统、多团队、多通知渠道并存的场景。
研发、运维人员在告警处理的时候，可能会经历如下困扰：
- 告警风暴，手机不停地响，打电话都打不出去
- 告警分散在多个平台，因为一个公司通常不止是一套监控系统，可能同时用了 Zabbix、Prometheus、Nightingale、云监控、Grafana、ElastAlert、还有各类商业产品自带的监控等等
- 没法协同，一个重要故障可能需要很多人协作解决，大家可能会拉个群，但是群里的消息很多，很零散，看起来很乱
- 移动办公不方便，告警可能是通过短信、邮件、钉钉机器人消息发出的，如果想评论、认领等，还需要打开电脑、登录 VPN、登录平台，操作起来很麻烦
- 告警容易遗漏，比如晚上睡着了没有听见，或者信号不好，或者手机静音了
这时候，一个好的告警事件 OnCall 平台很有必要，这里我介绍三个方案，两个开源方案一个商业方案，供大家参考。
OnCall 平台选型先看哪些能力
在比较具体产品前，可以先用下面几个问题判断团队到底需要什么：
| 选型问题 | 如果答案是“是” | 说明 |
|---|---|---|
| 是否只有一套监控系统？ | 可以优先评估监控系统内置告警能力 | 系统越少，统一平台诉求越弱 |
| 是否需要统一接入多套监控？ | 需要统一事件入口 | 重点看 webhook、邮件解析、标准化能力 |
| 是否需要值班排班？ | 需要人员和值班体系 | 重点看主备值班、临时调班、公平轮换 |
| 是否需要认领和升级？ | 需要事件闭环 | 重点看自动升级、手动转派、时间线 |
| 是否需要移动端处理？ | 需要 IM 或 App 深度集成 | 重点看认领、关闭、评论是否能在移动端完成 |
方案一：Zabbix 内置 PROBLEM 管理
Zabbix 内置的 PROBLEM 管理其实挺丝滑的，完成度很高，不但支持告警根据条件做分派、方便管理各类通知媒介，还支持 PROBLEM Update、PROBLEM 多环节升级，整体设计还是挺不错的。比如下面这个图，是 Zabbix 的分派规则：
在 Zabbix 里称为 Trigger Action，可以根据告警事件的属性做各种条件过滤，即不同的事件发给不同的人（通过不同的通知媒介），甚至还可以做多环节的升级、认领。如果你们公司就只有 Zabbix 这么一套监控系统，就使用 Zabbix 内置的 PROBLEM 管理也能解决大部分问题了。
但是，Zabbix 体系相对封闭，没法接入其他监控系统的事件，Zabbix 的设计初衷如此，没有办法。所以如果你们公司有多套监控系统，就需要考虑其他方案了。
方案二：Alertmanager
Alertmanager 一开始的设计就不止是针对 Prometheus 的，它就是提供了一个统一的告警事件接收的接口，不同的监控系统都可以把事件推给 Alertmanager，Alertmanager 做统一的告警屏蔽、抑制、分组、分派。即：对事件本身的处理做的比较到位，但是事件的发送设计的比较粗糙，Alertmanager 里没有人员信息，没法做排班、认领、升级、协同评论这类跟人有关的操作。
Alertmanager 更像是一个中间组件，各种的监控系统把告警事件发给 Alertmanager，Alertmanager 做一个初步处理，再投递给 PagerDuty 这样的组件。但是要把 Alertmanager 作为公司级统一的 OnCall 平台，还是不太够。但是开源社区基本也找不到其他方案了，Alertmanager 算是唯一一个稍微有那么点意思的项目了。
方案三：Flashduty
Flashduty 是 SaaS 产品，有免费套餐，专门做告警事件 OnCall 的统一平台，类似国外的 PagerDuty，因为 Flashduty 是面向国内用户的，所以和国内的各类云监控、国内的 IM（比如钉钉、企业微信、飞书等）等都有很好的适配。作为一款统一的 OnCall 平台，Flashduty 主要干了下面这些事：
- 对接各类监控系统，把告警事件统一接收
- 对事件做处理，比如过滤、Enrichment、Relabel 等
- 对事件做分派，支持按照各自条件做分派
- 支持排班管理
- 支持权限管理
- 支持协同评论
- 支持移动办公，不但可以和 IM 对接，还有 APP，可以在手机上处理告警事件
- 支持告警事件的统计、分析
- 支持认领、升级、转派、关闭等操作
- 支持告警降噪
- 支持和外部事件管理系统对接，比如 jira 等
毕竟，Flashduty 就是专职做 OnCall 的，比 Zabbix、Alertmanager 更完善，当然了，主要是定位问题，Zabbix 的定位主要还是一个监控系统，Alertmanager 的定位，主要是一个告警事件的聚合平台，而 Flashduty 的定位，就是一个专业的 OnCall 平台。
三类方案怎么取舍
| 方案 | 更适合的场景 | 主要优势 | 主要限制 |
|---|---|---|---|
| Zabbix | 单一 Zabbix 体系内的告警管理 | PROBLEM 管理、分派、媒介和升级能力比较完整 | 很难作为多监控系统统一事件平台 |
| Alertmanager | Prometheus 生态或多来源告警的中间处理 | 分组、抑制、路由能力成熟 | 缺少排班、认领、升级、协同等人员工作流 |
| Flashduty | 多监控、多团队、多通知渠道的统一 OnCall | 告警接入、降噪、排班、认领、升级、协同和统计闭环 | 商业 SaaS 产品，需要结合组织和预算评估 |
常见问题
Q1：已经有 Alertmanager，还需要 OnCall 平台吗？ A：如果只需要告警分组、抑制和路由，Alertmanager 可以承担核心工作；如果还需要排班、认领、升级、协同评论、移动端处理和统计分析，就需要评估专业 OnCall 平台。
Q2：Zabbix 内置能力什么时候够用？ A：当公司主要使用 Zabbix，告警来源单一，响应流程也主要在 Zabbix 内闭环时，Zabbix 内置 PROBLEM 管理通常可以解决基础需求。
Q3：OnCall 平台选型最容易忽略什么？ A：容易只关注通知渠道，而忽略告警事件闭环。真正影响效率的是告警是否能被正确分派、及时认领、无人响应时自动升级，并留下可追溯时间线。
总结
告警事件 OnCall 平台是告警响应体系的重要支撑。Zabbix、Alertmanager 和 Flashduty 分别适合不同阶段、不同复杂度的团队：Zabbix 更适合单一监控体系内处理，Alertmanager 更适合作为告警事件中间层，Flashduty 更适合把告警接入、降噪、排班、认领、升级和协同做成统一闭环。选型时先判断团队的告警来源、响应流程和人员协作复杂度，再决定采用哪类方案。
