Monitor 单机版：运行维护与故障排查

审阅状态与值班范围

审阅日期：2026-09-08。本文依据 Monitor 单机版源码标记 v2.1.7 编写；本次未执行长期运行、重启、热重载、通知或故障演练。值班范围是已获准的单机指标、服务探针和通知链路，不包含远程自动修复、集中式存储或 Kubernetes 控制面管理。

交接准备与已实现维护能力

交接清单应包含制品标识、运行身份、配置位置、日志位置、采样周期、每个探针的责任人、报告时间和通知接收组。凭据只在既有受控系统保管，交接文档保存引用而非明文。

源码提供按文件大小轮转日志、保留份数、状态日志间隔和配置重新加载，分别见 main.go:340、main.go:422、main.go:613。明确 max_backups=0 的行为是截断当前文件，不是无限保存。当前维护功能不等于具备日志远端归档或不可篡改审计。

日常操作顺序

先确认实际进程与配置路径，再检查最近一次采集时间、探针覆盖、告警变化与报告计划。按同一时间范围对照系统基线，关注缺失数据、持续探针超时、通知错误和日志增长。调整阈值前记录业务负载变化，避免用提高阈值或延长静默期隐藏问题。

日志预算需结合实际采样频率、探针数与错误量测算；轮转设置只能约束本程序日志，不能代替整个文件系统容量管理。对日志做脱敏后再提交问题，保留时间戳、错误类别及制品标识即可，不公开完整 webhook、收件人清单或业务地址。

告警与报告验收

每次变更后，在受控样例中验证指标、探针、触发、发送与接收的完整时间线。告警静默期与每小时上限可能改变重复通知次数；恢复消息应由接收人确认。报告计划以主机本地时区为准，健康时跳过报告也需有日志依据，不能把“没有消息”直接判断为服务退出。

-t 会真实推送，源码在测试流程结束后退出 0，即使通道没有成功送达也不能据此宣布验收通过。测试记录至少保存接收端确认、时间与脱敏消息标识。源码依据见 main.go:554、main.go:1333、main.go:1721。

常见故障分层定位

• 指标不完整或异常为零：优先核对系统权限、平台差异、采集错误及同时间段基线。关键指标缺失却被当作健康时，停止扩大覆盖。
• HTTP/TCP 探针持续失败：优先核对目标配置、路由、证书、状态码与超时。目标身份不明或需要扩大访问范围时，停止推广并重新确认授权。
• Docker unhealthy：核对容器运行状态、HEALTHCHECK 本身及 inspect 权限。若只能通过过度授权才能检测，不继续接入。
• 告警未送达：核对开关、通道配置、静默与限流、网络和平台响应。通知发往非授权成员时，立即停止扩大通知范围。
• 日志迅速增长：核对高频错误、状态日志间隔、轮转权限与磁盘余量。已影响业务或保留预算失控时，停止推广并处置容量风险。

本工具不能代替应用级正确性检查。排障只收集获准证据，不通过重启数据库、清空业务数据或关闭防火墙试错。

变更恢复与退出边界

更改配置和日志规则前保存有效副本，记录期望生效时间及判断方式。重新加载失败时先核对原因，再恢复原文件并确认采集正常；发现影响业务时停止试点扩展，保留原有监控渠道。服务管理与停止操作应遵循环境内既有授权流程，不直接复制未知进程号执行信号。

代码处理终止信号时调用 os.Exit(0)，见 main.go:630；不要宣称所有在途通知和日志必然排空。重启后的告警状态与连续计数需重新观察，不将内存状态当作持久审计记录。只有采集、通知和恢复均有实测证据后，才能更新项目运行结论。

关联文档与复核依据

• 快速开始与试点准备
• 配置与探针使用
• Monitor 单机版工具
• 项目档案
• Linux 主机监控场景
• Kubernetes 集群监控场景：需要对象和集中采集能力时另行评估，不沿用单机版能力假设。