标签、附加信息与级别
给路由用的标签、在通知里读得顺的附加信息，以及有意识地选 S1 / S2 / S3。
这页办完你会得到：规则产生的事件上，既有路由要用的标签，也有凌晨三点那个人需要的文字， 还有一个在你整套规则里含义一致的级别。
三种能挂在事件上的东西
它们在不同的步骤里，行为也不一样，搞混了就是「通知规则怎么匹配不上」的常见原因：
| 附加标签 | 附加信息 | 级别 | |
|---|---|---|---|
| 在哪儿 | 第 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 | 用途 |
|---|---|
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}}
完整的变量列表见模板与变量。
级别
规则里的每条查询都带一个级别，而它是决定你的告警日子好不好过的最关键的一个字段。
| 站得住脚的含义 | |
|---|---|
| S1（一级 / Critical） | 用户此刻已经受影响，必须有人在几分钟内处理。凌晨三点打电话是可以接受的 |
| S2（二级 / Warning） | 没人管的话会变成 S1，但不是今晚。工作时间、群消息 |
| S3（三级 / Info） | 值得记下来定期看，不值得打断任何人 |
级别本身不路由任何东西。它之所以能路由，是因为你的通知规则按它匹配—— 也正因如此，这几个定义必须在整套规则里保持一致。一半规则拿 S1 表示「紧急」、 另一半拿它表示「重要」，再怎么配路由也救不回来。
怎么选
按顺序问两个问题：
- 需要人吗？ 不需要就是 S3——记下来、画进图、每周看一次。 大多数磁盘用量和证书过期的告警在快到线之前都是 S3。
- 需要人现在就来吗？ 不需要就是 S2。
剩下的才是 S1。在一套健康的规则里，这是很小的一部分：用户已经感知到的， 或者一小时内就会感知到的。
有两个习惯能让它保持诚实。回顾最近一个月真正把人叫起来的那些告警， 把没人立刻处理的降级——见规则设计实践。 以及，一条规则需要两个级别时，用一条规则里的多个级别配上级别抑制， 而不是写两条早晚会各走各路的规则。
下一步
- 这些字段在表单里的位置：指标规则
- 路由拿它们做什么：通知规则
- 事后改写标签：改写标签与补充上下文
- 背后的模型：标签与附加信息