对于大部分公司，通常都不止一套监控、可观测性相关的系统：云上的、云下的，开源的、商业的，指标的、日志的、链路的。各个系统体验不同，权限难管，告警入口也不统一。如何利旧现有体系，同时把使用体验和故障响应效率提上来，是很多技术负责人头疼的问题。
核心要点
- Grafana 解决了很多团队的统一可视化问题，但告警仍可能散落在 Prometheus、日志系统、链路系统和云监控中。
- 统一告警可以拆成两层：统一事件生成，以及统一事件分发和响应。
- 事件生成关注“从哪些数据源判断异常”，事件分发关注“告警出来后如何路由、通知、认领、升级和降噪”。
- Flashduty 的设计思路是兼顾利旧和统一：既对接多种存储生成事件，也对接已有监控系统接收事件。
- 对多机房、多团队场景，告警引擎靠近数据源部署，可以降低网络分区对告警判定的影响。
要完全推翻现有的体系也不现实，毕竟迁移成本很高，而且谁能保证那些所谓的 all-in-one 的系统一定能在各方面胜出现有的平台？利旧的同时，把体验和价值提升，或许是个路子。
Grafana 其实是个很好的例子，Grafana 几乎统一了数据可视化。如果我们再进一步，除了可视化还有什么可以统一呢？我想应该是告警！一个典型的监控/可观测性系统，其架构如下：
数据采集方面，确实五花八门，比如指标使用 Categraf、Exporter，Tracing 使用 Otel-Collector，日志使用 Filebeat。采集层通常贴近技术栈和运行环境，强行统一的收益未必高。
数据存储方面，指标使用 VictoriaMetrics、Prometheus，日志和 Tracing 使用 ElasticSearch、ClickHouse，解决方案也基本已经固化。许多企业更现实的路线不是推倒重来，而是在既有系统之上统一体验。
告警方面，尚有统一优化的空间。首先，我们希望把各个平台的告警统一到一起，做统一的收敛降噪、排班认领升级、灵活的分发。我们做了一个产品来做告警统一，称为 Flashduty，本文介绍一下 Flashduty 的一些设计理念，希望对你有所启发。
Flashduty 统一告警的思路
统一告警如果细分，可以分两个方面，一个是统一事件生成，一个是统一事件分发。
- 事件生成。通常是监控系统来做。监控系统支持用户配置告警规则，然后周期性查询存储，对数据做异常判定，进而生成告警事件。
- 事件分发。通常是 OnCall 平台来做，比如国外的 PagerDuty、Opsgenie。对接各个监控系统收集告警事件，然后做统一的收敛降噪、排班、分发等。
| 层次 | 解决的问题 | 典型能力 |
|---|---|---|
| 统一事件生成 | 从不同数据源中判断异常 | 查询规则、阈值判定、事件生成、规则管理 |
| 统一事件分发 | 告警出来之后如何处理 | 路由、分派、通知、认领、升级、收敛降噪 |
统一事件生成
Flashduty 的思路是对接各种存储，比如 Prometheus、VictoriaMetrics、Thanos、MySQL、Postgres、Oracle、ElasticSearch、Loki、ClickHouse 等，支持用户配置查询告警规则，然后周期性查询生成告警事件。
其架构图如下：
一个公司通常会有多个机房，每个机房有不同的存储，要对各种存储做告警，建议在每个机房部署一个告警引擎，避免网络分区问题。告警引擎从中心同步告警规则，然后查询存储做异常数据判定，进而生成告警事件。
下面是一个告警规则列表页面的样例，即大家可以在 Flashduty 管理各类告警规则。
除了对接存储生成告警事件，Flashduty 还提供了一个事件监控小工具，叫 catpaw，catpaw 可以执行一些自定义脚本，对问题现场做检测，检测到问题之后直接生成告警事件。catpaw 是开源的，地址是：https://github.com/cprobe/catpaw。
统一事件分发
告警事件散落在各个监控系统里，不方便处理，不方便量化，而且动不动还有告警风暴，此时就需要一个 OnCall 平台了。
国外有 PagerDuty、Opsgenie 这样的产品，PagerDuty 估值几十亿美金。很多 SRE 工程师应聘的时候，如果发现雇主公司没有使用 PagerDuty，直接拒绝入职，因为没有使用 PagerDuty 的 OnCall 工作，太痛苦，凌晨一个告警，把全组都呼起来，大家都受不了。
Flashduty 类似 PagerDuty，可以对接各类监控系统，收集告警事件，目前已经对接的监控系统如下图：
整个数据流原理是：监控系统生成告警事件，通过 Webhook 或 Email 的方式发给 Flashduty，Flashduty 即可做后续统一处理。比如：
- 标签增强。给告警事件附加更多有意义的元信息，方便后续筛选、查看、关联
- 事件处理。按条件修改告警事件，也可以过滤、抑制告警事件等
- 路由。通过告警事件的属性、标签，路由告警事件到特定的协作空间，即路由给特定的团队
- 分派。协作空间里，关联了不同的分派策略，不同级别的告警可以使用不同的通知媒介。
- 分发告警时也可以和值班表关联，避免所有人受到打扰
- 支持认领、升级策略，确保告警一定被最终处理
- 支持收敛降噪，把多条告警合并为故障，解决告警风暴问题
- 可以和 IM 打通，方便移动端办公。尤其是晚上睡得朦朦胧胧，移动办公更是必备
适合优先统一告警的场景
如果企业已经满足下面任意一种情况，统一告警通常比统一采集、统一存储更容易先见效：
- 已经有多套 Prometheus、Zabbix、云监控、日志监控或链路监控，告警入口分散。
- 多个团队共用基础设施，但值班表、通知媒介、处理流程各不相同。
- 告警风暴经常发生，需要把多条告警合并为一个可处理的故障。
- 希望按协作空间、服务、环境、等级等属性做灵活路由。
- 希望沉淀告警处理过程，后续做告警治理和效率度量。
总结
通过统一事件生成和分发，Flashduty 提升了告警的整体体验。新的架构不要求企业立即替换现有监控系统，而是把分散的数据源、告警事件和响应流程纳入同一个处理闭环：
如果您也想建设类似的平台，可以参考 Flashduty 的做法，或者直接使用 Flashduty，Flashduty 的地址如下：
- 产品介绍：www.flashduty.com
- 免费注册：console.flashcat.cloud
