node-exporter必须运行在被监控物理机本地且默认监听:9100；grafana不采集数据，仅从prometheus查询渲染图表，“node-exporter+grafana”缺prometheus无法运行。
Node-Exporter 必须运行在被监控物理机本地，且默认监听 :9100；Grafana 本身不采集数据，只负责从 Prometheus 查询并渲染图表——所以“Node-Exporter + Grafana”这个组合缺了 Prometheus 就完全跑不起来。
node_exporter 启动后访问 http://localhost:9100/metrics 返回空或 404
这不是 Grafana 的问题，而是 node_exporter 没真正提供指标。常见原因有：
- 进程启动失败但没报错：用
ps aux | grep node_exporter确认进程是否存在；若无，检查是否被 SELinux 或防火墙拦截（setsebool -P prometheus_can_network on或临时setenforce 0） - 二进制权限问题：某些系统（如 CentOS 7）需加
--no-collector.wifi --no-collector.xfs避免因内核模块缺失导致启动卡住 - 端口被占用：
lsof -i :9100查看冲突进程，改用--web.listen-address=":9101"换端口 - 指标路径不是
/metrics：确认没误加--web.route-prefix，否则真实路径会变成/prefix/metrics
prometheus.yml 中 targets 写 localhost:9100 却抓不到数据
Prometheus 默认从自身所在机器发起抓取请求，localhost 指的是 Prometheus 进程所在的机器，不是被监控的物理机。部署时容易混淆这点：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 如果 Prometheus 和 node_exporter 在同一台物理机：用
localhost:9100是对的 - 如果 Prometheus 装在 A 机，node_exporter 装在 B 机（典型物理机监控场景）：
targets必须写 B 机的真实 IP，例如['192.168.1.102:9100']，不能写localhost - 确保 B 机的
firewalld或ufw放行9100端口（firewall-cmd --permanent --add-port=9100/tcp） - 抓取失败时，去 Prometheus UI 的
Status > Targets页面看具体错误（如connection refused或timeout）
Grafana 添加 Prometheus 数据源后测试成功，但导入面板显示 “No data”
这说明连接通了，但查询不到有效时间序列。重点排查指标是否存在和标签匹配：
- 先在 Prometheus UI 的 Graph 页面手动执行
node_cpu_seconds_total，看是否有结果；没有就说明 node_exporter 根本没上报成功 - 检查 job 名称和 instance 标签是否与面板 JSON 中的变量一致：比如面板里写的是
job="linux"，但你的prometheus.yml里是job_name: "physical-server"，就会查不到 - 部分旧版 Grafana 面板（如 ID 1860）默认用
instance=~".*"，而新版本 node_exporter 可能带上了主机名+端口（如host.example.com:9100），需要改成instance=~".+:9100"或直接删掉该过滤条件 - 确认 scrape_interval 设置合理（建议 ≤30s），太长会导致首次加载延迟明显
最容易被忽略的一点：node_exporter 默认不收集某些高开销指标（如 textfile、bonding），但如果你手动启用了 --collector.systemd，却没装 systemd-devel 或权限不足，整个进程可能静默退出——务必用 journalctl -u node_exporter -n 50 看真实日志，别只信 ps 显示在运行。
