本节并无太多要讲的内容，菜单里的【活跃告警】，就是列出了当前所有的未恢复活跃告警，如果某个告警恢复了，就会自动从这个列表中删除，这个页面还是蛮重要的，可以作为日常巡检的一项，每天上下班的时候都看一下，看看哪些事件还没恢复，漏了处理。

活跃告警可以删除，这个操作比较危险，一定要弄明白原理。通常情况下，我们是无需手工删除的，比如cpu_usage_idle告警了，会自动创建一条告警事件，当cpu_usage_idle的值恢复了，即这条告警变成恢复状态了，系统就会自动从活跃告警中删除，所以，通常情况下，就让系统自动处理就好了。

但是，如果某个指标的标签发生变化，或者机器下线，相关的告警就再也无法恢复了，这个不好理解，详细解释一下：

指标标签发生变化

比如这个告警规则：cpu_usage_idle{cpu="cpu-total"} < 25，拿着这个promql去promdash查询，得到的结果可以看到，有cpu和ident两个标签，ident表示的监控对象，此时，如果我们去对象管理页面，修改这个监控对象的标签，后面新上报的监控数据，就会自动打上新标签，继续拿着刚才的promql去promdash查询，会发现表格里很快会出现新的记录，和之前的记录并存，从时序库的角度来看，就是多了一条新的series。

就相当于：之前有个series告警了，还没恢复呢，又来了一个新的series，老的series不再上报监控数据，所以老的告警事件就永远都不会恢复了。当然，我们可以调整一下这个promql，忽略掉其他的额外的标签，比如avg(cpu_usage_idle{cpu="cpu-total"}) by (ident)，这样一来，即使在监控对象的页面修改了标签，这个新的promql永远都只有ident这一个标签，因为这个新的promql是根据ident做了聚合。虽然标签稳定了，但是本人不推荐大家这么做，这样做了之后，cpu="cpu-total"这个标签就丢了。

机器下线

比如某个机器的某个指标报警了，比如内存利用率的一个指标，还没恢复呢，这个机器下线了，上面的客户端也不再上报监控数据了，那这个告警事件就永远都不会消失了，这种情况，我们知道是怎么回事，就可以手工删除对应的告警事件。省的放那没用，还碍眼。

另外，左侧的业务组旁边，带有一个数字徽章，表示的是这个业务组下的活跃告警数量，这种方式可以让我们快速知道哪个业务组下的告警规则触发了及其活跃事件数量。