执行记录
夜莺 v9 工作流执行记录：审计每一次工作流被触发后的执行轨迹、各节点输入输出、失败原因，是排查工作流问题的核心入口。
概述
工作流执行记录 = 每次「工作流（Event Pipeline）」被触发后留下的审计 + 排错日志。
侧栏路径：告警 → 工作流 → 执行记录 Tab，URL /event-pipelines-executions。
每当一个工作流被触发（无论成功还是失败），都会生成一条执行记录：
- 成功时：记录每个节点（Processor）的输入、输出、耗时；
- 失败时：记录失败发生在哪个节点、错误信息是什么；
- 运行中：实时显示进度，便于看长耗时的工作流。
适用场景：
- 工作流"没生效"？查记录看是没触发还是触发了但失败；
- 想知道某个事件最终被哪条工作流处理过；
- 评估各节点性能（看
执行耗时），找出慢节点； - 出 P0 后回放完整的事件处理链路。
筛选 & 列表字段
页面顶部支持的过滤：
- 自动刷新：Off / 5s / 15s / 30s / 60s — 调试新工作流时建议开 5s。
- 关键字搜索：在工作流名称里搜。
- 触发模式：3 种 — 见下表。
- 状态：3 种 — 见下表。
| 列 | 含义 |
|---|---|
| 工作流名称 | 触发的那条工作流；点击列名跳转到该工作流编辑页 |
| 触发模式 | event（告警事件触发，最常见） / api（外部系统调 API 触发） / cron（定时器触发） |
| 状态 | running（运行中） / success（成功） / failed（失败，标红） |
| 开始时间 | 工作流开始执行的时间 |
| 结束时间 | 工作流结束时间；运行中显示为空 |
| 执行耗时 | duration_ms，单位毫秒；超过 5s 的需要关注是否有慢节点 |
| 触发者 | event：触发事件的告警规则名；api：调用方信息；cron：定时任务标识 |
执行详情：排查失败的核心入口
点击列表行打开执行详情，会展示每个节点的输入 / 输出 / 耗时 / 错误信息：
- 节点结果（NodeResults）：JSON 形式记录每个 Processor 的运行结果。可以一节点节点地看：
- 输入：上一节点传入的事件数据
- 输出：本节点处理后的结果
- 耗时：单节点的执行时间，找慢点用
- 错误信息（ErrorMessage + ErrorNode）：失败时着重看 —
ErrorNode指出失败发生在哪个节点的 ID，ErrorMessage是具体错误（API 超时、JSON 解析失败、查询数据源拿不到结果等）。 - 输入快照（InputsSnapshot）：触发工作流时的原始输入（脱敏后），用于回放调试。
调试新工作流的标准动作：在 工作流 编辑页保存后，去对应规则触发一次（或手工调 API），回到执行记录立刻看到一条
running→ 几秒后变success或failed。失败就点开看 ErrorNode，回工作流改那个节点。
数据保留
执行记录会自动清理：
- 默认保留 7 天（可在
n9e.toml配置文件里调整）； - 每天凌晨 6:00 自动跑清理任务，分批删除（每批 100 条，间隔 10ms 不影响数据库）；
- 想长期归档（合规 / 故障复盘）：通过 API 拉取后入仓自管，UI 内不支持手工延长保留期。
常见问题
Q1：我的工作流明明配好了，但执行记录里完全没看到它的条目？
A：说明根本没被触发。检查触发条件：
- 告警工作流（event 模式）：在 告警规则 的"流水线配置"区是否绑定了该工作流；事件标签是否命中工作流的过滤条件。
- 定时工作流（cron 模式）：在工作流编辑页的"触发器"是否启用了 cron 表达式。
- API 工作流（api 模式）：是否真的有外部系统调过 API（看夜莺 server 访问日志）。
Q2：状态一直显示 running 不结束，怎么回事？
A：常见原因有：
- 工作流里某个节点（如 callback、AI 摘要）调用外部服务长时间无响应，被卡住；
- 节点超时配置过大；
- 后端 worker 进程异常退出导致状态未更新。
排查思路：看 ErrorNode 是哪个节点，去该节点对应的服务端日志（如 callback 目标的接收方）确认是否真的在处理。如果是 worker 异常，重启告警引擎服务即可清理僵尸记录。
Q3：执行耗时 duration_ms 经常几秒甚至几十秒，正常吗？
A：取决于节点类型：
- 纯标签处理（重写、丰富、丢弃）：通常 < 100ms，几秒以上偏慢；
- 基于查询的节点（事件抑制 QD、附加信息 QD）：依赖底层数据源响应，1-3 秒正常；
- AI 摘要 / 截图 / Callback：调外部服务，3-30 秒都可能正常；
- 脚本执行：完全取决于脚本本身。
把执行耗时按节点拆开看（详情里每个节点都有自己的耗时），找出瓶颈。
Q4：能不能给执行失败配告警？
A：暂时没有官方"工作流失败就告警"的开关。绕一下：在工作流末尾加一个"Webhook 回调"节点，外部接收方汇总失败计数，再配一条针对该计数指标的告警规则即可。后续版本可能内置该能力。
