跳到主要内容

用模拟事件试跑

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

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

试跑入口在哪​

两处，作用范围不同：

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

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

历史事件还是样例事件​

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

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

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

__name__=cpu_usage_idle
ident=mock-host-01
env=prod
service=web

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

读试跑结果​

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

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

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

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

试跑和真实执行的差别​

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

具体来说：

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

所以试跑通过之后还有一步：挂到规则上、等一条真实事件、去 执行记录确认。

下一步​

本页目录