# 告警生命周期与 S1 / S2 / S3

告警事件由规则 + 标签集唯一标识，经历触发、持续、恢复三个阶段；S1 / S2 / S3 不改变机制，只告诉收到的人有多急。

最后校对于 2026-10-10

## 事件的一生[​](#事件的一生 "事件的一生的直接链接")

一个事件从产生到消失，会出现在三个地方：

1. **告警事件 → 活跃告警**：正在烧着的，还没恢复；
2. **通知记录**：这个事件被发给了谁、走的哪个媒介、成功还是失败；
3. **告警事件 → 历史告警**：恢复之后（或被手动删除后）落到这里，用于复盘。

活跃告警是「现在」，历史告警是「过去」。同一个事件在这两个列表里出现的顺序是 先活跃、后历史，不会同时在两边。

## 什么决定「是不是同一个告警」[​](#什么决定是不是同一个告警 "什么决定「是不是同一个告警」的直接链接")

不是规则，是**规则 + 标签集**。

`Host memory usage too high` 这一条规则跑在 5 台机器上，会产生 **5 个独立事件**， 因为它们的 `ident` 标签不同。其中一台恢复了，只有那一个事件恢复，其余四个还烧着。

反过来，标签集完全相同的一次次触发，会被认为是同一个告警的延续，而不是新告警。 所以**标签集设计不好，会直接导致告警合并不对**—— 见[标签、注解与身份](https://n9e.github.io/zh/docs/concepts/labels-annotations.md)。

## 三个级别是给人看的[​](#三个级别是给人看的 "三个级别是给人看的的直接链接")

夜莺不强制 S1/S2/S3 的含义，但如果团队里没有共识，级别就退化成装饰。 一个能用的约定是**按「要不要现在处理」来分**，而不是按技术严重程度：

| 级别   | 含义                           | 典型投递方式       |
| ------ | ------------------------------ | ------------------ |
| **S1** | 现在就得有人处理，可以半夜叫醒 | 电话、短信         |
| **S2** | 今天工作时间内要处理           | 群消息 + @人       |
| **S3** | 知道就行，不用打断任何人       | 群消息，或只进看板 |

判断一条规则该定几级，问一句就够了：**「凌晨三点收到这条，值得起床吗？」** 不值得，就不是 S1。

级别在夜莺里的实际作用有两个：一是通知规则可以按级别分流到不同媒介； 二是同一条规则的多档阈值可以配不同级别，配合抑制只发最严重的那条。

## 手动干预[​](#手动干预 "手动干预的直接链接")

活跃告警列表上可以对事件做两件事：

* **屏蔽**：直接从这个事件生成一条屏蔽规则，止血用；
* **删除**：把它从活跃列表里移走。注意这不解决根因， 条件还成立的话下个判定周期它会再回来。

## 相关[​](#相关 "相关的直接链接")

* [判定、恢复与状态变化](https://n9e.github.io/zh/docs/concepts/evaluation.md)
* [活跃告警与历史告警](https://n9e.github.io/zh/docs/events/active-historical.md)
* [标签、注解与级别](https://n9e.github.io/zh/docs/alerting/labels-severity.md)