# 用模拟事件试跑

对一条手写的事件跑一遍 Pipeline，在上线前看每个处理器的输出。

最后校对于 2026-10-10

这页办完你会得到：在工作流还没挂到任何规则上之前，就看到它对一条事件做了什么—— 哪个处理器改了哪个标签、事件是不是在半路被丢掉了。

## 试跑入口在哪[​](#试跑入口在哪 "试跑入口在哪的直接链接")

两处，作用范围不同：

* **单个处理器**：每张处理器卡片里都有一个试跑按钮，只跑这一个处理器。 调 relabel 的正则时用它，一次只验一件事；
* **整条工作流**：表单底部的试跑按钮，从上到下把所有处理器跑一遍， 能看出顺序对不对、会不会被前面的处理器提前丢掉。

两个都在工作流的新建/编辑抽屉里，**不需要先保存**。点开之前会先校验表单， 有必填项没填会把出错的卡片展开给你。

## 历史事件还是样例事件[​](#历史事件还是样例事件 "历史事件还是样例事件的直接链接")

弹窗第一步是 **选择测试事件**，两个 tab：

**历史事件**——列出这段时间的真实告警，勾一条。首选这个：真实事件带着真实的标签和取值， 试跑结果最接近线上。这段时间一条都没有时，弹窗会提示「这段时间没有历史告警事件」， 并给一个「改用样例事件试跑」的按钮。

**样例事件**——由服务端合成的一条假事件，**只在内存里流转、不会入库**， 所以新装的实例、还没烧出过任何告警时也能验证配置。它固定带这几个标签：

```
__name__=cpu_usage_idle

ident=mock-host-01

env=prod

service=web
```

外加一个 `rulename` 标签。**告警级别** 和 **恢复事件** 两项可以调—— 处理器经常按级别或恢复态分支（比如「丢掉 S3」「丢掉恢复通知」）， 只有把这两项调一遍才能把分支都覆盖到。

## 读试跑结果[​](#读试跑结果 "读试跑结�果的直接链接")

点试跑后切到 **试跑结果** 视图，三块内容：

* 顶部横幅：**执行成功** 或 **执行失败**；
* **逐节点执行结果**：处理器一个个列出来，每个带一句结果消息。 事件丢弃处理器的消息是「条件命中，事件已丢弃」或「条件未命中，事件继续往下走」； 标签改写给出改写前后的差异；
* **处理后的事件**：淌完整条流程之后事件长什么样，按事件详情的格式渲染。

如果事件在中途被丢掉，会看到一条提示：**事件在此环节被丢弃 / 抑制，后续处理器不会执行， 也不会产生通知**。这是正常结果，不是错误——横幅仍然是「执行成功」。

想改条件再来一次，点 **重新选择事件** / **重新配置样例事件** 回到第一步。

## 试跑和真实执行的差别[​](#试跑和真实执行的差别 "试跑和真实执行的差别的直接链接")

弹窗里那条提示说得很清楚：**试跑走的是 API 触发路径，会跳过线上的部分流程 （如过滤条件判定），结果可能与真实告警不完全一致。**

具体来说：

* **作用范围不参与判定。** 试跑不检查适用标签/适用属性，所以「试跑有输出」不代表 线上这条事件真的会进这条工作流。范围配错了，线上表现是执行记录里一条都没有；
* **用样例事件时更要复核。** 样例事件的标签是固定的四个，按其他标签判断的处理器 在这里必然走不到；
* **整条工作流的试跑会写一条执行记录**，触发模式是「API 触发」、触发者是你的用户名。 单个处理器的试跑不写记录。

所以试跑通过之后还有一步：挂到规则上、等一条真实事件、去 [执行记录](https://n9e.github.io/zh/docs/events/execution-records.md)确认。

## 下一步[​](#下一步 "下一步的直接链接")

* 把工作流挂上去：[事件 Pipeline](https://n9e.github.io/zh/docs/events/pipelines.md)
* 看真实事件的执行结果：[查看 Pipeline 执行记录](https://n9e.github.io/zh/docs/events/execution-records.md)
* 试跑通了线上不生效：[工作流试跑通过但线上不生效](https://n9e.github.io/zh/docs/troubleshooting/workflow-prod-fails.md)
* 通知那一侧也能这么测：[验证通知链路](https://n9e.github.io/zh/docs/notifications/test.md)