# 告警与通知

节点在线异常、延迟丢包、流量超额、证书或 DDNS 失败，都应先在 **系统设置 → 告警管理**核对时间与目标资源，再沿具体症状排查。

## 阅读告警与趋势

![告警统计、控制面网络状态、筛选与操作入口](https://img.coderluny.com:444/uploads/zfc-tutorial-20261018-alerts-overview-8eb044cc2bdf.png)

按告警 ID、状态、原因、严重程度筛选，检查发生次数、首次与最近发生时间，以及对应服务器／端点／端口。点击 **查看趋势**观察告警在时间上的分布，判断是短时波动还是持续问题。

| 状态 | 如何理解 |
| --- | --- |
| 活跃 | 仍需要跟进的告警记录 |
| 自动解决 | 系统记录的恢复结果，还需结合业务验证 |
| 手动解决 | 管理员将记录标为解决，不会替你修复节点 |
| 已忽略 | 改变告警处理状态，不表示服务已恢复 |
| 点事件 | 一次性事件，不应当作持续到现在的故障 |

例如入口地址变化可带通知序列，DDNS 写入失败则需结合记录归属与写入状态；不能把所有地址相关事件都当作掉线。

列表里的 **一键解决所有告警**和**一键删除所有告警**是批量操作。日常排查先筛选和处理具体资源，保留需要的证据；清空记录不会恢复业务。

## 配置检测阈值与发送开关

进入 **系统设置 → 告警与通知 → 告警设置**。

![告警类型的 Telegram 通知开关，具体状态以自己的面板为准](https://img.coderluny.com:444/uploads/zfc-tutorial-20261018-alert-settings-2a40049b879b.png)

1. 选择需要接收的离线、延迟、端口、资源、额度等告警类型。
2. 核对 CPU、内存、磁盘、连接数等阈值和持续检查次数；百分比与连接数量的单位不同。
3. 按实际值班需要设置余额不足阈值等参数。
4. 点击页面 **保存**，重新读取确认。

持续检查次数用于减少瞬时波动触发，不代表固定秒数，需结合实际采样周期。关闭某类发送开关也不能直接推断对应告警记录停止生成。界面标为“暂未实现”的自定义告警不能当作可用的任意脚本告警功能。

## Telegram 与邮件

在 **Telegram Bot**配置里核对 Bot 凭据、接收目标与启用状态。Bot Token 和 Chat ID 不出现在公开截图；凭据正确还需 Bot 能访问接收目标，以及面板网络能访问 Telegram。

在 **通知设置**中逐项核对事件启用状态、渠道和阈值；每条通知规则有自己的保存按钮。邮件设置与页面总设置、各条规则的保存动作不要混淆。

邮件可配置 SMTP 和 Resend，填写相应服务器、端口、用户、凭据和发件地址，再检查国内域名分流及频率限制。编辑时空密码通常用于保留原秘密值，应按字段提示处理，不能据此判断系统未配置密码。

验证应使用自己控制的接收目标，选择面板支持的测试方式或观察一条真实事件。发送成功、第三方接受、最终送达是不同阶段；未收到时依次检查事件开关、渠道配置、接收目标、限流、网络和服务商错误。

## 租户通知策略

租户管理员可在 **租户通知策略**分别查看运维告警与用户通知。默认继承全局；取消某条“继承”后才设置本租户覆盖并逐条保存。重新启用继承会恢复使用全局策略。

运维告警的部分邮件选项在当前界面不可用，应按禁用提示处理，不能以全局配置过邮件就认为所有租户事件都支持邮件发送。平台通知与租户覆盖也不能混作同一份全局配置。

## 从告警进入排查

| 症状 | 继续阅读 |
| --- | --- |
| 连接失败、速度下降 | [诊断与测速](/docs/diagnostics-speed-test/) |
| 入口监听被拦截 | [防火墙](/docs/firewall/) |
| DDNS、组 DNS 变更失败 | [DDNS](/docs/dynamic-dns/)与[服务器组](/docs/server-groups/) |
| 证书签发／续期失败 | [证书管理](/docs/certificates/) |
| 超额或到期暂停 | [用户与套餐](/docs/users-packages/) |
| 需要节点证据 | [AI 只读诊断](/docs/agent-diagnose/) |

处理完成后，复测实际业务，确认节点当前状态、告警状态和通知结果。不要只靠手动标记解决来完成故障验收。