## 症状现象
翻看监控大盘，某台机器凌晨两点到四点的曲线是空的，缺口平直或干脆无数据。缺口的含义需要判断：是机器真出问题了，还是采集链路自己断了。两种情况天差地别，误判轻则虚惊，重则漏掉真实故障。
## 定位过程
三步分流。第一步看同机多指标：CPU、内存、磁盘、网络全部同时断，机器级别的采集链路断了；只有个别指标缺失，是单个采集项的问题。第二步看同网段其他机器：邻居也断，是网络或监控服务端的问题；只有它断，回到这台机器自己找。第三步登录机器查时间线：机器存活、采集进程在不在、系统日志有无对应时段的重启或内存不足记录。三步下来，断点归因基本清楚。
systemctl status 监控代理服务 grep -i "oom\|restart" /var/log/messages | head
常见根因排序：代理进程被内存不足杀掉后未自动拉起、机器高负载时采集超时被服务端丢弃、网络抖动导致上报失败、服务端维护窗口。
## 解决方法
代理侧：确认自动重启策略，内存不足的根因要处理，不能只拉起进程了事。服务端侧：确认上报失败的落盘缓存机制，无缓存的方案在断网期间数据直接丢。补数据要看采集链路是否支持：代理本地有缓存的可以回补，无缓存的缺口只能接受并记录说明，恢复时间点之后的可信度不受影响。
## 预防建议
监控自身的存活也要被监控：代理进程存活、上报成功率、数据新鲜度三项指标独立告警，采集断了不再靠肉眼发现。顺云监控告警对代理状态有独立视图，接入后缺口类问题从排查变成提示，事半而功倍。
缺口事件本身的复盘也要形成记录：断点的起止时间、归因、影响的数据范围、是否补齐。这份记录既是监控体系改进的输入，也是数据可信度的注脚，报表引用该时段数据时附上说明，结论就不会被缺口污染。缺口归档按月统计，频发的环节优先治理。