linux监控丢点需逐层排查：先确认采集器进程、日志及退避机制；再检查传输链路连通性、缓冲区与网络；接着验证目标端接收能力与资源状态；最后排除cpu、内存、磁盘i/o及时间同步等系统级问题。
Linux监控采集丢点，通常不是单一环节的问题，而是采集链路中某个组件出现延迟、阻塞、配置不当或资源瓶颈所致。排查需从数据源头到存储逐层验证，重点看采集器行为、传输稳定性、目标端接收能力及中间网络/队列状态。
确认采集器是否正常运行并持续发数
很多“丢点”实际是采集器自身已停止或卡住：
- 检查进程状态：ps aux | grep telegraf（或其他采集器名），确认进程存活且启动时间合理
- 查看采集器日志：journalctl -u telegraf -n 100 -f 或翻查 /var/log/telegraf/telegraf.log，关注 error/warn 级别日志，如 "E! [outputs.prometheus_client] Error writing response" 或 "E! [inputs.cpu] Error in plugin: failed to get CPU info"
- 验证采集频率是否被抑制：部分采集器（如 Telegraf）在插件报错多次后会自动退避，表现为指标突然中断几分钟后恢复，需查日志中的 "disabled" 或 "backoff" 关键词
检查采集器到目标端的传输链路
即使采集器在跑，数据也可能卡在发送环节：
- 确认目标地址可达且端口开放：telnet 127.0.0.1 9100（Prometheus Exporter）或 nc -zv your-pushgateway 9091
- 观察采集器输出插件缓冲区积压：Telegraf 的 [agent].metric_batch_size 和 metric_buffer_limit 设置过小，或目标响应慢，会导致 buffer 满而丢弃新指标；检查日志中是否有 "Dropping metrics due to full metric buffer"
- 若走 HTTP 推送（如 Pushgateway），用 tcpdump 抓包确认请求是否发出、是否有 5xx 响应或超时；若走 TCP/UDP 上报（如 StatsD、InfluxDB Line Protocol），注意防火墙、连接数限制（netstat -an | grep :8125 | wc -l）
验证目标端接收与落盘是否及时
接收服务压力大或配置不合理也会造成“假性丢点”：
- Prometheus：检查 status → Runtime & Build Information 页面中的 Scrape duration 是否明显增长，或 Graph 中查询 prometheus_target_interval_length_seconds 是否抖动；同时确认 scrape_timeout 小于 scrape_interval
- Pushgateway：检查 /metrics 是否返回正常，以及 pushgateway_build_info 后面的时间戳是否实时更新；注意它不支持高并发推送，大量 job 同时 push 易触发 429 或写入延迟
- InfluxDB / VictoriaMetrics：查看写入日志是否有 "too many requests"、"write timeout" 或 "out of memory"；用 influx ping 或 vmselect --version 配合 /api/v1/status/topk 查资源使用
排除系统级干扰因素
底层资源不足常被忽略，却是高频根因：
- CPU 过载：采集器（尤其含 exec 插件）或目标端在高负载下无法及时处理，用 top -p $(pgrep telegraf) 观察单个采集进程 CPU 占用
- 内存与 OOM：dmesg -T | grep -i "killed process" 查是否被 OOM Killer 干掉；cat /sys/fs/cgroup/memory/.../memory.oom_control（若启用 cgroup v1）可确认
- 磁盘 I/O 延迟：iostat -x 1 查 %util > 90 或 await 异常高，影响本地缓存型采集器（如 Filebeat 写 spool）或 TSDB 落盘
- 时间不同步：NTP 失效导致采集时间戳异常（如未来时间），部分后端（如 Prometheus）会静默丢弃；运行 timedatectl status 和 ntpq -p 确认同步状态
