# 规则模板与内置规则

夜莺自带 MySQL、Redis、Kubernetes 等六十多个组件的规则模板，可导入任意业务组；自己的规则也能存为模板复用。

最后校对于 2026-10-10

这页办完你会得到：夜莺自带的 MySQL、Redis、Kubernetes 等六十多个组件的告警规则， 已经躺在你的某个业务组里，指向你自己的数据源、挂好了通知规则—— 并且你知道怎么把自己写的规则放进同一个库里。

## 随安装附带的规则库[​](#随安装附带的规则库 "随安装附带的规则库的直接链接")

**集成中心 → 模板中心**（`/components`）是一片 logo 宫格，一个集成一块。 夜莺随包带了 <!-- -->83<!-- --> 个集成，其中 <!-- -->63<!-- --> 个带告警规则。

点开一个集成会拉出抽屉，里面的 **告警规则** tab 就是这个集成带来的规则列表。 每条规则都带备注、标签，以及一条 `action` 附加信息，写着被叫起来的人第一步该干什么。

列表可以按**分类**筛。分类来自规则文件的打包方式，所以 MySQL 下面 `mysql_by_categraf` 和 `mysql_by_exporter` 是两个分类。按你实际的采集方式挑一个——两个都导，每条规则就会有两份。

自带库里的规则，「更新人」列标着**系统内置**。这个标记同时意味着它们在这里不能改、不能删， 只能导入。

## 把内置规则导进业务组[​](#把内置规则导进业务组 "把内置规则导进业务组的直接链接")

勾选要的规则，点**导入业务组**。

| 字段       | 怎么填                                          |
| ---------- | ----------------------------------------------- |
| 业务组     | 规则落到哪儿，也就决定了产生的事件归哪个团队    |
| 启用       | 默认关。就让它关着，把导进来的东西看一遍再启用  |
| 数据源类型 | 只读，从你选的规则里推导                        |
| 数据源筛选 | 这些规则该跑在**你自己的**哪些实例上            |
| 通知规则   | 在这里挂上。内置规则自己不带任何通知配置        |
| 内容       | 规则的 JSON，可编辑——落库前想调个阈值就在这儿调 |

一次导入里的规则必须是同一种数据源类型，混选会在提交前被拦下。

提交。预期结果：规则出现在那个业务组的规则列表里，处于停用状态， 数据源筛选和通知规则都已经按你填的设好了。

和[导入、导出与复用](https://n9e.github.io/zh/docs/alerting/import-export.md)里那条「导出再导入」的路不同， 这条路**会保留生效时间窗口**——内置规则的窗口写在文件里，跟着一起过来。

## 从规则列表页导同一批[​](#从规则列表页导同一批 "从规则列表页导同一批的直接链接")

如果你已经在看某个业务组的规则列表，不必绕去模板中心： **规则管理 → 导入 → 导入内置告警规则**翻的是同一个库，直接导进你当前所在的组。

有一处区别值得知道：这条路**没有**通知规则那个字段，所以这样导进来的规则不挂任何通知。 事后用**更多操作 → 更新告警规则 → 通知规则**补上。

## 导进来之后要做的事[​](#导进来之后要做的事 "导进来之后要做的事的直接链接")

内置规则是起点，不是成品。启用之前有三件事要过一遍：

1. **阈值。** 它们是按通用安装写的。`disk_used_percent > 85` 对数据库服务器合理， 对日志采集机就是噪音。挨条看一遍。
2. **级别。** 这个库对 S1 挺大方的。哪些真的值得半夜叫人，自己定—— 见[标签、附加信息与级别](https://n9e.github.io/zh/docs/alerting/labels-severity.md)。
3. **通知规则**，如果你是从规则列表那条路导的。没有它，规则触发了也是发向虚空。

然后分批启用，别一次全开，这样一波噪音来了还能追到是哪一批。

## 把自己的规则做成模板[​](#把自己的规则做成模板 "把自己的规则做成模板的直接链接")

**没有「保存为模板」这个按钮。** 官方支持的是一条三步的手工路径，界面上的说明也是这么写的：

1. 在自己的业务组里把规则写好、调顺，可以拿真实数据[模拟触发](https://n9e.github.io/zh/docs/alerting/test-fire.md)验证；
2. 在规则列表里选中它，用**更多操作 → 导出规则 JSON**；
3. 去**集成中心 → 模板中心**，打开它所属的那个集成（没有就新建一个）的**告警规则** tab， 点**创建**，填一个分类名，把 JSON 粘进去。

这样存下的模板落在数据库里，不在附带的文件里，所以「更新人」列显示的是你的名字而不是 **系统内置**，你也能改能删。从此它就和内置规则出现在同一个列表里，导入方式完全一样。

模板中心页面顶部的**创建**按钮可以新建一个集成，要填名称、图标和启用开关。 没有上传集成包这回事——这样建出来的集成，就是一个装你粘进去的模板的容器。

关于这份 JSON 有两点。导入是**按规则名**匹配的，所以模板起的名字别和大家已有的规则撞上。 以及，粘之前把环境相关的东西删掉，尤其是数据源 id——那个由导入表单来设。

## 这个库从哪儿来[​](#这个库从哪儿来 "这个库从哪儿来的直接链接")

自带规则就是夜莺发布包里的普通 JSON 文件，路径是 `integrations/<集成名>/alerts/*.json`。一个文件是一个规则数组，文件名就是界面上看到的分类。

它们在进程启动时从磁盘读进来。集成本身会记进数据库；告警规则、仪表盘、指标说明只在内存里， 每次启动重建——所以改完 JSON 文件重启一下，库里提供的东西就变了。

目录默认是工作目录下的 `integrations`，可以用 `[Center]` 下的 `BuiltinIntegrationsDir` 改。 想完全不加载自带库（比如内网环境要用自己整理的一套），在 `configs` 表里插一条 `ckey` = `disable_integration_init` 的记录。

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

* 把导进来的规则改成自己的：[指标规则](https://n9e.github.io/zh/docs/alerting/metric-rules.md)
* 在环境之间搬运自己的规则：[导入、导出与复用](https://n9e.github.io/zh/docs/alerting/import-export.md)
* 决定什么才值得叫人：[规则设计实践](https://n9e.github.io/zh/docs/alerting/best-practices.md)