告警事件产生之后，会带有一些 labels、annotations、description 等信息，有时这些信息不够规整需要二次处理，有时这些信息不够丰富需要附加更多信息，才方便 SRE 等 OnCall 人员快速定位、解决问题。具体应该如何做？本文会分享一些思路，希望对大家有所帮助。
需求场景举例
为了方便理解，我举几个场景例子：
- 比如，告警事件中包含 product、service 两个标签，我们可以基于这俩标签拼接出 SOP 地址，方便 OnCall 人员快速查看操作手册；
- 比如，告警事件中缺少 owner 信息，但是包含机器 IP，我们可以基于机器 IP 查询 CMDB，找到 owner 信息，附加到告警事件中；
思路
大体上，可以把事件的处理看作一个 Pipeline，包含两个重要 Action：Relabel 和 Enrichment，有两个位置适合配置 Action：告警规则那里（用于规则颗粒度的细粒度控制）和 OnCall 中心（一些相对通用的逻辑），下面我们展开说明。
告警规则
一个告警规则通常关联一个监控指标，在告警规则这个颗粒度，会有需求做一些细粒度的处理，比如某个告警规则生成的事件包含很多标签，有些标签想 Drop 掉，或者有些标签想拼接在一起变成一个新标签，都可以使用 Relabel Action 来实现。
下面是夜莺的告警规则中配置事件 relabel 的例子，这个 relabel 和 Prometheus 的 relabel 配置类似，都是基于标签的匹配、替换、删除等操作，只不过 Prometheus 中是对指标做 relabel，夜莺这里是对事件做 relabel：
除了在告警规则颗粒度配置一些事件处理逻辑，还有一些通用逻辑希望在更中心化的地方配置，比如在 OnCall 中心配置事件的处理逻辑。下面我以 Flashduty OnCall 产品举例，看看 Flashduty 的处理思路，供大家参考。
OnCall 中心
OnCall 中心可以对接各类监控系统，比如 Prometheus、Zabbix、Nightingale 等，接收到告警事件之后，会对事件进行一些处理，比如附加更多元信息、降噪、发送通知等。我们可以在 Flashduty 中创建一个上报监控事件的管道（称为 integration），然后在管道后面配置一些事件处理逻辑。整个架构示意图如下：
Flashduty 中可以创建多个 integration（即刚刚提到的管道，在 Flashduty 中称为集成），然后给这个 integration 配置标签增强，目前支持提取标签、组合标签、映射标签、删除标签等操作。
这样一来，只要发往这个 integration（管道）的告警事件，都会经过这个 Pipeline，对事件标签做统一处理。这几个标签操作都可以见名知义，只有映射标签稍微复杂一些，这里额外做一个说明。
映射标签
因为 Flashduty 是一个 SaaS 服务，无法直接访问公司内部的 CMDB，所以我们需要把 CMDB 中的映射数据导入 Flashduty，然后在 Flashduty 中配置映射规则即可。比如服务器 10.68.5.6 的负责人是 zhangsan，我们就可以根据机器信息查询到 zhangsan，然后把 zhangsan 附加到告警事件中。比如：
原始告警事件：
映射规则：
映射结果：
Callback 思路
如果告警引擎可以直接调用公司内部的 API，那么可以直接在告警引擎中配置 Callback，直接调用公司内部的 API，获取元信息，然后附加到告警事件中。这样的话就不需要管理、同步映射数据了。
如果你用过 Flashduty 的告警引擎，通过其 --help 参数就可以看到 -alerter.enrich 相关的配置，就是采用这个思路来做的。
结语
本文以夜莺和 Flashduty 举例，讲解了多种告警事件处理、Enrich 的思路，希望对大家有所帮助。如果你有更好的思路，欢迎留言讨论。夜莺和 Flashduty 的介绍信息如下，可以自行体验：
- 夜莺：https://github.com/ccfos/nightingale
- Flashduty：https://flashcat.cloud/product/flashduty/
