业务负责人问：“昨晚 CPU 明明打满了，为什么没有告警？”最让值班人员难受的答案，不是“配置错了”，而是“现在还不知道”。
等问题被发现时，现场往往已经过去。值班人员只能重新查询历史指标、核对规则配置、翻服务日志，然后逐项猜测：是不是数据源超时，是不是 for 持续时间没到，是不是命中了屏蔽规则，还是通知链路出了问题。即使最后找到一个可能原因，也很难证明它就是当时的真实情况。
夜莺 v9.1 增加的告警评估执行记录，就是为这类问题准备的。它像告警引擎的“行车记录仪”，把每个评估周期的重要现场保留下来，让排障从猜测变成回看。直接收益不是多了一份日志，而是少开一次没有证据的复盘会。
一次告警评估，到底发生了什么
一条告警规则并不是简单地执行一次查询，然后判断结果是否大于阈值。真实过程至少包含三个层次。
第一层是查询。告警引擎在什么时间、向哪个数据源执行了什么查询，返回了多少条序列，查询是否报错，决定了后续判断有没有输入。
第二层是判定。数据存在不等于应该告警，还要看阈值、持续时间、恢复条件和级别抑制。某个瞬时值越过阈值，但没有持续到规定时间，规则不会立刻产生告警。
第三层是事件处理。异常点生成事件后，还可能命中屏蔽规则，被事件流水线丢弃，或者因为尚未到重复通知时间而不再发送消息。
过去这些信息散落在配置、指标和运行日志里。v9.1 把它们整理成一条评估记录：本轮查到了什么、判定出了什么、事件后来去了哪里。用户可以从告警规则页面选择时间点，查看该周期的查询结果、异常与恢复数量，以及每个事件经过的处理阶段。
同样是“没收到”，背后可能是七种问题
假设 CPU 指标已经超过阈值，但值班人员没有收到消息。执行记录可能给出完全不同的结论：
- 查询没有返回目标机器，问题在数据或标签匹配；
- 指标超过阈值，但尚未满足持续时间；
- 事件命中了“仅屏蔽通知”，因此事件存在但消息没有发送；
- 更高级别事件已经触发，当前级别被抑制；
- 距离上次通知未达到重复发送间隔；
- 事件流水线主动丢弃了事件；
- 事件队列已满，入队失败。
这些情况对用户的表象都可能是“没收到告警”，处理方法却完全不同。执行记录的价值，不是多保存一份日志，而是给出告警引擎当时的判断依据和处理轨迹。
这会改变团队处理问题的顺序。过去先找人、再翻日志、最后尝试复现；现在可以先打开对应周期的记录，判断问题属于数据、规则还是事件分发，再把任务交给真正负责的团队。对使用统一告警平台的企业来说，这还能减少监控团队、业务团队和通知平台之间的来回推诿。
为什么记录写在本地磁盘
告警评估频率通常很高。如果把每一次查询现场都写入业务数据库，不仅会增加数据库压力，还会让一项用于排障的功能反过来干扰告警主流程。
夜莺把评估记录写在告警引擎本地磁盘，按规则、数据源和时间组织，滚动后压缩保存。默认每次查询最多记录 100 条序列、每条 60 个点；默认保留 192 小时，也就是 8 天；总磁盘上限 20GB，单条规则每天最多使用 1024MB。查询侧还有并发和返回体积限制，避免排障查询影响正常评估。
这套默认值适合先把功能跑起来，但不是所有环境都应该原样照搬。规则数量大、评估频率高或者告警引擎磁盘紧张的团队，应在升级前评估容量，按需要调低保留时间和磁盘上限；完全不需要时也可以关闭。
换句话说，可回放是有成本的，只是这笔成本是可见、可限制的磁盘空间；没有执行记录的成本，则是每次问题发生后都重新花人力还原现场。多数告警量较大的团队，后者更贵。
它和“测试触发”有什么区别
测试触发面向上线前：用当前规则主动演练查询、事件处理和通知链路，回答“这份配置现在能不能工作”。
评估执行记录面向运行后：保存真实评估周期的现场，回答“昨天那个时间点实际发生了什么”。前者是演习，后者是回放。两项能力配合使用，才能同时覆盖配置发布前的验证和故障发生后的追查。
建议这样使用
升级到 v9.1 后，可以先做三件事：确认各告警引擎节点的磁盘余量；根据规则规模调整保留时间和总量上限；挑一条高频规则，熟悉如何从执行记录区分查询、判定和事件处理问题。之后再把“查看评估记录”加入漏报排障和事故复盘流程。
监控系统的可信度，不只来自“能发出告警”，也来自“能解释为什么发、为什么没发”。没有这层解释能力，团队只能选择相信系统，或者在每次事故后重新怀疑系统；当告警判断可以被回看，规则优化和故障复盘才有可靠依据。
