使用指南

Monitor 单机版：配置与探针使用

说明配置入口、各类探针判定、告警控制和报告计划，区分发送尝试与实际通知送达。

适用版本与阅读前提

审阅日期：2026-09-08。以下配置语义来自源码标记 v2.1.7 的 main.go，未通过本次真实运行验证，不构成正式 release 承诺。先完成试点准备，确认运行身份、可写配置和日志位置、目标责任人及通知测试窗口；实际字段以获准制品对应源码为准。

已实现配置入口

-c 选择 JSON 文件，-v 输出源码品牌与版本，-t 加载配置后发送通知测试。配置结构见 main.go:54，包括采样周期、阈值、监测磁盘、独立 TCP 与服务探针、告警控制、通知通道和日志配置。notify_config.channels 配置后优先于旧单通道形式；未配置或占位通知地址会跳过发送，不是有效接入状态。

分层配置流程

先明确主机名称、采集间隔和实际挂载点，保留原配置副本。
根据试点基线设置 CPU、内存、磁盘、负载、IO 等待与 TCP 连接阈值；不要把示例阈值当作生产标准。
每次只增加一种探针，检查正常样例与受控异常样例，再继续扩展。
设定连续触发次数、静默期和每小时告警上限，由值班人员确认过度静默不会掩盖故障。
分别启用获准通知通道和报告计划，记录接收人确认结果。

以下仅展示通知关闭状态的配置片段，不能作为完整配置直接启动：

{
  "notify_config": {
    "enable_alert": false,
    "enable_report": false,
    "channels": []
  }
}

探针判定与局限

TCP：在超时内完成连接即满足探针条件；端口成功不代表认证、SQL 或业务交易成功。
HTTP(S)：检查 GET 请求与预期状态码，默认接受 2xx；没有业务响应体断言，需另行验证关键交易。
process：进程名称或命令行包含目标字符串即匹配；应避免过宽名称误匹配，命令行读取也可能受权限限制。
Docker：读取 docker inspect 的运行及健康状态；未定义 HEALTHCHECK 时只能判定运行，require_healthy=false 会放宽健康要求。

依据分别位于 main.go:1044、main.go:1140、main.go:1188。并发探针存在整体等待边界，不能只增大单探针超时就认定所有检查都能等待完成。

报告与配置变更

report_time 和 report_times 合并去重后按本地时区定点调度，存在有效定点时优先于 report_interval；否则按间隔执行。先确认主机时区，再记录下一次计划时间。报告开关和 report_skip_healthy 会影响实际发送。调度器在等待计时器结束后进入下一轮，不要承诺修改计划立即打断当前等待。

配置更新可由文件修改检测或 SIGHUP 触发重新读取；这会改变后续运行行为，应当作为受控变更。重新加载前保留有效文件，失败时核对日志并恢复原内容；不能仅凭“文件已保存”认定新配置已经生效。

验收与故障处理

逐项记录正常/异常探针结果、连续触发次数、通知去重与恢复、报告时间以及各通道送达确认。-t 会实际推送，退出码 0 不能代替接收证据。未送达时区分未配置、被禁用、占位值、网络失败和平台拒绝；不要为排障长期关闭 TLS 证书校验。配置中的 aggregation_window 未见实际消费逻辑，不把其数值写入验收时限。

风险与关联阅读

告警与报告可能包含主机及服务标识，应限制通知成员与留存范围。自动化更新应先通过单主机验证，保留原监控，不以业务停机制造故障。后续阅读运行维护与故障排查、主机监控场景、Prometheus 告警分级与降噪实践；后者是通用治理思路，不代表单机版采用 Alertmanager 实现。