# 弃用与生命周期

被夜莺标记为弃用的功能、字段和界面项及各自的替代方案；项目未公布移除时间表，版本信息以 GitHub Release 为准。

最后校对于 2026-10-10

这页列的是夜莺标记为弃用的东西，以及各自的替代方案。它不列移除时间， 因为**项目方没有公布过任何时间表**——读下面之前先看第一节。

## 没有公开的版本维护政策[​](#没有公开的版本维护政策 "没有公开的版本维护政策的直接链接")

项目方没有公布支持矩阵，没有 LTS 版本，没有说明每个小版本维护多久， 也没有宣布过这页上任何一项的移除计划。[兼容性矩阵](https://n9e.github.io/zh/docs/reference/compatibility.md) 在平台版本这件事上是同样的口径，理由也一样。

实际情况是：修复只会打在发布线的最新一版上，v9.1.1 是打在 v9.1.0 上的补丁版本， Bug 修复出现在那里。除此之外，权威记录在 GitHub：

| 你想知道的                   | 去哪儿看                                                                                         |
| ---------------------------- | ------------------------------------------------------------------------------------------------ |
| 有哪些版本、各自什么时候发的 | [GitHub Releases](https://github.com/ccfos/nightingale/releases)                                 |
| 某个修复进没进               | 每个 release 里的 `fix:` 条目，见[发布说明](https://n9e.github.io/zh/docs/help/release-notes.md) |
| 某个字段引擎还读不读         | 源码。除此之外没有别的能作准                                                                     |

**下面标记为弃用的东西，在 v9.1.1 里全都还在、全都还能用。** 没有任何一项被移除。 把「弃用」读成「新增的东西应该做在替代方案上」，不要读成「下个版本就不能用了」—— 没有人说过时间，也不要从这页去推一个时间出来。

## 你能看到什么，取决于安装日期[​](#你能看到什么取决于安装日期 "你能看到什么，取决于安装日期的直接链接")

界面隐藏弃用菜单的依据是**这套系统是什么时候装的，不是它跑的哪个版本**。 分界线是 2025-06-20，也就是 v8 beta 14 的发布时间：

* 在这个时间**之后**装的，永远看不到被弃用的那两个通知页面， 告警规则表单上也没有通知版本切换入口；
* 在这个时间**之前**装的，这些还都在，侧栏里旁边挂着一个弃用标记。

所以两套都跑 v9.1.1 的系统，菜单可以不一样，而且两边都没坏。 同事的界面上有你没有的入口，说明他那套装得比这个分界线早。

## 界面上被弃用的[​](#界面上被弃用的 "界面上被弃用的的直接链接")

| 什么                                      | 原来在哪     | 替代                             |
| ----------------------------------------- | ------------ | -------------------------------- |
| 通知设置（`/help/notification-settings`） | 告警通知     | **通知规则** 加 **通知媒介**     |
| 通知模板（`/help/notification-tpls`）     | 告警通知     | **消息模板**                     |
| 告警规则表单上的事件标签重写（Relabel）   | 告警规则表单 | 工作流里的**事件标签重写**处理器 |

前两个就是上面那条安装日期规则会隐藏掉的入口。第三个不会隐藏—— 表单自己带了一句提示，说已有的 relabel 配置更适合改用工作流处理器来表达。

## 告警规则上被弃用的字段[​](#告警规则上被弃用的字段 "告警规则上被弃用的字段的直接链接")

下面这些在告警规则模型里带着 `Deprecated` 标记。它们全都还能传、API 也还会返回：

| 字段                                                  | 替代                                                     | 说明                                                                             |
| ----------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------------------------------- |
| `datasource_ids`、`cluster`                           | `datasource_queries`                                     | `datasource_ids` 是读的时候反填给列表页用的；引擎只读 `datasource_queries`       |
| `notify_channels`、`notify_groups`、`callbacks`       | `notify_rule_ids`                                        | 三层通知模型。`notify_version: 1` 的规则不用这几个字段                           |
| `enable_stime`、`enable_etime`、`enable_days_of_week` | `enable_stimes`、`enable_etimes`、`enable_days_of_weeks` | 单数形式只能表达一个生效时段，复数形式能表达多个                                 |
| `prom_for_duration`                                   | 标注的是 *use cron pattern instead*                      | **它仍然是「持续时长」唯一的实现**，每次判定都还在读。不要把它从规则 JSON 里删掉 |

任何读写告警规则 JSON 的东西——导出脚本、批量下发工具、同步任务——都该改用替代字段， 但无论如何要保留 `prom_for_duration`。

## 新通知版本下会被清空的订阅规则字段[​](#新通知版本下会被清空的订阅规则字段 "新通知版本下会被清空的订阅规则字段的直接链接")

保存一条 `notify_version: 1` 的订阅规则时，后端会把下面这些字段清空， 不报错，也没有提示：

* 授权团队（`user_group_ids`）；
* 重新定义的通知媒介（`redefine_channels`、`new_channels`）；
* 重新定义的回调地址（`redefine_webhooks`、`webhooks`）；
* 重新定义的告警级别（`redefine_severity`、`new_severity`）。

这是设计如此，不是 Bug：在新模型里这些决定属于订阅所选的那几条通知规则，不属于订阅本身。 见[订阅规则](https://n9e.github.io/zh/docs/events/subscriptions.md)。如果你是用脚本创建订阅的， 把这些字段和 `notify_version: 1` 一起发过去，它们会被静默丢掉。

## 代码还在、但已经不在任何链路上的[​](#代码还在但已经不在任何链路上的 "代码还在、但已经不在任何链路上的的直接链接")

两样你读源码或者抓包时可能会撞见的东西。它们都还会响应，但都不要基于它们做事。

* **`POST /api/n9e/busi-group/alert-rules/notify-tryrun` 和 `.../enable-tryrun`。** 前端还各留着一个封装函数，而唯一那处调用被注释掉了。它们的活现在由 [测试触发](https://n9e.github.io/zh/docs/alerting/test-fire.md)干了——一次走完查询 → 阈值 → 事件 → 通知， 而不是分成两个局部检查。
* **`alert/sender/` 下那套 v7 时期的发送器**（钉钉、企业微信、飞书、Lark、Telegram、 Mattermost、邮件）。它们还编译在里面、也还挂着，但只有旧链路会走到： 一条 `notify_version: 0` 的规则产生的、带着 `notify_channels` 和 `notify_groups` 的事件。 通知规则走的是完全不同的另一条路，经过你在**告警通知 → 通知媒介**里配的媒介。 改旧链路上的模板，不会改变通知规则发出去的内容。

## 相关[​](#相关 "相关的直接链接")

* [发布说明](https://n9e.github.io/zh/docs/help/release-notes.md)——每个版本的升级影响
* [v8 升级 v9](https://n9e.github.io/zh/docs/migration/v8-to-v9.md)——上面这些替代方案大多是那时候来的
* [兼容性矩阵](https://n9e.github.io/zh/docs/reference/compatibility.md)——另一页同样没有官方承诺兜底的内容