grafana 显示“no data”主因是数据源未真正连通，而非查询错误；需验证api可达性、access模式适配、反向代理头透传、时间范围动态变量及node_exporter路径/权限/selinux配置。
为什么 datasource 配置完却显示 “No data”？
Grafana 里加了 Prometheus 或 InfluxDB 数据源，面板也建好了，但曲线始终空着——大概率不是查询写错了，而是数据源本身没真正连通。Grafana 的 UI 提示“Success”只代表能 ping 通地址，不等于能读到指标。
- 检查
<a href="https://www.php.cn/link/2ff16a5f2babf0a440ff9fc0be52960c">https://www.php.cn/link/2ff16a5f2babf0a440ff9fc0be52960c</a> 是否能直接 curl 通，且返回有效 JSON（注意：不是 404 或 502）
- 确认数据源配置里的
Access 模式：用 Server (default) 时，Grafana 后端去拉数据，需确保 Grafana 容器/进程能访问目标数据库；选 Browser 则由前端发请求，受浏览器同源策略限制，本地开发常用但生产环境基本不可用
- 如果用了反向代理（如 Nginx），确认是否透传了
X-Forwarded-For 和 Authorization 头，否则某些带认证的数据源会静默失败
如何让 Prometheus 查询在 Grafana 里正确识别时间范围？
手动写 rate(http_requests_total[5m]) 时，看起来没问题，但切到“Last 6 hours”面板却没数据——因为 Prometheus 查询模板默认不自动适配 Grafana 时间范围，得靠变量和函数配合。
- 在查询编辑器中启用
Relative time 模式（右上角时钟图标），或显式用 $<strong>range</strong> 替代硬编码区间，例如：rate(http_requests_total[$range])
- 注意
$<strong>range</strong> 是动态字符串（如 1h），不能直接用于 offset；需要偏移历史数据时，改用 $interval 或写死 offset 1h
- 如果查询含
time() 或 timestamp()，它们返回的是 Unix 秒级时间戳，而 Grafana 时间选择器传入的是毫秒，混用会导致时间错位
Linux 主机监控没指标？检查 node_exporter 的暴露路径和权限
装了 node_exporter，curl localhost:9100/metrics 能看到指标，但 Grafana 还是空——常见于路径、权限、SELinux 三重干扰。
- 默认指标路径是
/metrics，但有些发行版打包会改成 /metrics/textfile 或加前缀，务必在数据源的 HTTP URL 后补全，比如 <a href="https://www.php.cn/link/7c23287c6dd3acd5f4fae4175be75c7e">https://www.php.cn/link/7c23287c6dd3acd5f4fae4175be75c7e</a>
- systemd 启动的
node_exporter 可能被限制访问 /proc 和 /sys，运行 sudo systemctl status node_exporter 查看是否有 Permission denied 日志
- SELinux 开启时，
node_exporter 默认不允许绑定网络端口，需执行 sudo setsebool -P node_exporter_can_network=on（RHEL/CentOS）
面板刷新慢或超时，别只调 timeout 参数
面板加载要 10 秒以上，甚至报 Query timeout，第一反应是加大 Timeout，但更可能是查询本身低效或数据量失控。
- 在 Prometheus 中先用
<a href="https://www.php.cn/link/76e7fa167c6a800e4907a525e8dad878">https://www.php.cn/link/76e7fa167c6a800e4907a525e8dad878</a> 手动跑同样查询，看响应时间和样本数；超过 10 万样本就容易卡住
- 避免在大时间范围内用无标签过滤的
count({job="node"})，改用 count by (instance) ({job="node"}) 分组聚合，减少传输量
- Grafana 数据源配置里的
Query timeout 单位是秒，但实际生效还受 Prometheus 的 --query.timeout 和 --query.max-concurrency 限制，后者默认仅 20，并发查多个面板时会排队
<a href="https://www.php.cn/link/2ff16a5f2babf0a440ff9fc0be52960c">https://www.php.cn/link/2ff16a5f2babf0a440ff9fc0be52960c</a> 是否能直接 curl 通，且返回有效 JSON（注意：不是 404 或 502）Access 模式：用 Server (default) 时，Grafana 后端去拉数据，需确保 Grafana 容器/进程能访问目标数据库；选 Browser 则由前端发请求，受浏览器同源策略限制，本地开发常用但生产环境基本不可用X-Forwarded-For 和 Authorization 头，否则某些带认证的数据源会静默失败rate(http_requests_total[5m]) 时，看起来没问题，但切到“Last 6 hours”面板却没数据——因为 Prometheus 查询模板默认不自动适配 Grafana 时间范围，得靠变量和函数配合。
- 在查询编辑器中启用
Relative time模式（右上角时钟图标），或显式用$<strong>range</strong>替代硬编码区间，例如：rate(http_requests_total[$range]) - 注意
$<strong>range</strong>是动态字符串（如1h），不能直接用于offset；需要偏移历史数据时，改用$interval或写死offset 1h - 如果查询含
time()或timestamp()，它们返回的是 Unix 秒级时间戳，而 Grafana 时间选择器传入的是毫秒，混用会导致时间错位
Linux 主机监控没指标？检查 node_exporter 的暴露路径和权限
装了 node_exporter，curl localhost:9100/metrics 能看到指标，但 Grafana 还是空——常见于路径、权限、SELinux 三重干扰。
- 默认指标路径是
/metrics，但有些发行版打包会改成 /metrics/textfile 或加前缀，务必在数据源的 HTTP URL 后补全，比如 <a href="https://www.php.cn/link/7c23287c6dd3acd5f4fae4175be75c7e">https://www.php.cn/link/7c23287c6dd3acd5f4fae4175be75c7e</a>
- systemd 启动的
node_exporter 可能被限制访问 /proc 和 /sys，运行 sudo systemctl status node_exporter 查看是否有 Permission denied 日志
- SELinux 开启时，
node_exporter 默认不允许绑定网络端口，需执行 sudo setsebool -P node_exporter_can_network=on（RHEL/CentOS）
面板刷新慢或超时，别只调 timeout 参数
面板加载要 10 秒以上，甚至报 Query timeout，第一反应是加大 Timeout，但更可能是查询本身低效或数据量失控。
- 在 Prometheus 中先用
<a href="https://www.php.cn/link/76e7fa167c6a800e4907a525e8dad878">https://www.php.cn/link/76e7fa167c6a800e4907a525e8dad878</a> 手动跑同样查询，看响应时间和样本数；超过 10 万样本就容易卡住
- 避免在大时间范围内用无标签过滤的
count({job="node"})，改用 count by (instance) ({job="node"}) 分组聚合，减少传输量
- Grafana 数据源配置里的
Query timeout 单位是秒，但实际生效还受 Prometheus 的 --query.timeout 和 --query.max-concurrency 限制，后者默认仅 20，并发查多个面板时会排队
/metrics，但有些发行版打包会改成 /metrics/textfile 或加前缀，务必在数据源的 HTTP URL 后补全，比如 <a href="https://www.php.cn/link/7c23287c6dd3acd5f4fae4175be75c7e">https://www.php.cn/link/7c23287c6dd3acd5f4fae4175be75c7e</a>
node_exporter 可能被限制访问 /proc 和 /sys，运行 sudo systemctl status node_exporter 查看是否有 Permission denied 日志node_exporter 默认不允许绑定网络端口，需执行 sudo setsebool -P node_exporter_can_network=on（RHEL/CentOS）timeout 参数
面板加载要 10 秒以上，甚至报 Query timeout，第一反应是加大 Timeout，但更可能是查询本身低效或数据量失控。
- 在 Prometheus 中先用
<a href="https://www.php.cn/link/76e7fa167c6a800e4907a525e8dad878">https://www.php.cn/link/76e7fa167c6a800e4907a525e8dad878</a>手动跑同样查询，看响应时间和样本数；超过 10 万样本就容易卡住 - 避免在大时间范围内用无标签过滤的
count({job="node"})，改用count by (instance) ({job="node"})分组聚合，减少传输量 - Grafana 数据源配置里的
Query timeout单位是秒，但实际生效还受 Prometheus 的--query.timeout和--query.max-concurrency限制，后者默认仅 20，并发查多个面板时会排队
Grafana 配置真正的难点不在界面点几下，而在于每个环节都依赖上下游服务的状态一致性——从 node_exporter 的权限、到反向代理的头字段、再到 Prometheus 的采样精度，漏掉任意一环，都会表现为“没数据”这种模糊错误。
