导入、导出与复用
以 JSON 在环境之间搬运规则，并纳入版本控制。
这页办完你会得到：一批规则以 JSON 文件的形式离开一套环境、落到另一套环境里， 并且你清楚地知道哪些字段没跟着一起过去。
导出一批规则
告警通知 → 规则管理，勾选要导出的规则，然后更多操作 → 导出规则 JSON。
弹窗里就是 JSON——一个数组，一条规则一个对象。拿走之前可以直接在框里改，
然后下载 JSON（存成 download.json）或者复制 JSON 内容到剪贴板。
同一个菜单里还有导出（CSV），把选中规则的全部字段导成表格。那个是用来看和评审的， CSV 不能反向导入。
导出会主动丢掉什么
这份 JSON 不是规则的逐字节副本。只在源环境里有意义的字段会被剥掉：id、group_id、
创建人/更新人和时间戳、已废弃的 datasource_ids，以及旧版通知字段。
其中有两项会改变导入后的行为，要提前有准备：
| 丢掉的 | 导入后的后果 |
|---|---|
enable_stimes / enable_etimes / enable_days_of_weeks | 生效时间窗口丢失——导入后的规则变成全天全周生效 |
disabled | 由导入弹窗自己的启用开关决定，而那个开关默认是关的 |
决定规则对什么告警的东西全部保留：name、cate、prod、rule_config（查询、阈值、
级别、抑制）、append_tags、annotations、cron_pattern、prom_for_duration、
recover_duration、notify_repeat_step、notify_max_number、enable_in_bg、time_zone、
datasource_queries、pipeline_configs。
也就是说：这趟往返对调度是有损的，对判定逻辑是无损的。导入之后，把每条规则的第 5 步走一遍， 原本有生效窗口的补回去。
导入到业务组
在左侧树里选好目标业务组，点导入。弹窗有三个 tab，中间那个导入告警规则吃的就是 你导出的 JSON。
| 字段 | 怎么填 |
|---|---|
| 内容 | 把数组粘进来。单个对象也接受，会自动包成数组 |
| 数据源类型 | 只读。从你 JSON 里的 cate 推导出来 |
| 数据源筛选 | 把规则重新指向这套环境的数据源。 文件里的 id 在这里没有意义 |
| 启用 | 默认关。就让它关着，把规则检查一遍再启用 |
| 强制覆盖同名 | 默认关。打开后，本组内同名的规则被原地替换，保留原 id 和创建记录；关着的话，撞名会作为错误报出来，那条跳过 |
一次导入里的所有规则必须是同一种数据源类型。 一条 Prometheus 规则和一条 MySQL 规则混在 一次粘贴里，提交前就会被拦下——拆成两次导入。
点导入。预期结果：一张结果表，每条规则一行，显示规则名和「导入结果」—— 成功时结果列为空，失败时给出错误信息。
通知配置不会被带过来。导入时会清掉旧版的媒介和接收组字段，规则上也不会挂任何通知规则， 所以导入之后要自己挂一条，否则什么也发不出去。见通知规则。
导入 Prometheus 原生告警规则
第三个 tab 导入 Prometheus 告警规则吃的是 Prometheus 的规则文件 YAML——
就是你放进 rules.yml 的那段原文：
groups:
- name: example
rules:
- alert: HighRequestLatency
expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
for: 10m
labels:
severity: page
annotations:
summary: High request latency
裸的 rules 列表、单条 rule 对象也接受，会被包成一个合成的组。选好数据源， 决定要不要直接启用，提交。
字段怎么映射
| Prometheus | 夜莺 |
|---|---|
alert | 规则名称 |
expr | rule_config 里唯一的那条查询 |
for | 持续时长。解析不了或没写，兜底 60 秒 |
组上的 interval | 执行频率，写成 @every Ns。组里没写就是 60 秒 |
labels.severity | 级别。critical / error / fatal / page / sev1 → S1；warning / warn / sev2 → S2；info / notice / sev3 → S3。认不出来的值、以及压根没这个标签的规则，一律按 S2 |
labels 里其余每一项 | 一条 key=value 附加标签 |
annotations | 原样搬成附加信息 |
文件里的 record 规则会被静默丢弃。 只有带 alert: 的条目会被转换——
夜莺里对应的能力见记录规则。keep_firing_for、limit
也不会转换。
把规则纳入版本控制
导出的 JSON 足够稳定，可以拿来做 diff，于是就有了一套能跑的评审流程：
- 在预发环境用界面改规则，表单会帮你校验，模拟触发能证明它真的能跑；
- 导出这个组的规则，把 JSON 提交进仓库；
- 像评审其他改动一样评审这份 diff；
- 打开强制覆盖同名导入到生产，于是合并是按名字做的。
有两件事要守住纪律。这套流程里规则名就是主键——在预发里改个名，到生产就是新建一条， 而不是更新原来那条。以及，生效窗口不会跟着导出走，所以要么让所有规则都全天生效， 要么把窗口记在某个导入时一定会看到的地方。
不用文件的复制方式
在同一套夜莺里搬规则，别绕 JSON：
- 更多操作 → 克隆到其他业务组，把选中的规则复制到一个或多个别的组，名字不变。 把一套规则交给另一个团队，就该用这个。
- 规则行上的克隆是把这条规则当成一份未保存的副本打开，用来做变体。
- 更多操作 → 更新告警规则对选中的规则批量改某一个字段——级别、执行频率、生效时间、 附加标签、通知规则，以及另外十几个。刚导入的一批规则都要换同一个数据源、 挂同一条通知规则时，用这个。
批量改有一处要注意：改告警级别只对「只有一档阈值」的规则有效。 对配了多档级别的规则，请求会成功，但什么也没改。
下一步
- 干脆从随附的规则库开始：规则模板与内置规则
- 给导入的规则重新指路：按业务组与数据源划定范围
- 确认它们真的能发出通知：通知规则