先看现象。Grafana 10.2 接 Prometheus 2.45，面板顶部加了 instance 变量，query 用的是 label_values(up)，打开面板要转十几秒，超时后下拉框空白，下面所有面板都显示 No data。
把日志和配置对完，能解释这个现象的基本就这几处。变量查询没带时间范围和 label 过滤，扫了全量时序。还有一种是label_values 在几百万条序列上开销很大，数据源默认超时只有 30 秒。
少数情况下是面板刷新时变量会重新求值，打开一次触发多轮查询。
不容易想到的是，Prometheus 前面挂了反代，60 秒的读超时先把连接断了。
手工跑一次变量查询看耗时
time curl -s '127.0.0.1:9090/api/v1/label/instance/values' | head -c 200接着看一小时内的序列规模
curl -s '127.0.0.1:9090/api/v1/series?match[]=up&start=-1h' | jq '.data | length'再往下改成带 match 过滤的查询
curl -s '127.0.0.1:9090/api/v1/label/instance/values?match[]=up{job="node"}'调大 Grafana 数据源超时
grep -n -A5 'timeout' /etc/grafana/provisioning/datasources/prom.yml改完先别撤，确认这几项。变量下拉框三秒内加载完成，面板打开不再空白，Grafana 查询日志里没有 context deadline exceeded。
提醒一点。变量查询要尽量带 match 和时间范围，label_values 不带过滤在序列多的环境里几乎不可用；数据源超时只是兜底。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。