重试与投递状态
通知发送失败只对「连不上」自动重试，参数按发送类型各不相同；每条消息的投递结果在通知记录里可查，记录保留 7 天。
这页办完你会知道：一条通知从「决定要发」到「对方收到」中间可能卡在哪， 哪些失败会自动重试、哪些不会，以及事后去哪儿翻这一条到底发生了什么。
消息是怎么发出去的
发送路径按媒介的发送类型（request_type）分三条：
| 发送类型 | 怎么发 | 并发控制 |
|---|---|---|
http（钉钉、企业微信、飞书卡片、Telegram、回调、自建 webhook） | 进这个媒介自己的队列，异步发 | 媒介上的并发数 |
smtp（邮件） | 同步发，走邮件连接池 | 媒介上的批量发送（一次连接里发几封） |
flashduty / pagerduty / script | 直接调用，同步 | 无 |
HTTP 队列满的时候消息会被丢弃，并写一条失败记录：
failed to enqueue notify task, queue is full。看到它说明目标端太慢或者并发数配得太小。
重试只覆盖「连不上」
这是最容易误解的一点。HTTP 媒介的重试循环是这样的：
- 请求根本发不出去（DNS 解析失败、连接被拒、超时）→ 等一个重试间隔再来一次，
最多重试重试次数遍；全失败后写一条
all retries failed, last error: <最后一次的错误>。 - 对方返回了任何 HTTP 响应 → 立刻返回，不重试。200 记成功，非 200 记失败，
记录里是
status_code:<码>, response:<响应体>。
也就是说，钉钉返回 400「关键词不匹配」、企业微信返回 45009「超频」， 都不会重试。这是有意的：重发一条对方已经明确拒绝的消息没有意义， 而且对下游的去重不友好。
还有一个边界：重试次数填 0 等于一条都不发——循环体一次都不进，
记录里是一条 all retries failed，错误信息还是空的。别把它当限流开关用。
每种发送类型的重试参数不一样
| 参数 | http | flashduty / pagerduty |
|---|---|---|
| 超时 | 超时时间（毫秒），内置媒介 10000 | 超时时间（毫秒），内置 FlashDuty 5000 |
| 重试次数 | 重试次数，内置媒介 3 | 重试次数，不填按 3 |
| 重试间隔 | 重试间隔（毫秒），内置媒介 100 | 重试等待时间（毫秒），不填按 1000 |
| 实际尝试次数 | 等于重试次数 | 重试次数 + 1 |
新建媒介时表单给的默认值和内置媒介不完全一样（超时 10000、并发 3、重试 3、间隔 3000）， 按需要改。
对「对方回了个错误状态码」这件事，三条路径的态度也不一样：
http：只有 200 算成功，其余状态码记失败，但不重试；pagerduty：200 和 202 算成功，其余状态码会按重试次数再试一轮；flashduty：只要请求发出去了就算成功，状态码只记录不判断——重发会破坏对方的去重。
发之前就被丢掉的几种情况
这几种情况下请求压根没发出去，但通知记录里有一条失败记录：
| 记录里的文字 | 原因 | 怎么修 |
|---|---|---|
message_template not found | 这条通知配置没选消息模板 | 回通知规则补上模板。FlashDuty、PagerDuty 和「回调」类媒介不需要模板，界面上也不显示这一项 |
notify_channel not found | 媒介被删了，或者被停用了——引擎侧的缓存只装启用中的媒介 | 把媒介启用回来，或换一个 |
failed to enqueue notify task, queue is full | HTTP 发送队列满 | 提高媒介的并发数，或者查目标端为什么慢 |
另外两种情况连记录都不会有，因为事件根本没走到通知这一步： 通知规则上挂的事件处理工作流把事件丢弃了，或者恢复事件遇上「不通知恢复」的规则。
在哪儿看送没送到
开源版没有独立的「通知记录」菜单页，记录挂在事件上： 告警通知 → 告警事件 → 点开一条事件 → 通知记录 → 查看详情。
抽屉里分告警规则通知和订阅规则通知两张表，列是通知规则 ID、通知渠道、 通知对象、通知目标、通知状态。三点值得注意：
- 同一个（渠道 + 目标）的多条记录会被合并成一行，状态取更差的那个， 说明文字拼接在一起。所以一行里可能同时看到成功和失败的片段。
- 通知目标默认打码，末 8 位变成星号。只有邮件、短信、语音、脚本和屏蔽记录 显示完整值——这几类的目标本来就是收件人自己看得到的信息。
- 记录是异步入库的（内存队列每 100 毫秒批量落一次），刚发完立刻刷新可能还看不到。
状态有三种：成功、失败，以及被屏蔽——最后一种来自「只屏蔽通知」的屏蔽规则，
渠道显示成 mute，目标是 id=<屏蔽规则 id>，说明文字里带屏蔽规则的名字。
用它可以回答「这段时间到底屏蔽掉了什么」，详见屏蔽规则。
通知记录只留 7 天
notification_record 是持续高频写入的大表，中心端每天凌晨 1 点清理一次，
默认只保留 7 天。想改保留天数，在中心端配置文件的 [Center] 段里加：
[Center]
# 通知记录保留天数，默认 7
CleanNotifyRecordDay = 30
要长期留存就自己往外导，不要靠加大这个值——这张表的写入量跟告警量成正比。