Monitor-Gateway 使用指南：规则、通知与报告

操作范围与状态说明

本页解释 2026-09-08 已审阅源码中的节点、规则、通知和报告接口，未运行 Gateway 或 Agent，也未执行测试通知。使用前完成快速开始的存储与权限准入，再依据环境版本评审配置。

控制台查询、更新告警状态、热加载和发送报告具有不同影响。只读检查不授权发送消息或改变值班状态，测试通道与接收人应在任务开始前明确。

节点指标与服务探针

为节点配置稳定身份、业务分组和标签，选择必要的 CPU、内存、磁盘、网络与进程指标。挂载点列表与自动发现选项应对照实际系统，避免遗漏业务盘或把临时文件系统作为容量告警对象。

服务探针支持 TCP、HTTP(S)、进程和 Docker。逐项登记目标、超时和成功条件；端口开放仅证明连接建立，HTTP 成功码也不证明业务事务完成。Docker 检查涉及容器访问权限，需最小授权；不要为了一个探针扩大全部主机管理权限。

local_alerts 决定 Agent 是否做本地阈值判断，探针失败是否附带告警还有独立选项。配置变化后应检查实际载荷与生效规则，不能仅根据界面有指标就认定告警来源正确。

中心规则与告警来源

agent_only 使用 Agent 告警，gateway_only 使用中心规则，merge 合并两者并按源码规则解决同类型告警。迁移前应列出当前阈值、节点范围与告警责任人，再选择一种明确策略，避免双份阈值长期漂移。

候选规则应从一类指标和一个试点分组开始，检查单位、比较符、阈值、持续条件和恢复行为。磁盘类指标可能按挂载点展开，须核对实际路径与消息内容。查询生效规则和观察测试告警后才扩大范围，不直接把模板阈值推广到全部节点。

通知通道与防告警风暴

已实现钉钉、企业微信、飞书、Slack、SMTP 邮件和通用 Webhook。配置通道前确定秘密保管、接收对象、限速和失败重试策略；占位通道可能被跳过，配置文件可解析不等于可以发送。

先在专用测试通道验证一条告警及恢复，再核对分组、静默、连续次数和通道限速是否符合预期。不要通过制造生产 CPU 或磁盘故障验证告警。管理测试接口会实际发送通知，必须得到接收方同意；队列已接收也不等于对端已送达，需保留接收证据。

控制台、查询与集群报告

控制台提供节点、告警、统计、历史和规则视图；API 具备节点、历史、规则与报告调度查询入口。查询应使用获准的最小权限身份，避免把管理 Token 放进浏览器地址。源码中的告警状态更新属于写操作，不能因为使用查询类权限就被当作无副作用读取。

报告可按定点或间隔生成，并支持全绿跳过。核对网关时区、报告时间、开关与接收对象；未收到报告可能是调度或全绿条件，不一定是通知故障。历史网络字段表示吞吐 MB/s，不是累计流量，展示和验收时应使用相同单位。

变更验收与相关资料

热加载前保存候选与当前配置差异，执行后查询生效规则、通知设置和调度结果。监听、存储、TLS 和队列等变化需按运行维护安排重启，不能仅凭热加载接口返回成功就认定所有配置已经生效。

每次记录节点范围、规则模式、告警来源、发送结果及恢复证据。源码依据为 internal/alert/rules.go、internal/notify/channels.go、internal/gw/gateway.go 和 internal/gw/report.go。可参考告警分级与降噪知识与Linux 主机监控场景，但不代表已与 Prometheus 或 Alertmanager 完成联动。