Prometheus + Grafana 在 Linux 服务器上需重点配置 scrape_config 中的目标 IP（非 localhost）、Grafana 数据源的 Access 模式（Server/Browser）匹配部署场景，以及 Dashboard 中 instance label 与实际采集值一致，三者任一出错即导致“no data”。
直接上结论：Prometheus + Grafana 在 Linux 服务器上不是“装完就能用”，核心卡点在 scrape_config 配置、target 可达性、以及 Grafana 数据源的 URL 和 Access 模式匹配——这三处出错，90% 的人会卡在“页面空白”或“no data”。
确认 Prometheus 能真正抓到指标（别信 localhost）
很多人把 prometheus.yml 里 targets: ['localhost:9090'] 当成万能写法，但实际部署时：localhost 指的是 Prometheus 进程自身所在容器/主机的回环地址，不是你浏览器访问的那台机器。若 Prometheus 运行在 Docker 容器中，而你要监控的是宿主机上的 Node Exporter，则必须用宿主机真实 IP 或 host.docker.internal（仅 Docker Desktop 支持），Linux 服务器请改用宿主机内网 IP（如 192.168.1.100:9100）。
实操建议：
- 先在 Prometheus 服务器上执行
curl http://<em>目标IP</em>:9100/metrics，确认返回文本格式指标（非 404 / connection refused） -
scrape_configs中的job_name建议带业务标识，比如job_name: 'prod-node'，避免和默认prometheusjob 冲突 - 若目标服务启用了 Basic Auth，必须在
static_configs同级加basic_auth块，不能只写在 URL 里
Grafana 添加 Prometheus 数据源时的 Access 模式陷阱
Web UI 中填完 URL: http://localhost:9090 后，Access 下拉菜单有两个选项：Server (default) 和 Browser。选错就查不到数据——这是最常被忽略的配置。
实操建议：
- 如果 Grafana 和 Prometheus 在同一台 Linux 服务器上，且都走 HTTP（无反向代理），选
Server即可，Grafana 后端直连 Prometheus - 如果 Grafana 前端通过 Nginx 反向代理暴露，而 Prometheus 仅监听
127.0.0.1:9090（未开放外网），必须选Server，否则浏览器会因同源策略失败 - 选
Browser仅适用于：Prometheus 明确监听0.0.0.0:9090且允许跨域（需配置--web-cors-origin="*"启动参数），生产环境不推荐
导入 Dashboard 后显示 no data？检查 label 匹配和时间范围
从 grafana.com 下载的热门 Dashboard（如 Node Exporter Full）依赖特定 label，比如 instance 必须包含端口号（192.168.1.100:9100），而你的 scrape_configs 若写了 static_configs: [{targets: ['192.168.1.100']}]，Prometheus 默认补 :9100，但某些旧版 exporter 或自定义 target 可能没带端口，导致 label 不一致。
实操建议：
- 在 Prometheus Graph 页面手动输入
count(node_cpu_seconds_total)，看是否返回数值；再用label_values(node_cpu_seconds_total, instance)查看实际采集到的instance值长什么样 - Dashboard JSON 里搜索
"expr"，找到关键查询语句，把其中的{instance=~"..."}临时删掉，看能否出图——能出说明是 label 匹配问题 - 右上角时间选择器别停留在
Last 6 hours就以为没问题，切到Now - 5m，Prometheus 默认 scrape interval 是 15s，太宽泛的时间范围可能命中空数据块
真正麻烦的从来不是安装命令，而是 scrape_configs 里的 IP 写对了没、Access 模式选对了没、Dashboard 里的 instance label 和你实际采集的一致吗——这三个地方一错，所有可视化都是幻觉。
