# 端到端测试一条通知

在凌晨三点依赖它之前，先通过真实媒介从规则到手机完整发一条测试消息。

最后校对于 2026-10-10

这页办完你会确认：真实告警发生时，消息确实会落到那个群 / 那个邮箱， 而不是停在「界面上配好了」这一步。

## 三个层次的测试[​](#三个层次的测试 "三个层次的测试的直接链接")

| 层次         | 在哪按                                          | 验证了什么                             | 没验证什么                       |
| ------------ | ----------------------------------------------- | -------------------------------------- | -------------------------------- |
| 媒介测试     | 通知媒介编辑页底部的 **测试**                   | 地址通不通、密钥对不对、网络能不能出去 | 你的消息模板、通知规则的筛选条件 |
| 通知规则测试 | 通知规则表单里每条通知配置右上角的 **通知测试** | 媒介 + 模板 + 接收人这一整组配置       | 告警规则有没有挂上这条通知规则   |
| 真实告警     | 告警规则的 **测试触发**                         | 整条链路，包括规则绑定                 | ——                               |

三个都过了才算数。只做前两个是「配置对」，不等于「真实告警会到」。

## 1. 在媒介上直接测[​](#1-在媒介上直接测 "1. 在媒介上直接测的直接链接")

**告警通知 → 通知媒介**，点开一个媒介，底部有 **测试**。

它**按当前表单里的内容真实发一条消息，不需要先保存**，所以适合边填边试。 弹窗里从上往下：

* **模式**：模拟事件（内置假事件，可选级别和是否恢复）/ 历史事件（挑真实事件）；
* **媒介参数**：这个媒介声明的自定义参数，比如钉钉的 Access Token；
* **接收人**：媒介配了「联系方式」时才出现。

预期结果：提示「发送成功」，并且**你真的在群里/邮箱里看到那条消息**。 只看提示不算——媒介返回 200 但消息被平台丢掉的情况并不少见。

两个限制：

* **Script 类媒介不能内联测试**，必须先保存。未保存的脚本会被写盘执行，等于从请求体 直接执行任意代码，后端因此拒绝。
* **这里发出去的正文不是你的模板**，是界面按媒介请求体里的 `{{$tpl.xxx}}` 现拼的一段 起步内容。所以这一步只能证明「通道是通的」，证明不了「模板写对了」。

## 2. 在通知规则里测[​](#2-在通知规则里测 "2. 在通知规则里测的直接链接")

**告警通知 → 通知规则**，编辑一条规则，在某条通知配置右上角点 **通知测试**。 这一步用的就是这条配置真正会用的媒介、模板和接收人。

两种模式的差别很重要：

* **使用模拟事件**：**不校验筛选条件**，只验证通道。级别取你勾选的最低那一级。 模拟事件长这样——规则名「通知测试模拟事件」，触发值 `81.5`，标签 `ident=mock-host-01`、`source=notify-rule-test`。
* **选择历史事件**：会先跑一遍筛选条件，事件不匹配就直接报错 （`event severity not match severity filter` 之类）。想验证筛选条件写得对不对，用这个。

预期结果：弹窗里回显目标返回的响应（HTTP 媒介是 `status_code:200, response:...`）， 同时消息真的到了。

## 3. 用真实告警走完整条链路[​](#3-用真实告警走完整条链路 "3. 用真实告警走完整条链路的直接链接")

前两步不经过告警规则，所以最容易漏掉的一件事是：**这条通知规则根本没挂到告警规则上**。

去 **告警通知 → 规则管理**，确认目标告警规则的 **通知规则** 字段里有它， 然后用规则自己的[测试触发](https://n9e.github.io/zh/docs/alerting/test-fire.md)真的产生一条事件。

预期结果：**告警通知 → 告警事件** 里出现一条新事件，同时你收到消息。

## 在通知记录里确认[​](#在通知记录里确认 "在通知记录里确认的直接链接")

事件出现了但消息没到，就去看通知记录：**告警事件 → 点开事件详情 → 通知记录 → 查看详情**。

抽屉里有两张表：**告警规则通知** 和 **订阅规则通知**，列是通知规则 ID、通知渠道、 通知对象、通知目标、通知状态。状态里的文字就是失败原因，例如：

| 记录里的文字                          | 含义                                                     |
| ------------------------------------- | -------------------------------------------------------- |
| `status_code:200, response:...`       | 发出去了，对方回了 200                                   |
| `message_template not found`          | 这条通知配置没选消息模板，整条被丢弃                     |
| `notify_channel not found`            | 媒介被删了或被停用                                       |
| `all retries failed, last error: ...` | 连不上目标地址                                           |
| `status_code:400, response:...`       | 目标接受了请求但拒绝了内容，多半是 token、签名或消息格式 |

**通知目标默认打码**（末 8 位变星号），只有邮件、短信、语音、脚本和屏蔽记录例外。

## 测不通的时候按这个顺序查[​](#测不通的时候按这个顺序查 "测不通的时候按这个顺序查的直接链接")

1. 媒介测试过不去 → 是网络或密钥问题，跟夜莺的其余配置无关。看错误里的 status code。
2. 媒介能过、通知规则测不过 → 看筛选条件（尤其是**适用级别一个都没勾**）和模板是否选了。
3. 都能过、真实告警收不到 → 告警规则上没挂这条通知规则，或者被屏蔽规则吃掉了。
4. 通知记录里根本没有这条事件的记录 → 事件压根没进到通知这一步， 顺着[有告警事件，为什么收不到通知？](https://n9e.github.io/zh/docs/troubleshooting/no-notification.md)排。

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

* 消息内容不对：[模板与变量](https://n9e.github.io/zh/docs/notifications/templates.md)
* 发送失败的重试规则：[重试与投递状态](https://n9e.github.io/zh/docs/notifications/delivery.md)
* 送到了但送错了人：[通知路由到了错误的人](https://n9e.github.io/zh/docs/troubleshooting/wrong-routing.md)