是时候解决告警事件数据孤岛问题了

大家有没有发现，随着公司发展，慢慢引入了越来越多的监控、可观测性的系统，云上的、云下的，开源的、商业的，通用的、特定产品的，导致告警事件分散在非常多的地方，形成一个一个的数据孤岛。比如下面这些监控系统，你们应该不止用了一个吧：

上图中有些系统你可能会困惑，比如 OceanBase，明明是个数据库，为啥出现在这里。因为 OceanBase 自己内置有自己的监控能力，没有复用 Prometheus 之类的通用监控系统，这就是上面我提到的特定产品的监控。

告警数据孤岛引发的问题

告警事件没有收拢在一个地方，分散在多处，简单来讲，会带来两个问题：

• 没法统一管理。比如手机号、邮箱要配置在多个地方。另外，想要做统一的告警事件收敛降噪、排班认领升级、筛选过滤、事件再丰富等，都很痛苦。即便想要一个地方查看所有告警事件，也很难。
• 不方便故障定位。临近触发的告警事件在时间维度上是有关联性的，我们曾专门做过一个「事件墙」的产品，把重要的告警、变更事件（据Google统计，70%的线上故障是变更引起的）放到一个地方展示，辅助故障定位，对于中大公司效果很好。

在夜莺监控的社区用户群里，我就收到过多次群友提问，是否能够把 Zabbix 之类的其他监控系统的告警事件发给夜莺，使用夜莺做统一展现和触达。很遗憾，是不行的。因为夜莺的定位是一个监控系统，不是一个告警事件的中心，其内部逻辑有很多相互耦合的地方，不适合做这种事情。就像 Zabbix 也不会去接收其他监控系统的事件。

当然，Prometheus 生态的 Alertmanager 是个例外，它算是一个微型的统一告警事件中心，不局限于只接收 Prometheus 推过来的告警事件，但是它也不会兼容很多监控系统的 Webhook 协议来接收其他监控系统的事件，相当于 Alertmanager 往统一告警事件中心的方向走了一步，但也没走多远。

如何解决告警数据孤岛问题

国外其实很早就有这样的产品了，最为知名的是 PagerDuty，国外几乎所有的监控系统，不管是商业的还是开源的，都会支持对接 PagerDuty，把告警事件都推给 PagerDuty，然后在 PagerDuty 中做统一查看、响应、分析处理。

今天偶尔在群里看到某个朋友分享 NetFlix 的技术栈，发现 NetFlix 也是直接使用 PagerDuty，而没有重复造轮子，即便 NetFlix 已经如此之大。可能 NetFlix 的人觉得 PagerDuty 已经做得很好了，没必要重复造轮子。

国内类似 PagerDuty 的产品就是 FlashDuty 了。推荐使用 FlashDuty 来解决告警数据孤岛问题，它支持对接我上面截图中的所有监控系统。FlashDuty 这些产品是怎么一个思路呢？这里稍微展开说一下。

通过监控系统的 Webhook 方式与各个监控系统对接

这是个脏活累活，监控系统很多，每个监控系统几乎都提供了调用第三方接口的能力，即通过 Webhook 把告警事件推给 FlashDuty。但是各个监控系统的推送协议、字段定义都不一样，需要逐个对接，而且对接后还要不断维护，因为监控系统的版本迭代很快，字段定义可能会变。

通过这一步，就把所有的告警事件收集到一个地方了。另外，除了告警事件，FlashDuty 还可以对接变更事件，方便我们在故障时排查是否是变更导致的。

告警事件收敛以及灵活筛选

通常来讲，监控系统为了避免通知媒介不可用，经常会把相同的告警多次发送，FlashDuty 会把这种重复的告警收敛掉。另外，标签相同的告警也支持收敛为一个故障（按需配置），减少通知频次。

查看时，也需支持聚合查看，比如按照某个标签聚合、按照告警规则名称聚合、按照级别聚合等等，方便我们快速了解全盘情况。当然了，不同的监控系统，其告警事件的字段定义不同，这就需要 FlashDuty 做统一的字段映射、规整、结构化，这对未来引入 AI 分析、自动化处理是有好处的。

事件Pipeline和灵活的事件通知

告警事件统一接过来，在数据流中可以引入事件 relabel、事件过滤、事件元信息丰富等各类事件处理的能力，为事件增加更多上下文，方便告警接收者快速定位问题。

通过排班机制，践行 OnCall，让不值班的人可以睡个好觉。引入告警认领、升级机制，兜底漏掉的告警。通过不同的过滤条件，把不同的告警事件推送到不同的通知渠道，还可以和钉钉、飞书、企微等良好打通。而且提供 FlashDuty 手机 App，增强移动端的告警事件处理能力。

快速体验

FlashDuty 更多信息可以参考 官网，也可以免费注册体验，地址是：https://console.flashcat.cloud/。