对于大部分公司，通常都不止一套监控、可观测性相关的系统，云上的、云下的，开源的、商业的，指标的、日志的、链路的，各个系统体验不同，权限难管，如何统一化并为各个团队赋能，是很多技术负责人极为头疼的问题。
要完全推翻现有的体系也不现实，毕竟迁移成本很高，而且谁能保证那些所谓的 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 打通，方便移动端办公。尤其是晚上睡得朦朦胧胧，移动办公更是必备
总结
通过统一事件生成和分发，Flashduty 提升了告警的整体体验，所以新的架构变成了 👇
如果您也想建设类似的平台，可以参考 Flashduty 的做法，或者直接使用 Flashduty，Flashduty 的地址如下：