青云科技雷万钧：使用 Notification Manager 构建云原生通知系统

嘉宾 | 雷万钧    整理 | 小雨青年

出品 |CSDN云原生

2022 年 4 月 26 日，在 CSDN 云原生系列在线峰会第 2 期“可观测性与 APM 峰会”上，青云科技顾问软件工程师雷万钧分享了：在云原生场景下使用 Notification Manager 构建通知系统。

戳👇观看雷万钧分享视频

云原生下通知系统的特点

众所周知，在云原生领域，K8s 已经成为了事实上的标准。那么狭义上讲，云原生通知系统就可以理解为 K8s 下的通知系统，基于此，云原生下的通知系统拥有以下特点：

1. 为 Kubernetes 而生

2. 支持对接多种的事件源，告警、事件、审计等

3. 多租户设计 

4. 高并发，可以同时处理大量的通知

Notification Manager 是什么

Notification Manager 是 KubeSphere 开源的一款云原生多租户通知管理系统，支持从 Kubernetes 接收告警、事件、审计，根据用户设置的模板生成通知消息并推送给用户，支持将通知消息推送到 DingTalk，Email，Feishu，Pushover，Slack，WeCom，Webhook，短信平台（阿里、腾讯、华为）等。

Notification Manager 会接收来自 Promethus、Alertmanager 发出的警告消息、K8s 产生的审计消息以及 K8s 本身的事件。在规划中我们还会实现接入 Promethus 的告警消息和接入 Cloud Event 。消息在进入缓存之后，会经过静默、抑制、路由、过滤、聚合，最后进行实际的通知，并记录在历史中。

下面是对每个步骤的解析

1. 缓存（Cache）

缓存的作用有两个，一个是应对告警风暴，同时产生大量告警时减少对系统的影响；另一个是对告警事件做聚合处理，飞书、钉钉和企业微信，对访问频次有限制。

目前采用松耦合设计，支持内存、NATS Streamming（后续）。

2. 静默（Silence）

我们可以根据设定的规则对告警、事件、审计进行静默处理 ，比如支持设置静默时间，让晚上十点到早上八点不进行通知。

同时我们可以支持设置全局静默规则和租户静默规则，全局的规则的会被全部租户启用，而租户规则只对当前租户起作用。

3. 抑制（Inhibit）

一个节点宕机之后会发送大量告警，而这些告警不利于我们排查原因，我们可以通过设置抑制规则不再发送这部分告警给用户。

4. 路由（Route）

告警、事件、审计都是由一个个标签组成的，路由的本质就是根据标签寻找需要接收标签的接收器。

下图就是一个路由，他定义了一个路由，他有以下几部分组成：

• 标签选择器 alertSelector 

• 接收器 Receiver

接收器定义了我们的通知往哪里发、如何发，有如下特点

• 可复用。尽可能复用配置，减少用户运维成本。

• 多租户。支持定义全局接收器用于接收所有的通知，同时用户可以定义自己的通知接收器用于接收租户相关的通知。

• 动态加载。

为了实现动态加载，我们采用 CRD 的模式定义了 Config 和 Receiver。

Config CRD 定义了发送通知需要的信息，比如钉钉的 APP secret，它来定义我们如何发送信息，还可以通过标签区分全局 Config 和租户 Config 。

Receiver CRD 定义了通知发送到哪里，比如钉钉、Email、飞书、Slack、短信平台、webhook、企业微信等。

我们可以通过下图理解 Receiver 如何选择 Config 的，租户级的 Receiver 只能使用租户级的 Config，全局的 Receiver 只能使用全局的 Config。如果一个租户级的 Receiver 没有找到对应的租户级的 Config 就会使用全局级的 Config，这样就可以通过全局级的 Config 达到降低运维成本的作用。

那么，我们定义了 Receiver 之后，消息过来之后是如何匹配到对应的 Receiver 呢？有两种模式：

• 路由匹配：根据路由规则匹配 Receiver。

• 自动匹配：根据 namespace 标签自动匹配。

对于这两种模式，有三种协同方式，分别是

• All：同时使用两种方式匹配。

• 路由优先：优先使用路由规则匹配，未匹配成功的使用自动匹配。

• 只使用路由：使用路由规则未匹配到 Receiver，则不发送通知。

5. 过滤（Filter）

Filter 的作用是 Receiver 可以选择接收哪些通知，过滤掉不重要的通知。

实现 Filter 的方式有两种，一种是通过在 Receiver 中设置标签选择器，过滤掉不重要的通知，对于单个通知有效，另一种是定义租户级别的静默规则，对部分通知进行静默。

6. 聚合（Aggregation）

聚合的的作用有两个：一个是在于对于消息的汇总，便于归档，另一个是减少调用频次，避免被钉钉等禁言，节省资源。

7. 通知（Notify）

通知发送采用的是并行的模式，支持高性能，支持自定义模板，支持全局模板、接收器模板以及租户模板。下面是一个自定义模板的转换示例。

8. 多语言支持

Notification Manager 内置支持中英文，并支持语言包，可以换成任意一种语言。

Notification Manager 在 KubeSphere 上的最佳实践

KubeSphere 的通知系统是使用 Notification Manager 实现的，不仅实现了可视化配置，通知历史，同时实现了多集群环境下的通知配置分发。

KubeSphere 愿景是打造一个以 Kubernetes 为内核的云原生分布式操作系统，它的架构可以非常方便地使第三方应用与云原生生态组件进行即插即用（plug-and-play）的集成，支持云原生应用在多云与多集群的统一分发和运维管理。

点击视频观看实践演示（19分35秒）

Notification Manager 未来发展方向

在接下来的迭代中我们预计支持 Cloud Event 。为了去除因为中间件导致的数据不安全性，我们支持直接从Promethus 接入告警。同时，也要支持前面提到的通知抑制（Inhibit）功能。

Cache将支持更多中间件，比如 Redis、Kafka 等。

由于目前我们的模板是基于 Go template ，对新手不是很友好，后续考虑要不要支持 XML 类型的模板。最后支持更多接收器，保证能通过更多渠道发送通知。

---

聚焦云原生新技术、新实践，帮助开发者群体赢在开发范式转移的新时代。欢迎关注CSDN云原生微信公众号～