# 导入、导出与复用

以 JSON 在环境之间搬运规则，并纳入版本控制。

最后校对于 2026-10-11

这页办完你会得到：一批规则以 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 规则混在 一次粘贴里，提交前就会被拦下——拆成两次导入。

点**导入**。预期结果：一张结果表，每条规则一行，显示规则名和「导入结果」—— 成功时结果列为空，失败时给出错误信息。

通知配置不会被带过来。导入时会清掉旧版的媒介和接收组字段，规则上也不会挂任何通知规则， 所以**导入之后要自己挂一条**，否则什么也发不出去。见[通知规则](https://n9e.github.io/zh/docs/notifications/rules.md)。

## 导入 Prometheus 原生告警规则[​](#导入-prometheus-原生告警规则 "导入 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:` 的条目会被转换—— 夜莺里对应的能力见[记录规则](https://n9e.github.io/zh/docs/query/recording-rules.md)。`keep_firing_for`、`limit` 也不会转换。

## 把规则纳入版本控制[​](#把规则纳入版本控制 "把规则纳入版本控制的直接链接")

导出的 JSON 足够稳定，可以拿来做 diff，于是就有了一套能跑的评审流程：

1. 在预发环境用界面改规则，表单会帮你校验，[模拟触发](https://n9e.github.io/zh/docs/alerting/test-fire.md)能证明它真的能跑；
2. 导出这个组的规则，把 JSON 提交进仓库；
3. 像评审其他改动一样评审这份 diff；
4. 打开**强制覆盖同名**导入到生产，于是合并是按名字做的。

有两件事要守住纪律。这套流程里**规则名就是主键**——在预发里改个名，到生产就是新建一条， 而不是更新原来那条。以及，生效窗口不会跟着导出走，所以要么让所有规则都全天生效， 要么把窗口记在某个导入时一定会看到的地方。

## 不用文件的复制方式[​](#不用文件的复制方式 "不用文件的复制方式的直接链接")

在同一套夜莺里搬规则，别绕 JSON：

* **更多操作 → 克隆到其他业务组**，把选中的规则复制到一个或多个别的组，名字不变。 把一套规则交给另一个团队，就该用这个。
* 规则行上的**克隆**是把这条规则当成一份未保存的副本打开，用来做变体。
* **更多操作 → 更新告警规则**对选中的规则批量改某一个字段——级别、执行频率、生效时间、 附加标签、通知规则，以及另外十几个。刚导入的一批规则都要换同一个数据源、 挂同一条通知规则时，用这个。

批量改有一处要注意：改**告警级别**只对「只有一档阈值」的规则有效。 对配了多档级别的规则，请求会成功，但什么也没改。

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

* 干脆从随附的规则库开始：[规则模板与内置规则](https://n9e.github.io/zh/docs/alerting/templates.md)
* 给导入的规则重新指路：[按业务组与数据源划定范围](https://n9e.github.io/zh/docs/alerting/scope.md)
* 确认它们真的能发出通知：[通知规则](https://n9e.github.io/zh/docs/notifications/rules.md)