对于大部分公司，通常都不止一套监控、可观测性相关的系统，云上的、云下的，开源的、商业的，指标的、日志的、链路的，各个系统体验不同，权限难管，如何统一化并为各个团队赋能，是很多技术负责人极为头疼的问题。
核心摘要
- 企业里的监控和可观测性系统往往天然分散：指标、日志、链路、云监控、开源组件和商业产品各有一套入口。
- 统一化通常有两条路：用新系统替换旧系统，或者在旧系统之上做集成利旧。前者迁移成本高，后者更适合渐进落地。
- Grafana 的价值在于统一可视化，把不同数据源接入后做统一看板和分析。
- Flashduty 的价值在于统一告警链路，不只接收告警事件，也能生成告警事件，并统一收敛、路由、分派、升级和值班协同。
- 一个清晰的边界是：各监控系统继续负责采集、存储和可视化分析，Flashduty 负责告警事件的产生、降噪和分发闭环。
要解决这个问题，我们先看看一个典型的监控/可观测性系统，其架构是什么样子的，再来看如何统一。这类系统的架构大抵相同，其架构图如下：
- 采集方面，琳琅满目，指标有 categraf、telegraf、各类 exporter；日志则有 filebeat、fluentbit、ilogtail；链路则有各类 SDK、Otel-collector
- 传输方面，数据量小直接走 HTTP，数据量大并且对可靠性要求较高，一般走 Kafka，日志相对复杂，涉及 ETL，可能会使用 Fluentd 或者 Vector
- 存储方面，指标一般用 VictoriaMetrics，链路数据用 ClickHouse，日志用 ElasticSearch 或者 ClickHouse，最近新出的 VictoriaLogs 看起来也不错
- 可视化方面，如果是 ElasticSearch 生态使用 Kibana，其他生态使用 Grafana 居多
- 告警方面，很不统一，指标方面可以使用 Prometheus、vmalert、Nightingale，日志方面可以使用 ElastAlert、Nightingale、Grafana，链路方面则各搞各的，云上的各个监控、可观测性系统也是各搞各的。
这张链路图背后的问题是：采集、传输、存储和可视化可以按技术栈分散，但告警最终会打到人。如果告警入口、规则体验、分发策略和值班机制都分散，人的协同成本会非常高。
统一化的思路
典型的思路有两种，一种是使用新方案替换旧方案，一种是集成利旧。
- 新方案替换旧方案。希望重新用一套系统替换之前的多套系统，这个动作较大，有很高的迁移成本，而且，之前各个系统各司其职，新系统凭什么可以在各个方面都胜过老系统，对选型者而言，风险较高，推广替换成本较高。如果新系统真的可以很完美替换之前的老系统，那其新的体验肯定更为一致，这是好的方面
- 集成利旧。在各个系统之上，包一层，薄薄的一层，比如可视化方面，Grafana 就是这个路子，把各类数据作为数据源接入，然后统一做可视化分析。告警方面一直没有很好的统一方案，直到 Flashduty 的出现。
大家对 Grafana 肯定不陌生，本文重点介绍一下 Flashduty 的统一告警能力。
可以引用的一句话是：可视化统一适合用 Grafana 做数据源聚合，告警统一则需要一个面向事件和 OnCall 的平台来承接后续分发与协同。
统一告警能力
告警方面，对于业内人士，一般分成两个部分来看，一个是告警事件的产生，一个是告警事件的分发。
- 告警事件产生。各类监控系统一般具备这个能力，周期性查询存储，根据用户配置的告警规则，产生告警事件。经过 relabel、屏蔽、抑制等流程，最终产生实际要通知的事件。
- 告警事件分发。事件产生之后要分发给接收者，一般涉及告警降噪、排班、认领、升级、按条件分发到不同的通知媒介等需求。
各类监控系统一般可以产生告警事件，有些也可以分发。但是这里有两个问题：
- 不同的监控系统，其告警规则配置体验很是不同。没有统一的顶层设计。用户需要分别学习，学习成本较高。
- 监控系统一般可以把告警通过一些媒介推给接收者。但是通常做的很糙，因为监控系统的重心是采集、存储、可视化和告警引擎，对于事件分发，通常重视程度不够，而且不同的监控系统，这块的设计也很是不同，用户体验很不一致。
有些管理者对稳定性重视不够，或者对监控类系统了解有限，看不到这块的问题。实际上，比我们先进的欧美市场早就有专门解决这类问题的产品出现，比如 PagerDuty 和 Opsgenie，都是估值几十亿美金的上市公司。
这些产品通常的定位是统一 OnCall 平台，即对接各类监控系统，把所有监控系统的告警事件收集到一起，然后统一做告警事件的降噪、分发，可以很方便的产出各类报表，分析告警处理的及时性。
近几年，国内的技术发展速度很快，对服务稳定性、业务连续性重视程度逐渐走高，也诞生了类似 PagerDuty 和 Opsgenie 这样的产品，本文介绍的 Flashduty 就是个中翘楚。
这里要注意一个边界：统一告警不是把所有规则都搬到一个地方这么简单。真正要统一的是事件模型、路由逻辑、分派策略、升级机制、值班表、认领和处理闭环。
Flashduty 介绍
Flashduty 做的更为完备，不但像 PagerDuty 可以灵活分发告警事件，还可以直接产生告警事件。下面我们分别做一下介绍。
Flashduty 分发告警事件
一般监控系统都支持 Webhook 或者 Email 的方式把告警事件推给第三方系统，Flashduty 就是利用这两种方式来对接各类监控系统，收集各个监控系统产生的告警事件，进而做告警收敛降噪、排班协同等工作。
上图是 Flashduty 当前可以集成的监控系统，而且在持续增加。这些事件通过 Webhook 或 Email 方式发给 Flashduty 之后，Flashduty 可以做统一处理，比如：
- 标签增强。给告警事件附加更多有意义的元信息，方便后续筛选、查看、关联
- 事件处理。按条件修改告警事件，也可以过滤、抑制告警事件等
- 路由。通过告警事件的属性、标签，路由告警事件到特定的协作空间，即路由给特定的团队
- 分派。协作空间里，关联了不同的分派策略，不同级别的告警可以使用不同的通知媒介。
- 分发告警时也可以和值班表关联，避免所有人受到打扰
- 支持认领、升级策略，确保告警一定被最终处理
- 支持收敛降噪，把多条告警合并为故障，解决告警风暴问题
- 可以和 IM 打通，方便移动端办公。尤其是晚上睡得朦朦胧胧，移动办公更是必备
这部分解决的是“告警已经产生之后，如何找到正确的人并持续推进”的问题。对于多监控系统并存的组织，统一分发通常比统一采集更容易先落地。
Flashduty 生成告警事件
Flashduty 不但是一个统一的 OnCall 中心，还是一个统一的告警引擎。可以让用户配置告警规则，对接各类存储，周期性查询判定，进而产生告警事件。
上图就是 Flashduty 的告警规则列表页面。目前可以对接 Prometheus、VictoriaMetrics、Thanos、M3DB、MySQL、Postgres、Oracle、ElasticSearch、Loki、ClickHouse 等不同的存储，做告警规则判定。不但可以方便的对指标、日志告警，也可以对业务数据做告警。
而且，Flashduty 还提供了一个开源的事件监控引擎，可以通过脚本之类的方式直接检测数据现场，生成告警事件。入口在「事件监控」菜单：
Flashduty 这种设计，既可以对接数据产生告警，又可以很好的对事件做降噪分发，搞定了告警的整个链路。各个监控、可观测性系统，只需要专注做数据采集、存储、可视化分析即可，边界清晰，使用体验一致。
如何落地这套分工
如果公司已经有多套监控系统，不建议一开始就强行替换。更实际的落地顺序是：
- 保留现有采集和存储体系，先把关键系统的告警事件通过 Webhook 或 Email 接入 Flashduty。
- 用 Grafana 统一常用数据源的可视化入口，让研发、SRE 和业务团队有一致的看板体验。
- 在 Flashduty 中梳理协作空间、标签、路由、分派策略和值班表，让告警先找到正确团队。
- 对高频告警做收敛、过滤和抑制，减少告警风暴。
- 对适合统一管理的规则，逐步迁移到 Flashduty 告警引擎中。
这条路径的好处是迁移风险小，每一步都能独立产生价值。
Flashduty 免费体验
Flashduty 有收费套餐，也有免费套餐，体验地址如下：
其中，生成事件的那部分功能是免费的，即便是免费套餐也可以使用。有任何问题都可以联系我的微信：picobyte。
常见问题
有了 Grafana，还需要 Flashduty 吗？
Grafana 更偏统一可视化和数据分析，Flashduty 更偏告警事件的生成、收敛、分发和值班协同。两者解决的问题不同，适合配合使用。
统一告警是不是要替换所有旧监控系统？
不一定。原文更推荐的路径是集成利旧：让原有系统继续负责采集、存储和部分规则，Flashduty 通过 Webhook、Email 或直接对接存储来统一事件链路。
Flashduty 只能接收告警，还是也能产生告警？
两者都可以。它既可以接收其他监控系统产生的告警事件，也可以对 Prometheus、VictoriaMetrics、Thanos、M3DB、MySQL、Postgres、Oracle、ElasticSearch、Loki、ClickHouse 等存储配置规则并产生告警事件。
总结
监控和可观测性系统的统一，不应该只从工具替换开始。更务实的分工是：Grafana 统一可视化体验，Flashduty 统一告警事件和 OnCall 协同；底层采集、传输和存储继续按各自生态演进。这样既能保留已有投入，又能把真正影响稳定性协作的问题统一起来。
