部署完监控却看不到数据，是很多人接入 Prometheus 时都会卡住的一步：node_exporter 明明已经启动，Prometheus 的 Targets 页面却一直显示 DOWN，或者干脆查不到任何指标。这篇文章解决的就是这个问题——教你如何系统排查 Prometheus 抓取 node_exporter 失败的各类故障，按”目标不可达、端口未监听、抓取超时、数据缺失”四类逐一给出具体命令和修复方法。与从零部署教程不同，本文默认你的监控链路已经搭好，重点放在故障定位上。看完之后，大多数抓取问题你都能在十分钟内定位到具体环节。
先分清四种故障形态
处理抓取问题之前，先在 Prometheus 的 Status → Targets 页面确认你的目标处于哪种状态，这直接决定了排查方向。四种形态对应的病因完全不同，混在一起查会浪费大量时间：
- UP 但数据为空：抓取链路正常，问题在 exporter 采集层或指标名称
- DOWN 且报 connection refused：目标机器或端口不通，先查进程和监听
- DOWN 且报 context deadline exceeded：网络或负载导致超时，先看延迟和资源
- 目标根本不在列表里：抓取配置没生效，查 prometheus.yml 与重载操作
打开 Targets 页面的 Error 列，把错误信息复制下来对照上面的分类。比如显示 Get "http://10.0.0.5:9100/metrics": dial tcp 10.0.0.5:9100: connect: connection refused，就属于第二类，可以直接跳到对应章节处理，不用从头排查。更多监控链路的部署背景，可以结合我们的服务器博客专区里的相关文章一起看。
目标不可达：进程与监听检查
connection refused 说明 Prometheus 能找到这台机器，但 9100 端口没有人应答。最常见的两个原因是 node_exporter 进程挂了，或者监听地址配成了 127.0.0.1。登录目标服务器依次执行这三条命令，一分钟内就能定位：
systemctl status node_exporter
ss -tlnp | grep 9100
curl -s http://127.0.0.1:9100/metrics | head -5
如果 systemctl 显示 inactive 或 failed，先看日志找退出原因：journalctl -u node_exporter --since "10 min ago"。常见的是配置文件参数写错导致启动失败，修正后 systemctl restart node_exporter 即可。如果进程正常但 ss 输出里监听地址是 127.0.0.1:9100，说明启动参数带了 --web.listen-address=127.0.0.1:9100，改成 0.0.0.0:9100 并重启，让外部网卡也能访问。第三条 curl 命令能输出一堆 # HELP 开头的文本，才说明本机采集正常，问题确实出在网络层。如果排查下来发现目标机器本身配置过低、资源长期吃紧，也可以考虑升级到独立服务器来承载监控负载。
网络层排查用两条命令收尾：在 Prometheus 所在机器执行 curl -m 5 http://<目标IP>:9100/metrics 验证连通性，不通的话再查中间的防火墙。云服务器（云端租用的虚拟化服务器）场景优先检查安全组是否放行了 9100 端口——这是新手抓取失败最高频的原因。如果你用的是 Hostease 的云服务器或独立服务器，可以在控制面板里直接编辑防火墙规则放行该端口，改完立即生效，不用重启实例。
抓取超时：超时与资源瓶颈
context deadline exceeded 说明连接能建立，但 Prometheus 在设定的抓取窗口内没拿到完整响应。默认抓取超时是 scrape_timeout 减去一个余量（默认 10 秒窗口），一台负载很高的机器很容易超时。分三步定位：
time curl -s http://<目标IP>:9100/metrics -o /dev/null
top -bn1 | head -5
grep -c "" /proc/net/dev
第一条命令直接测量 /metrics 接口的真实响应时间。如果本地 curl 都要十几秒，问题在目标机器自身——通常是 node_exporter 采集某些指标时被系统调用拖慢，比如挂载了故障的 NFS 目录会让文件系统统计卡住。用 --collector.disable-defaults --collector.enable=cpu,memory,meminfo,diskstats,filesystem,loadavg,netdev 只启用核心采集器做对比测试，能快速锁定是哪个采集器拖慢了响应。
如果本地 curl 秒回但 Prometheus 仍然超时，问题多半在网络延迟或 Prometheus 自身负载。前者用 ping 和 mtr 检查跨机房链路质量，跨地域抓取建议把 scrape_interval 放宽到 30s 以上；后者查看 Prometheus 进程的 CPU 和内存占用，目标数量超过几百个时单实例容易吃紧，这时应该按业务线拆分实例或启用联邦集群。关于多实例的架构取舍，可以参考我们之前写的 Prometheus Node Exporter 监控 VPS：容量告警配置指南，里面对比了单机与分层监控的适用场景。
数据缺失：指标查不到的三个原因
目标显示 UP，但在 Prometheus 里查不到预期指标，通常是这三种情况。逐一对照处理，绝大多数能当场解决：
- 指标名写错：用
curl -s http://<目标IP>:9100/metrics | grep <关键词>确认真实指标名，PromQL 区分大小写且下划线不能写错 - 时间范围选错：Graph 页面默认展示最近 1 小时，确认查询时间范围覆盖目标刚变成 UP 的时刻
- 查询语句语法问题：node_exporter 返回的是带标签的指标，比如按设备区分的磁盘指标，查询时漏掉标签过滤会导致结果被聚合或为空
特别提醒第一点：很多教程里写的指标名来自旧版本 node_exporter，新版本已经拆分或改名。例如内存相关指标在新版本中是 node_memory_MemAvailable_bytes 而不是早期文档里的 node_memory_MemFree 单位写法，网卡指标 node_network_receive_bytes_total 也常被误写成 receive_bytes。验证方法很简单，直接 curl 抓取端点 grep 一下，以实际输出为准，不要凭记忆写 PromQL。
另一个隐蔽原因是查询时间线的 stale 标记。如果目标曾经 DOWN 过一段时间，之前时间段的图会显示为空，这属于正常现象而不是数据丢失；把时间范围调大，确认 UP 之后的时间段有数据即可。
告警没触发：从规则到通知逐段验证
数据能查到了，下一步是让告警真正发出来。这条链路有四个环节，任何一环断掉都会导致”故障发生了却没人知道”。我们建议按数据流向逐段验证，而不是盯着一处反复改：
- Alertmanager 页面确认告警已到达且状态是 firing
- prometheus.yml 中 alerting 段的 alertmanager 地址、端口正确且可达
- 路由规则 route 的匹配标签与告警标签一致，否则告警会被路由到空接收器
- receiver 配置的通知渠道参数（SMTP、webhook）经实际测试可用
初次接入监控的读者如果对整套链路还不熟悉，建议先阅读网站性能优化指南了解指标与体验的关系，再回到本文处理具体故障。
验证前两环的快速方法：在 Prometheus 的 Alerts 页面看规则是否处于 PENDING 或 FIRING 状态。规则一直 PENDING 不变，通常是 for 持续时间设得太长，比如故障只持续了 3 分钟但规则要求持续 5 分钟才触发。把 for 参数调短到与业务容忍度匹配，或者临时把表达式改成必然触发的条件（如 vector(1)）做一次端到端演练，确认告警能走完整个链路到达通知渠道，再改回真实规则。邮件通知发不出来时，优先检查 Alertmanager 日志里的 SMTP 认证错误，这是最高频的配置问题。
整套链路验证通过后，建议保留一条低危的测试告警规则（比如某台测试机的假指标），每周自动触发一次，持续验证通知渠道没有悄悄失效。
建立固定的排障顺序
抓取类故障看着花样多，但排查路径其实是固定的：先看 Targets 页面的状态和错误信息定类，再按”进程与监听 → 网络 → 超时与资源 → 指标与查询 → 告警链路”的顺序逐层深入。我们建议把这个顺序存成团队内部的排障清单，遇到问题照单执行，避免每个人各查各的方向。如果你在 Hostease 的 VPS（虚拟专用服务器）或独立服务器上部署监控时遇到本文覆盖不了的问题，可以提交工单，我们的技术支持团队会协助检查网络与防火墙层面；监控配置层面的深入调优，则建议结合业务指标量级参考 PromQL（Prometheus 查询语言）官方文档逐步优化。
