2. 数据采集层故障排查：Agent采集器无数据、采集器进程假死、采集指标缺失的根因分析与修复步骤

数据采集层是监控体系的“神经末梢”，Agent 的健康状态直接决定上层告警与可视化的数据质量。本章聚焦三类高频故障：采集器无数据、进程假死、指标缺失，从架构视角给出根因定位路径与可落地的修复步骤。

2.1 故障分类与影响矩阵

故障现象 典型表现 影响范围 紧急程度
采集器无数据 Agent 端口不通、上游无数据流 整机或全量指标丢失 P0
进程假死 进程存活但无日志输出、无网络连接 部分指标持续缺失 P1
采集指标缺失 特定指标为空或异常值 局部监控盲区 P2
架构原则：Agent 故障应优先通过“心跳 + 自监控”机制发现，避免依赖用户反馈。每台 Agent 必须上报 agent.alive 与 agent.collect.count 两个黄金指标。

2.2 采集器无数据：根因与修复

2.2.1 根因分析树

  1. 网络层断裂：防火墙策略变更、DNS 解析失败、目标端口被占用。
  2. 配置错误：采集器配置文件语法错误、Endpoint 地址写错、 过期。
  3. 进程未启动：系统重启后自启失败、二进制文件损坏、依赖库缺失。
  4. 上游接收端故障：Collector/Receiver 服务宕机、队列积压导致拒绝连接。

2.2.2 修复步骤

步骤 操作 验证命令/方法
1 检查进程状态 systemctl status agent 或 ps aux | grep agent
2 验证网络连通性 telnet collector_host 9090 或 nc -zv collector_host 9090
3 校验配置文件 agent --check-config 或手动解析 YAML/JSON 格式
4 查看启动日志 journalctl -u agent --since "5 min ago"
5 重启并确认数据流 systemctl restart agent 后观察上游指标曲线
快速定位技巧：在 Agent 所在节点执行 curl -s http://127.0.0.1:9100/metrics | head -20，若能返回指标则说明 Agent 进程与 HTTP 服务正常，问题大概率出在上游网络或接收端。

2.3 采集器进程假死：根因与修复

进程假死是“进程存活但无响应”的状态，比进程崩溃更难发现。常见根因包括：

  • 线程死锁：采集插件内部锁竞争导致所有工作线程阻塞。
  • 内存泄漏：GC 频繁触发 Full GC，导致停顿时间过长。
  • IO 阻塞：磁盘写满、NFS 挂载超时、管道缓冲区满。
  • 外部依赖挂起：连接数据库或 Redis 超时未释放连接。

2.3.1 诊断步骤

  1. 查看进程状态：ps aux 确认进程存在，strace -p <PID> 观察系统调用是否卡住。
  2. 检查线程堆栈：jstack <PID>（Java Agent）或 pstack <PID>（C Agent）。
  3. 分析 GC 日志：jstat -gcutil <PID> 1000 10 查看 GC 频率与停顿时间。
  4. 检查文件描述符：lsof -p <PID> | wc -l 对比系统上限。

2.3.2 修复策略

根因 临时恢复 长期修复
线程死锁 kill -3 <PID> 导出堆栈后重启 优化锁粒度，引入超时机制
内存泄漏 重启 Agent，临时增加堆内存 使用 MAT 分析 heap dump，修复对象引用
IO 阻塞 清理磁盘 / 重启 NFS 客户端 添加 IO 超时配置，使用异步写入
外部依赖挂起 重启 Agent 释放连接 配置连接池与健康检查
避坑提醒：不要在生产环境直接 kill -9 假死进程，否则可能丢失未刷盘的指标缓存。优先使用 kill -15 或 systemctl stop 优雅关闭。

2.4 采集指标缺失：根因与修复

指标缺失表现为“部分指标有值，部分为空或恒为 0”，通常与采集插件、权限、数据源有关。

2.4.1 常见根因

  • 采集插件未加载：配置文件未启用对应插件，或插件版本不兼容。
  • 权限不足：Agent 运行用户无权限读取 /proc、/sys 或调用系统 API。
  • 数据源不可用：目标服务（如 MySQL、Nginx）未启动或端口变更。
  • 指标过滤规则：采集器配置了 drop 或 match 规则，误过滤了目标指标。
  • 采集超时：单次采集耗时超过预设阈值，导致数据被丢弃。

2.4.2 修复步骤

  1. 确认插件列表：agent --list-plugins 检查目标插件是否在 enabled 列表中。
  2. 测试数据源连通性：telnet localhost 3306（MySQL）或 curl http://localhost/status（HTTP）。
  3. 检查 Agent 运行用户：whoami 确认是否为 root 或监控专用用户，必要时赋予 CAP_DAC_OVERRIDE。
  4. 查看采集日志：tail -f /var/log/agent/collect.log 搜索 error 或 timeout 关键字。
  5. 临时关闭过滤规则：注释 drop_metrics 或 exclude_metrics 配置，重启后观察指标是否恢复。
架构建议：在 Agent 侧增加 collect.duration_seconds 与 collect.errors_total 自监控指标，当采集耗时超过基线 2 倍或错误率突增时，自动触发告警。

2.5 Agent 故障排查流程总图

以下 SVG 图展示了从“发现无数据”到“根因定位”的完整排查链路，涵盖网络、进程、配置、数据源四个维度。

Agent 故障排查流程总图 Agent 故障排查流程总图 发现 Agent 无数据 进程是否存活？ 启动 Agent 进程 网络是否可达？ 检查防火墙/DNS 配置是否正确？ 校验并重载配置 数据源可用？ 恢复数据源服务 数据恢复，问题解决 排查顺序建议 1. 进程 → 网络 2. 配置 → 数据源 3. 日志 → 自监控

2.6 自监控与预防体系

避免 Agent 故障的被动救火，需建立以下自监控机制：

监控项 采集方式 告警阈值
Agent 心跳 每 30s 上报 agent.alive 连续 3 个周期缺失 → P0 告警
采集指标数 每次采集后上报 agent.collect.count 环比下降 50% → P1 告警
采集耗时 插件级别记录 collect.duration_seconds 超过基线 3 倍 → P2 告警
进程资源 Agent 自监控 CPU/MEM/FD CPU > 80% 或 FD > 80% 上限 → P2 告警
最佳实践：将 Agent 自监控指标独立于业务采集链路，使用“带外”通道（如独立 UDP 包或本地日志文件）上报，避免因主链路故障导致自监控失效。

2.7 案例：一次“假死”的根因定位

现象：某 Java Agent 进程存活，但 Prometheus 连续 10 分钟未收到数据。

排查过程：

  1. jstack <PID> 发现 8 个线程全部处于 BLOCKED 状态，等待同一把锁。
  2. 分析锁对象，定位到自定义采集插件中使用了 synchronized 块且未设置超时。
  3. 查看 GC 日志，发现 Full GC 频率正常，排除内存问题。
  4. 修复：将同步块替换为 ReentrantLock 并添加 tryLock(5, TimeUnit.SECONDS)。
经验总结：Java Agent 假死 80% 由线程死锁或 IO 阻塞引起。优先使用 jstack 导出堆栈，不要盲目重启。
← 上一章 📖 返回目录 下一章 →