基础配置

从实际使用场景出发，介绍夜莺告警规则的基础配置：规则名称、业务组、附加标签与备注，以及如何用模板变量让告警信息一目了然。

概述

基础配置位于告警规则编辑页的第 1 步"基础配置"区块，决定一条规则叫什么、归哪个业务组管、产生的告警事件带什么标记：

字段	必填	说明
规则名称	是	告警事件的标题，支持模板变量；同一业务组内不能重名
业务组	是	规则的归属与权限边界，创建时选定，保存后不可更改
附加标签	否	附加到该规则产生的所有告警事件上的自定义标签，格式 `key=value`
备注	否	告警事件的补充说明，支持模板变量，适合放处置建议、文档链接

这几个字段不影响规则什么时候触发（那由数据源和告警条件决定），但直接决定告警事件在事件列表、通知消息里长什么样，以及后续能否被精确地筛选、屏蔽、订阅和路由。建规则时花一分钟想清楚，能省掉以后翻详情、猜来源的大量时间。

下面按实际使用场景介绍各字段的用法。

一条主机监控规则往往覆盖几十台机器。如果名称写死成"CPU 空闲率过低"，收到的所有通知标题都长一样，还得点开详情才知道是哪台机器。在名称里引用模板变量即可解决：

{{$labels.ident}} CPU 空闲率过低

配合附加标签和备注，一个典型的填写示例：

基础配置区块填写示例

变量在事件产生时渲染：$labels 是该事件的标签集合（指标自身标签 + 附加标签），$value 是触发时值，语法与消息模板一致。上面的名称在事件里会渲染成 web-01.bj CPU 空闲率过低。

几条实用约定：

名称建议包含"对象 + 现象"两个要素，如 {{$labels.ident}} 磁盘使用率超过 85%，标题即结论；
规则列表页显示的始终是原始模板（带 {{}}），只有告警事件里才是渲染后的值；
引用的标签在事件中不存在时渲染为空字符串；模板语法本身写错（如花括号不配对）时，事件标题会显示 failed to parse rule name，规则照常触发，但要尽快修正。

半夜收到告警，最值钱的信息是"现在该干什么"。把处置建议写进备注，并用变量带上现场值：

机器 {{$labels.ident}} 的 CPU 空闲率已降至 {{$value}}%。请先登录机器执行 top 定位高 CPU 进程，处理手册见 https://wiki.example.com/runbook/high-cpu

事件产生后，详情页里名称和备注都已渲染成实际值：

告警事件详情-变量渲染效果

备注会跟随事件进入通知消息——内置消息模板默认展示"规则备注"字段（{{$event.RuleNote}}），值班同学在 IM 里就能直接看到处置指引，不必再翻 wiki 找预案。

指标自带的标签（ident、cpu 等）描述"数据从哪来"，但日常运维更常用的筛选维度是"属于哪个业务、哪个环境、归谁管"。附加标签就是给事件补上这层业务语义，格式 key=value，空格或回车分隔多个：

规则触发的每条事件都会带上这些标签，在多个地方发挥作用：

筛选事件。 活跃告警、历史告警的搜索框直接输入 env=prod 即可过滤：

活跃告警-按附加标签过滤

匹配下游规则。 屏蔽规则、订阅规则、通知规则都能按标签匹配事件——比如订阅规则把 team=sre 的事件单独转发给 SRE 群，屏蔽规则对 env=test 的事件一键静音。指标标签可能随采集配置变化，而附加标签由规则保证一定存在，拿它做匹配条件最稳。

几条判定规则：

业务组决定谁能看到、修改这条规则——只有业务组成员才能管理组内规则。新建规则时默认为当前所在业务组，可在下拉框中切换；保存后不可更改，编辑时即使改动该字段也不会生效（服务端会保留原业务组）。

建到了错误的业务组：在规则列表页勾选规则，更多操作 → 克隆到其他业务组，克隆过去后删除原规则即可。注意克隆产生的是新规则，已产生的历史事件仍挂在原业务组下；
批量维护：规则多了以后，附加标签、备注这类字段不必逐条编辑——列表页勾选多条规则，更多操作 → 更新告警规则，可按字段批量更新。