只要Prometheus能访问node_exporter的/metrics端点并正确配置static_configs即可采集数据；实际90%问题源于网络不通、路径错误或配置未重载，需用curl验证响应、检查防火墙、监听地址、YAML缩进及执行reload。
只要 Prometheus 能访问到 node_exporter 的 /metrics 端点，加一条 static_configs 就能拉到数据；但实际部署中，90% 的“没数据”问题出在地址不通、路径不对或配置没重载。
确认 node_exporter 是否真正可访问
别跳过这步——很多问题卡在这儿。Prometheus 抓取失败时，target 状态会显示 DOWN，但原因未必是配置写错，而是网络或服务本身没起来。
- 在 Prometheus 所在机器上执行：
curl -I http://192.168.100.131:9100/metrics（把 IP 换成你的node_exporter主机地址） - 返回必须是
200 OK，且响应头含Content-Type: text/plain; version=0.0.4 - 如果超时：检查防火墙（
sudo ufw status或sudo firewall-cmd --list-ports）、node_exporter是否监听0.0.0.0:9100（不是127.0.0.1:9100） - 如果 404：确认启动时没改
--web.telemetry-path，默认就是/metrics
prometheus.yml 中添加 scrape_configs 的正确写法
直接加在 scrape_configs 列表里，不要嵌套错层级。最简可用配置就三行，但必须对齐缩进（YAML 对空格敏感）：
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
scrape_configs:
- job_name: "node"
static_configs:
- targets: ["192.168.100.131:9100", "192.168.100.132:9100"]-
job_name建议用"node"，后续写 PromQL（如node_cpu_seconds_total）时语义清晰 -
targets里的地址必须是 Prometheus 主机能直接连通的 IP + 端口，不能写localhost（除非node_exporter和 Prometheus 在同一台） - 如果用了非标准路径（比如启用了
--web.telemetry-path="/node/metrics"），要显式加metrics_path：
- job_name: "node"
metrics_path: /node/metrics
static_configs:
- targets: ["192.168.100.131:9100"]配置更新后必须触发重载，否则不生效
Prometheus 不会自动读取新配置，改完 prometheus.yml 后，必须通知它重新加载。两种方式都行，但推荐用 HTTP API（更可控）：
- 确保启动 Prometheus 时加了
--web.enable-lifecycle参数（否则/-/reload会 404） - 执行：
curl -X POST http://127.0.0.1:9090/-/reload - 如果提示
Failed to reload config: couldn't load configuration，说明 YAML 格式有误，用在线 YAML 校验器（如 yamllint）查缩进或冒号 - 验证是否生效：打开
http://<prometheus-ip>:9090/targets</prometheus-ip>，看nodejob 下 targets 状态是否为UP
最容易被忽略的是：Prometheus 默认只抓取 localhost:9090 自身指标，加了新 job 后若没重载、没检查 targets 页面、也没在 Grafana 里用 node_* 前缀查指标，就会以为“配置失败”。其实只要 targets 显示 UP，数据就已经在时序库里了——剩下的只是查询和可视化的事。
