# 标签、附加信息与级别

给路由用的标签、在通知里读得顺的附加信息，以及有意识地选 S1 / S2 / S3。

最后校对于 2026-10-10

这页办完你会得到：规则产生的事件上，既有路由要用的标签，也有凌晨三点那个人需要的文字， 还有一个在你整套规则里含义一致的级别。

## 三种能挂在事件上的东西[​](#三种能挂在事件上的东西 "三种能挂在事件上的东西的直接链接")

它们在不同的步骤里，行为也不一样，搞混了就是「通知规则怎么匹配不上」的常见原因：

|              | 附加标签                               | 附加信息             | 级别                |
| ------------ | -------------------------------------- | -------------------- | ------------------- |
| 在哪儿       | 第 1 步 基础配置                       | 第 6 步 事件处理     | 第 3 步，每条查询上 |
| 形态         | `key=value`                            | `key: 文本`          | S1 / S2 / S3        |
| 能被机器匹配 | **能**——屏蔽、订阅、通知规则都按它匹配 | 不能                 | 能                  |
| 逐事件渲染   | 不，固定字符串                         | 是，模板变量会展开   | 不                  |
| 拿来干什么   | 路由和筛选                             | 给读消息的人的上下文 | 决定要不要叫醒人    |

一句话判断：**要被匹配的，是标签；只需要被读的，是附加信息。**

## 附加标签[​](#附加标签 "附加标签的直接链接")

**基础配置 → 附加标签**收 `key=value`，用回车或空格分隔。它们会追加到这条规则产生的每条事件上， 叠在查询本身返回的标签之上。

表单会强制格式：`key=value`，key 以字母或下划线开头、只能由字母数字下划线组成， 单条不超过 64 个字符，同一条规则里 key 不能重复。标签里的空格会被去掉。

值得放在这里的东西：

```
team=infra

service=mysql

env=prod
```

这些是查询本身不可能知道的。`ident` 和 `instance` 来自指标，「归哪个团队」不来自指标。 后面的一切都按标签匹配：

* 通知规则按它挑接收人和媒介；
* 屏蔽规则按它静音；
* 订阅规则让别的团队按它把事件捞走；
* 事件列表按它筛。

两点提醒。别在这里编码一个逐序列变化的值——那是查询自己的标签该干的事。 以及，词表要小、要统一：一部分规则写 `team=infra`、另一部分写 `owner=infra-team`， 每条通知规则就都得同时认识这两个。

## 附加信息[​](#附加信息 "附加信息的直接链接")

**事件处理 → 附加信息**收 `key: 值`。它们在事件产生时渲染，展示在事件详情页， 也能被通知消息引用。

值支持模板变量，所以是逐事件的：

```
summary          {{$labels.ident}} 内存使用率 {{$value | printf "%.1f"}}%

dashboard_url    https://grafana.example.com/d/host?var-ident={{$labels.ident}}
```

`$labels.<名字>` 是事件上的任意标签，`$value` 是触发值。引用了事件上没有的标签会渲染成空字符串。 模板写坏了会渲染成 `failed to parse annotations`——规则照常触发，但赶紧改。

以 `http` 开头的值，在事件详情页上会渲染成可点击的链接。

### 四个约定俗成的 key[​](#四个约定俗成的-key "四个约定俗成的 key的直接链接")

key 可以随便起，但表单推荐了四个，其中一个是特殊的：

| Key               | 用途                                                                         |
| ----------------- | ---------------------------------------------------------------------------- |
| `summary`         | 一句话上下文：什么坏了、影响谁、为什么要紧                                   |
| `runbook_url`     | 值班的人第一个该打开的文档                                                   |
| `dashboard_url`   | 能看到这个问题所处环境的那张图                                               |
| `recovery_promql` | **特殊。** 事件恢复时会执行这条 PromQL，把结果写进 `recovery_value` 附加信息 |

`recovery_promql` 存在是因为一个真实的缺口：Prometheus 类规则的恢复， 意味着查询不再返回那条序列，所以没有值可报。在这里填一条不带阈值的表达式——

```
recovery_promql    mem_used_percent{ident="{{$labels.ident}}"}
```

——恢复通知里就能说出「现在是多少」。查询失败时会写一条 `recovery_promql_error`， 不会因此让恢复失败。

### 在通知里引用[​](#在通知里引用 "在通知里引用的直接链接")

事件详情页会自动逐项展示附加信息。想把某一项放进消息，在模板里引用它：

```
处理手册：{{$event.AnnotationsJSON.runbook_url}}
```

完整的变量列表见[模板与变量](https://n9e.github.io/zh/docs/notifications/templates.md)。

## 级别[​](#级别 "级别的直接链接")

规则里的每条查询都带一个级别，而它是决定你的告警日子好不好过的最关键的一个字段。

|                           | 站得住脚的含义                                                         |
| ------------------------- | ---------------------------------------------------------------------- |
| **S1（一级 / Critical）** | 用户此刻已经受影响，必须有人在几分钟内处理。凌晨三点打电话是可以接受的 |
| **S2（二级 / Warning）**  | 没人管的话会变成 S1，但不是今晚。工作时间、群消息                      |
| **S3（三级 / Info）**     | 值得记下来定期看，不值得打断任何人                                     |

级别本身不路由任何东西。它之所以能路由，是因为你的通知规则按它匹配—— 也正因如此，这几个定义必须在整套规则里保持一致。一半规则拿 S1 表示「紧急」、 另一半拿它表示「重要」，再怎么配路由也救不回来。

### 怎么选[​](#怎么选 "怎么选的直接链接")

按顺序问两个问题：

1. **需要人吗？** 不需要就是 S3——记下来、画进图、每周看一次。 大多数磁盘用量和证书过期的告警在快到线之前都是 S3。
2. **需要人现在就来吗？** 不需要就是 S2。

剩下的才是 S1。在一套健康的规则里，这是很小的一部分：用户已经感知到的， 或者一小时内就会感知到的。

有两个习惯能让它保持诚实。回顾最近一个月真正把人叫起来的那些告警， 把没人立刻处理的降级——见[规则设计实践](https://n9e.github.io/zh/docs/alerting/best-practices.md)。 以及，一条规则需要两个级别时，用[一条规则里的多个级别](https://n9e.github.io/zh/docs/alerting/metric-rules.md)配上级别抑制， 而不是写两条早晚会各走各路的规则。

## 下一步[​](#下一步 "下一步的直接链接")

* 这些字段在表单里的位置：[指标规则](https://n9e.github.io/zh/docs/alerting/metric-rules.md)
* 路由拿它们做什么：[通知规则](https://n9e.github.io/zh/docs/notifications/rules.md)
* 事后改写标签：[改写标签与补充上下文](https://n9e.github.io/zh/docs/events/relabel-enrich.md)
* 背后的模型：[标签与附加信息](https://n9e.github.io/zh/docs/concepts/labels-annotations.md)