打开告警规则页面，看到一排已经启用的规则，旁边没有告警。这时，我们能不能放心地说：系统运行正常？
做过监控的工程师，通常会多问一句：这些规则最近一次执行成功是什么时候？没有触发告警，可能是业务指标没有越过阈值，也可能是查询已经失败、执行节点离线，或者规则根本没有匹配到数据源。只看配置是否启用、通知有没有响，很难区分这些情况。
最近，Flashduty Monitors 优化了告警规则页面：每条规则现在都能直接看到运行状态和当前活跃告警数量；有活跃告警或运行问题的分组，会在左侧树上呈现提示，并向父级汇总。我们希望这张页面能回答一个日常值班里普遍性的问题：哪些业务正在报警，哪些检测需要修复，我应该先点开哪里？
先把“业务异常”和“检测异常”分清楚
告警规则本身也是一段周期执行的程序：查询数据、计算结果、判断条件，再维护告警状态。这段程序有没有正常工作，和它有没有发现业务问题，是两个独立维度。
以一条 checkout 5xx 错误率 > 5% 的规则为例。如果查询和计算成功，三个实例满足触发条件，这条规则应该同时显示“运行正常”和“3 条活跃告警”。绿色运行状态说明检测正在工作；旁边的告警数量说明业务有问题。把它们合并成一个红绿灯，读者就很难判断自己应该去查业务，还是去修监控。
反过来，一条 P99 延迟规则查询超时，即使当前活跃告警数量是 0，也需要明确显示“执行异常”。这时我们还没有足够证据判断业务是否正常，应当先恢复检测能力。已经存在的活跃告警，也可能与新的执行异常同时出现；两个维度都要保留。
图 1：三种常见组合。“暂未发现告警”的含义仍然取决于规则覆盖范围和触发条件。
在新的规则列表里，这个区别落成了两列。点击“状态”，打开运行详情；点击“活跃告警”的数量，进入这条规则的活跃告警列表。每个入口对应一个明确的问题，值班同学不需要先猜这个状态到底在表达什么。
图 2：产品界面示意，使用虚构数据，简化了无关列和导航。第一条规则正常执行并触发 3 条告警，第二条规则执行异常、当前活跃告警为 0。
从分组树开始，先找到需要关注的业务
规则多起来之后，逐页扫表格并不适合日常巡检。团队通常已经按业务、环境或基础设施组织了规则，例如“生产环境 → 交易服务 → checkout”。这些分组本来就反映了人的职责范围，问题也应该沿着同样的结构被看见。
这次我们给分组树加入了问题提示：分组内的规则存在活跃告警，或者出现执行异常、Edge 离线、状态过期、未匹配数据源等运行问题时，节点图标会变成红色警示三角。这个提示还会向可见的父级传播。即使 checkout 分组没有展开，交易服务及其上层分组也能提示这里有事情需要关注。
这里有一个刻意保留的层次：树上的提示负责引导注意力，规则列表负责说明问题类型。 分组图标不堆告警数量，也不试图把整棵树变成统计报表。工程师看到父级提示后，沿着分组向下定位，再看具体规则的状态和告警数，就能决定下一步动作。
同时，等待首次运行、配置待生效和规则已停用，本身不会因为这个运行状态就让分组亮起问题提示。新建或刚修改的规则有正常的传播与等待过程，把这些过程都画成异常，只会让树失去筛选价值。如果这些规则仍有活跃告警，分组依然会提示。
全局视角也遵循已有的权限边界。健康摘要依据当前用户有权读取的规则计算，再沿可见目录汇总。拥有全局读取权限的运维负责人，可以查看全局规则中的告警与运行问题；业务团队则关注自己的范围。页面能帮助大家共享问题位置，同时保留团队之间的权限隔离。
从一个数量，追到具体受影响对象
看到某条规则旁边有数字 3，下一步通常是确认这三个告警分别对应什么对象。新的入口会切换到“活跃告警”页签，并自动带入该规则的筛选条件，保留当前分组上下文。
在下面的示例里，同一条 checkout 错误率规则对应三个活跃告警，分别来自 checkout-01、checkout-02 和 checkout-03。列表可以展示严重程度、告警标题、Job、Instance 和最后更新时间，也可以通过筛选继续缩小范围。工程师可以先确定受影响对象，再点开告警查看详情。
图 3：产品界面示意，使用虚构数据。规则筛选条件自动带入，三个告警与前一张图中的数量对应。
这个数字表达的是当前活跃告警的数量，不是规则执行次数，也不是通知发送次数。同一告警即使产生重复通知，也不应该被读成出现了更多受影响对象。对于值班交接，这个区别很实用：交接的人需要知道还有哪些告警在持续，而不只是今天一共响过多少次。
规则执行异常，要能继续查下去
状态标签只是排障入口。真正需要解释的是：查询为什么失败，失败持续了多久，执行这条规则的节点是不是还在线？
点击规则状态后，运行详情会展示最近执行时间、执行耗时、执行结果、查询结果数、最近成功时间和连续失败次数。存在错误时，页面会显示错误类型与摘要；还可以查看负责执行的 Edge 集群、实例、在线状态及最近心跳。这样，规则的业务配置和它实际运行的情况能放在同一处判断。
下面仍然使用虚构的 checkout 场景。延迟规则的查询连续三次超时，但执行节点在线，最近成功发生在 14:05。仅凭“0 条活跃告警”无法发现这个问题；展开运行详情后，排障方向就明确了：从数据源查询与连通性入手，而不是把业务延迟正常作为既定结论。
图 4：产品界面示意，使用虚构数据。这里表达“检测查询失败”，并未推断 checkout 业务延迟是否超标。
一条规则如果关联多个数据源，页面还需要避免另一个容易误导人的情况：其中一个执行成功，就把整条规则显示成正常。Flashduty Monitors 会聚合各数据源的运行情况，优先展示需要关注的状态；详情里的数据源选择器也会优先列出需要关注的项。工程师切换到正常的数据源时，标题区仍保留规则整体状态，避免“列表说异常，点进去却看起来正常”的错位。
详情还提供执行历史入口，可以继续查看失败、执行恢复、产生事件和正常采样记录。当前状态用于判断现在该关注什么，历史记录用于补充变化过程。这里的历史包含正常执行采样，不能把它当成每个执行周期的完整流水。
页面上的状态，背后需要一致的判断
这类功能看起来只是加两列、换几个图标，但真正决定它是否可信的，是不同入口对同一条规则能否给出一致的解释。
在实现上，Edge 上报规则在具体数据源上的执行结果，中心端结合规则配置版本、执行状态、数据源匹配范围和执行节点心跳，计算列表需要展示的状态。规则列表、运行详情的数据源列表，以及分组健康摘要复用这套运行状态判断。活跃告警则依据当前告警记录单独统计，再与运行状态一起构成分组是否需要关注的依据。
状态还必须有时间语义。曾经执行成功，不代表现在仍然正常：超过预期时间没有新的执行状态，页面会标为“状态已过期”，并明确告诉用户正在展示最后一次已知结果。中心端保存了新配置，而 Edge 尚未上报对应版本时，会呈现“配置待生效”。尚未收到状态时，则显示等待。我们希望页面如实表达它掌握的证据，避免把等待或旧结果伪装成当前正常。
这也意味着，页面展示的是已上报、已汇总的当前视图，有执行和传播时间。规则列表、运行详情与分组树有各自的刷新时机，并不是所有图标都承诺同一瞬间更新。对值班工作来说，能够看见最近执行、状态是否过期、配置是否已生效，比一个没有时间依据的绿色图标更有用。
让告警规则页成为每天愿意打开的工作页面
我们希望工程师打开这张页面时，能顺着已有的业务分组找到问题：先看哪里需要关注，再区分业务触发告警还是检测执行异常，最后进入具体告警或运行详情继续处理。配置、执行和告警之间有了直接的入口，规则也就更容易持续维护。
对正在评估监控产品的团队，这也是一个值得实际验证的场景：选一组熟悉的业务规则，检查每条规则的最近执行与当前活跃告警，再确认分组树能否把需要关注的位置呈现出来。尤其要看看那些安静的规则——安静是否来自一次正常检测，应该有证据可查。
如果你正在管理多个业务团队的告警规则，欢迎用自己的分组方式体验 Flashduty Monitors，或联系我们安排演示。我们愿意从你们每天怎样巡检、怎样交接、怎样排查一条失效规则开始，一起判断这张页面能帮上什么忙。
