告警事件产生之后，通常会带有 labels、annotations、description 等信息。问题在于，这些信息有时不够规整，需要二次处理；有时不够丰富，缺少 owner、服务归属、SOP、机器信息等上下文，OnCall 人员就需要再去查 CMDB、问研发、翻文档，排障链路会被拉长。
告警事件 enrichment 的目标，就是在事件进入分派、降噪、通知和排障流程之前，把可计算、可查询、可映射的元信息尽量补齐。这样一来，SRE 或 OnCall 人员看到的不只是“某个指标异常”，而是一个带有业务、服务、负责人和处理入口的告警上下文。
核心要点
- 告警事件富化可以看作一个事件处理 Pipeline，常见动作包括 Relabel 和 Enrichment。
- 告警规则适合做规则颗粒度的细粒度处理，比如标签提取、替换、删除、组合。
- OnCall 中心适合做通用处理，比如统一附加元信息、降噪、分派和通知。
- 如果告警事件里已有 product、service、IP 等字段，可以基于这些字段拼接 SOP 地址，或通过 CMDB 映射 owner 等信息。
- 打通 CMDB 有两种常见思路：把映射数据导入 OnCall 平台，或由告警引擎通过 Callback 直接查询内部 API。
为什么告警事件需要 enrichment
一条原始告警事件通常能说明“发生了什么”，但不一定能说明“谁负责、去哪看、怎么处理、影响哪个服务”。这些信息缺失时，值班人员需要额外沟通和查询，告警恢复速度取决于人工经验，而不是事件本身的上下文质量。
更好的做法，是在告警进入 OnCall 流程前完成信息补齐：
| 富化目标 | 可依赖的原始字段 | 富化后的信息 | 对 OnCall 的价值 |
|---|---|---|---|
| 补齐负责人 | 机器 IP、服务名、应用名 | owner、团队、值班组 | 告警可以更准确地分派给负责人 |
| 补齐处理入口 | product、service | SOP 地址、服务文档地址 | 值班人员可以快速查看操作手册 |
| 规范事件标签 | 原始 labels、annotations | 统一命名、删除无用标签、组合新标签 | 后续降噪、聚合、路由更稳定 |
| 补齐业务上下文 | 服务、产品、集群、环境 | 产品线、服务归属、环境信息 | 排障时更容易判断影响范围 |
| 支持根因定位 | IP、实例、服务、告警指标 | CMDB 元信息、资源归属、处理建议入口 | 减少人工查表和跨团队询问 |
这些动作并不会改变告警事实本身，而是让事件更容易被机器处理、被人理解、被流程消费。
需求场景举例
为了方便理解，可以从两个典型场景看告警事件富化的价值。
基于标签拼接 SOP 地址
如果告警事件中包含 product、service 两个标签，就可以基于这两个标签拼接出 SOP 地址。OnCall 人员收到告警后，不需要再去搜索对应操作手册，可以直接从事件详情进入处理文档。
这种场景适合用规则侧或管道侧的标签组合能力来完成。关键点是原始事件必须有稳定字段，拼接规则也要保持统一。
基于机器 IP 查询 CMDB owner
如果告警事件中缺少 owner 信息，但是包含机器 IP，就可以基于机器 IP 查询 CMDB，找到 owner 信息，再把 owner 附加到告警事件中。
这类场景的重点不是改写告警内容，而是把 CMDB 中已经存在的资产归属关系转成告警上下文。富化后的事件可以用于分派、通知、升级和后续统计。
告警事件处理的基本思路
大体上，可以把事件处理看作一个 Pipeline。Pipeline 中有两个重要 Action：
| Action | 作用 | 典型操作 |
|---|---|---|
| Relabel | 对事件已有标签做整理和重写 | 匹配、替换、删除、提取、组合标签 |
| Enrichment | 给事件附加额外元信息 | 查询 owner、补充 SOP、映射服务归属、附加 CMDB 信息 |
这些 Action 通常有两个合适的配置位置：
- 告警规则侧：适合规则颗粒度的细粒度控制。
- OnCall 中心侧：适合跨监控系统的通用处理逻辑。
两者不是互斥关系。规则侧负责把单条告警规则产生的事件整理干净，OnCall 中心负责把不同监控系统上报的事件统一加工、降噪、分派和通知。
在告警规则侧做 Relabel
一个告警规则通常关联一个监控指标。在告警规则这个颗粒度，经常需要做一些细粒度处理：某个告警规则生成的事件包含很多标签，有些标签想 Drop 掉，有些标签想拼接在一起变成一个新标签，这些都可以使用 Relabel Action 来实现。
下面是夜莺告警规则中配置事件 relabel 的例子。这个 relabel 和 Prometheus 的 relabel 配置类似，都是基于标签做匹配、替换、删除等操作。区别在于，Prometheus 中是对指标做 relabel，夜莺这里是对事件做 relabel。
把规则侧 relabel 用好之后，事件进入 OnCall 中心时，字段会更规整，后续 enrichment、降噪和分派也更容易稳定执行。
在 OnCall 中心做统一 enrichment
除了在告警规则颗粒度配置事件处理逻辑，还有一些通用逻辑更适合放在中心化的位置，比如在 OnCall 中心配置事件处理。
OnCall 中心可以对接各类监控系统，比如 Prometheus、Zabbix、Nightingale 等。接收到告警事件之后，OnCall 中心可以继续对事件做处理，包括附加更多元信息、降噪、发送通知等。
以 Flashduty OnCall 产品为例，可以创建一个上报监控事件的管道，在 Flashduty 中称为 integration，然后在管道后面配置事件处理逻辑。整体架构示意如下：
Flashduty 中可以创建多个 integration，也就是多个集成管道。每个 integration 可以配置标签增强，目前支持提取标签、组合标签、映射标签、删除标签等操作。
这样一来，只要发往这个 integration 的告警事件，都会经过这个 Pipeline，对事件标签做统一处理。
| 标签增强能力 | 适用场景 |
|---|---|
| 提取标签 | 从已有字段中解析出更稳定的标签 |
| 组合标签 | 将多个字段拼接成新标签，比如基于 product、service 生成 SOP 入口 |
| 映射标签 | 基于 IP、服务名等字段映射 owner、团队、业务归属等信息 |
| 删除标签 | 去掉无用或干扰聚合、分派的标签 |
这几个标签操作都比较容易理解，只有映射标签稍微复杂一些，下面单独说明。
映射标签：把 CMDB 信息附加到告警事件
因为 Flashduty 是一个 SaaS 服务，无法直接访问公司内部的 CMDB，所以需要把 CMDB 中的映射数据导入 Flashduty，然后在 Flashduty 中配置映射规则。
举个例子：服务器 10.68.5.6 的负责人是 zhangsan。当告警事件中包含这台机器的信息时，就可以根据机器信息查询到 zhangsan，再把 zhangsan 附加到告警事件中。
原始告警事件：
映射规则：
映射结果：
这种方式的核心价值，是把 CMDB 里的静态资产关系转成告警事件里的动态上下文。后续无论是路由到负责人、按团队降噪、还是排障时定位服务归属，都可以直接使用事件上的富化字段。
Callback：由告警引擎直接查询内部 API
如果告警引擎可以直接调用公司内部的 API，也可以在告警引擎中配置 Callback，直接调用公司内部 API 获取元信息，然后附加到告警事件中。
这种方式不需要在 OnCall 平台中管理、同步映射数据。它更适合告警引擎能够访问内部网络，并且公司已经有稳定的 CMDB 或资产服务 API 的场景。
如果你用过 Flashduty 的告警引擎，通过其 --help 参数可以看到 -alerter.enrich 相关配置，就是采用这个思路来做的。
两种 CMDB 打通方式可以简单对比如下：
| 方案 | 工作方式 | 优点 | 适用条件 |
|---|---|---|---|
| 导入映射数据 | 将 CMDB 中的映射关系导入 OnCall 平台，再配置映射标签 | 不要求 SaaS 平台访问内部 CMDB | 需要维护映射数据同步 |
| Callback 查询 API | 告警引擎调用内部 API，实时获取元信息 | 不需要在 OnCall 平台管理映射数据 | 告警引擎需要能访问内部 API |
选择哪种方式，取决于告警引擎、OnCall 平台和 CMDB 之间的网络访问关系。如果 SaaS 无法访问内部 CMDB，导入映射数据更直接；如果告警引擎本身就在内部环境，Callback 查询 API 会更自然。
FAQ
告警事件 enrichment 和 relabel 有什么区别？
Relabel 主要处理事件已有字段，比如匹配、替换、删除、提取和组合标签；Enrichment 主要给事件附加新信息，比如 owner、SOP 地址、服务归属、CMDB 元信息等。实际落地时，两者经常放在同一个事件 Pipeline 中配合使用。
为什么不直接在告警规则里写完所有富化逻辑？
告警规则适合做和单条规则强相关的细粒度处理，但 owner 映射、CMDB 信息补齐、统一标签规范、分派降噪等逻辑通常具有通用性。把这些逻辑放在 OnCall 中心，可以减少重复配置，也方便跨 Prometheus、Zabbix、Nightingale 等不同监控系统统一处理。
SaaS OnCall 平台不能访问内部 CMDB 时怎么办？
可以把 CMDB 中需要用于告警富化的映射数据导入 OnCall 平台，然后通过映射标签完成 owner、团队、业务归属等字段补齐。Flashduty 的映射标签就是这种思路。
Callback 和映射标签应该怎么选？
如果告警引擎能够访问内部 API，并且内部 CMDB API 稳定，可以用 Callback 直接查询元信息。如果 OnCall 平台是 SaaS，无法访问内部 CMDB，则可以选择导入映射数据并配置映射标签。
结语
告警事件与 CMDB 打通，本质上是把“监控发现异常”和“组织知道谁负责、怎么处理”连接起来。事件里有了 owner、SOP、服务归属、产品线等上下文之后，分派更准确，降噪更有依据，根因定位也能少走弯路。
本文以夜莺和 Flashduty 举例，介绍了在告警规则侧做 Relabel、在 OnCall 中心做统一 enrichment、通过映射标签附加 CMDB 信息，以及通过 Callback 调用内部 API 的几种思路。夜莺和 Flashduty 的介绍信息如下，可以自行体验：
