事件 Pipeline
在通知之前按顺序对事件做变换、补充、丢弃或路由的处理器链。
这页办完你会得到：一条挂在告警规则或通知规则上的处理器链，事件在发出去之前 先从它上面淌过一遍——改标签、补上下文、或者干脆丢掉。
界面上这个功能叫 工作流，入口是 告警通知 → 工作流（/event-pipelines）。
1. 新建一条工作流
点 新增，右侧抽屉里配置，三段：作用范围、处理器、基本信息。
保存之后界面会直接告诉你一句要紧的话：工作流建好后不会自动生效，需要在告警规则或 通知规则里引用它才会执行。 抽屉里那个「去挂载」的接力面板就是干这个的。
2. 作用范围：哪些事件进这条工作流
条件之间是「与」，全部留空表示所有告警事件都进。
- 适用标签：按事件标签筛。填
service=mon，就只有带这个标签的事件会进来； - 适用属性：按事件的属性筛，可选的属性是固定的四个——业务组、数据源、 是否恢复、告警级别。
「是否恢复」很有用：想让恢复通知不走某个处理器，在这里排掉比在处理器里判条件干净。
3. 处理器：开源版有这五种
处理器从上往下依次执行，事件是一条线走完的，没有分支。拖动卡片可以调顺序。
| 分类 | 处理器 | 干什么 |
|---|---|---|
| 降噪 | 事件丢弃 | 按条件丢弃事件，后续处理器不再执行，也不产生通知 |
| 富化 | AI 摘要 | 用大模型给事件生成一段摘要 |
| 外呼 | Webhook 回调 | 把事件回调给外部系统（工单、自动化） |
| 改写 | 事件标签改写 | 修改 / 新增 / 删除事件标签 |
| 改写 | 事件更新 | 调用一个 HTTP 接口，并用返回内容更新事件 |
事件丢弃 用 Go 模板写条件，模板结果是 true 就丢，其他任何输出都放行。
可用变量：$event.Severity（数字 1/2/3）、$event.IsRecovered（布尔）、
$event.RuleName、$event.TagsMap.<标签名>。编辑器里有几个一键示例：
{{ if eq $event.Severity 3 }}true{{ end }}
{{ if $event.IsRecovered }}true{{ end }}
{{ if eq $event.TagsMap.env "dev" }}true{{ end }}
标签改写和事件更新怎么配，见改写标签与补充上下文。 AI 摘要怎么接模型、写提示词、结果落在哪，见AI 摘要处理器。
新建时那张处理器卡片不预选类型，必须自己从下拉里挑一个——类型是必填的，不选就存不下去， 提示是「请选择处理器类型，类型为空的处理器对每条事件都会执行失败」。这条校验存在的理由 也正是这句话。
变量 区可以定义工作流级别的输入变量，处理器里用 {{$inputs.变量名}} 引用，
适合把「同一条流程、不同环境换个地址」这种差异拎出来。
4. 挂到规则上，它才会跑
两个挂载点，语义不同：
- 告警规则上挂：事件一产生就跑，影响所有下游——屏蔽、落库、订阅、每一条通知规则 看到的都是处理过的事件。要丢弃事件、要改所有人都能看到的标签，挂这里。
- 通知规则上挂：只在这条通知规则准备发送前跑，只影响这一次发送。 想给某个群的消息单独加点上下文，挂这里。
在通知规则的表单里，这一段叫 事件处理工作流，点「添加事件处理工作流」选中即可， 每条都能单独启用/停用。
Pipeline 在屏蔽之前跑，所以挂在告警规则上的工作流改出来的标签，屏蔽规则能匹配到。 完整顺序见降噪与路由模型。
几个容易踩的点
- 工作流是全局的，权限靠「授权团队」。 基本信息里填的授权团队决定谁能看和改这条工作流， 它本身不绑业务组。
- 停用工作流不等于解除引用。 引用它的规则还在，只是这条流程被跳过； 删除工作流会让引用它的规则那一段直接失效。
- 别把第一个处理器设成事件丢弃再去调试。 事件被丢掉后，后面的处理器不会执行， 执行记录里也看不到它们的输出。
- 顺序有意义。 先改写标签再按标签丢弃，和反过来，结果完全不同。
下一步
- 上线前先跑一遍：用模拟事件试跑
- 跑完去哪看结果：查看 Pipeline 执行记录
- 具体怎么改标签：改写标签与补充上下文
- 试跑通了线上不对：工作流试跑通过但线上不生效