告警生命周期与 S1 / S2 / S3
告警事件由规则 + 标签集唯一标识，经历触发、持续、恢复三个阶段；S1 / S2 / S3 不改变机制，只告诉收到的人有多急。
事件的一生
一个事件从产生到消失，会出现在三个地方：
- 告警事件 → 活跃告警：正在烧着的，还没恢复；
- 通知记录：这个事件被发给了谁、走的哪个媒介、成功还是失败；
- 告警事件 → 历史告警：恢复之后（或被手动删除后）落到这里，用于复盘。
活跃告警是「现在」，历史告警是「过去」。同一个事件在这两个列表里出现的顺序是 先活跃、后历史，不会同时在两边。
什么决定「是不是同一个告警」
不是规则，是规则 + 标签集。
Host memory usage too high 这一条规则跑在 5 台机器上，会产生 5 个独立事件，
因为它们的 ident 标签不同。其中一台恢复了，只有那一个事件恢复，其余四个还烧着。
反过来，标签集完全相同的一次次触发，会被认为是同一个告警的延续，而不是新告警。 所以标签集设计不好，会直接导致告警合并不对—— 见标签、注解与身份。
三个级别是给人看的
夜莺不强制 S1/S2/S3 的含义，但如果团队里没有共识，级别就退化成装饰。 一个能用的约定是按「要不要现在处理」来分，而不是按技术严重程度：
| 级别 | 含义 | 典型投递方式 |
|---|---|---|
| S1 | 现在就得有人处理，可以半夜叫醒 | 电话、短信 |
| S2 | 今天工作时间内要处理 | 群消息 + @人 |
| S3 | 知道就行，不用打断任何人 | 群消息，或只进看板 |
判断一条规则该定几级，问一句就够了：「凌晨三点收到这条，值得起床吗？」 不值得，就不是 S1。
级别在夜莺里的实际作用有两个：一是通知规则可以按级别分流到不同媒介； 二是同一条规则的多档阈值可以配不同级别，配合抑制只发最严重的那条。
手动干预
活跃告警列表上可以对事件做两件事：
- 屏蔽：直接从这个事件生成一条屏蔽规则，止血用；
- 删除：把它从活跃列表里移走。注意这不解决根因， 条件还成立的话下个判定周期它会再回来。