Grafana 仪表盘实战：变量、复用面板与一张合格的业务大盘
很多团队的 Grafana 里躺着几十张大盘，点开全是默认图：变量选不了、面板挤成一团、查询慢得打不开，最后出问题还是靠登录服务器看。问题不在 Grafana，而在大盘没有按"排障路径"来组织。本文以 Prometheus 数据源为例，讲清四个动作：先用 Explore 验证查询、再搭模板变量、写好三类核心面板、最后把大盘 JSON 纳入 Git 管理。环境口径：Grafana 11.x，Prometheus 2.x/3.x，指标来自 node_exporter 与应用自身暴露的 metrics。
前置条件
- Grafana 已部署并能登录，已有至少一个可用的 Prometheus 数据源。
- Prometheus 已在采集目标指标（主机指标或业务指标），且能从 Grafana 所在机器访问。
- 操作账号具备数据源查询权限与仪表盘编辑权限。
第一步：接入数据源后，先用 Explore 验证查询
在连接设置里添加 Prometheus 数据源并点 Save & test 通过，只说明网络通、接口活，不代表你的指标名和标签写对了。正式做面板之前，先到左侧 Explore 页面选该数据源，手写一条查询把三件事确认掉：指标存在、标签维度符合预期、时间范围内的曲线形状正常。例如先确认主机 CPU 指标与 instance 标签：
node_cpu_seconds_total{instance="192.0.2.11:9100", mode="idle"}
Explore 里可以把查询结果切到 Table 视图看原始序列与标签组合，先在这里把"该有的序列都有、不该有的没有"核对完，再进仪表盘编辑器，能省掉大量在面板里反复试错的时间。后续每个面板的查询，都建议先在 Explore 里调通再粘贴。
第二步：搭模板变量，做级联下拉
大盘要给不同主机、不同服务复用，靠的是模板变量。在 Dashboard settings → Variables 里新建变量。第一个变量 job，类型 Query，查询取自 label_values：
label_values(node_cpu_seconds_total, job)
第二个变量 instance，查询里引用第一个变量，实现级联过滤——先选 job，下拉里只出现该 job 下的主机：
label_values(node_cpu_seconds_total{job="$job"}, instance)
配置要点：instance 变量勾选 Multi-value 与 Include All 时，面板查询里要用正则匹配写 instance=~"$instance"，等值匹配在多选时会查不到数据，这是最常见的"变量一多选就没图"的原因。变量的刷新策略选 On Dashboard Load 即可，频繁变更的标签再考虑 On Time Range Change。面板查询中统一引用变量后，同一块大盘通过切换下拉就能看任意主机，不必一台主机复制一张盘。
第三步：核心面板的三类 PromQL 写法
业务大盘的面板无非三类查询：速率、比率、百分位。写法分别如下。
速率类：先 rate 再聚合
计数器类指标（请求数、CPU 时间）要先算每秒速率。CPU 使用率的标准写法：
100 - (avg by (instance) (rate(node_cpu_seconds_total{instance=~"$instance", mode="idle"}[5m])) * 100)
窗口 [5m] 与抓取间隔匹配，一般不小于 4 倍抓取间隔；窗口太小曲线锯齿严重且容易查空。
比率类：分子分母分别聚合再相除
错误率、成功率这类指标，正确姿势是分子分母各自 sum 后再除，不要先算每条序列的比率再平均：
sum(rate(http_requests_total{job="$job", status=~"5.."}[5m]))
/
sum(rate(http_requests_total{job="$job"}[5m]))
面板单位选 Percent (0.0-1.0) 或在查询外层乘 100 后用 Percent，二选一，不要混用导致数值对不上。
百分位类：用 histogram_quantile 算延迟
延迟看平均值没有意义，要看分位。前提是应用用 Histogram 类型暴露了 *_bucket 指标：
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket{job="$job"}[5m])))
注意聚合时必须保留 le 标签（sum by (le)），把 le 聚掉是算不出分位的常见错误。同一面板里叠加 P50/P95/P99 三条线，再配一条请求量速率面板上下对照，延迟突增时先看是不是流量变化带来的，一眼就能定性。
第四步：面板复用与行组织
大盘按排障顺序组织：用 Row 分成"总览（请求量、错误率、P95 延迟、饱和度）→ 资源（CPU、内存、磁盘、网络）→ 明细（分接口、分实例）"三行，总览行默认展开，明细行默认折叠。同类面板不要一张张手搓：选中面板 → Panel → More → Duplicate 复制后只改查询与标题；更进一步，同一指标看多个实例时用面板的 Repeat 功能按 instance 变量自动重复生成。Grafana 的 Library panels（库面板）适合跨大盘复用同一块面板，一处修改全盘生效，核心的"错误率""P95"这类面板建议沉淀进库面板。另外给每个面板写 Description 说明指标口径，接手的人不用猜这条线算的是什么。
第五步：告警与大盘联动
告警不要另起炉灶单独维护一套表达式。Grafana 11 的统一告警（Alerting → Alert rules）里可以直接基于大盘同款 PromQL 建规则，并在规则里通过 Dashboard UID 与 Panel ID 关联回对应面板，值班同学点开告警通知里的链接就能落到出问题的那块图上。规则的表达式与大盘查询保持同源同口径，避免出现"大盘看着正常、告警却在响"的口径打架。阈值与持续时间（for）在告警侧配置，大盘只负责展示，两边职责分清。
第六步：仪表盘纳入版本管理
大盘是配置资产，要进 Git。在仪表盘设置里打开 JSON Model 复制全文，或用 Share → Export 导出 JSON，保存为 grafana/dashboards/业务名.json 提交仓库；Grafana 侧通过文件供给（provisioning）把仓库里的 JSON 作为数据源目录加载，实现"改大盘 = 提 PR"。至少也要养成习惯：每次在界面上改完大盘，当场导出 JSON 提交一次，仓库历史就是大盘的变更记录，回滚时把旧 JSON 重新导入即可。注意导出时把数据源写成变量引用（${DS_PROMETHEUS} 这类 provisioning 变量）而不是写死某个环境的 UID，JSON 才能跨环境复用。
验证
- 切换 job 与 instance 下拉，全部面板随之刷新且无 No data（人为选一台无指标的主机除外）。
- 把大盘时间范围切到最近一次已知故障时段，错误率与 P95 面板能复现当时的异常形状。
- 导出的 JSON 在另一套 Grafana（或新建文件夹导入）能正常打开且数据源不报错。
- 从告警规则的链接点进来，能定位到对应仪表盘与面板。
常见问题
变量联动失效，选了 job 但 instance 列表不更新。先查 instance 变量的查询是否真的引用了 $job 且标签名与指标实际标签一致，再确认变量刷新策略不是 Never；还有一个隐蔽点：级联变量的查询本身也要受数据源变量影响时，要在变量定义里显式选对数据源，老版本里变量默认数据源与面板数据源不一致会查空。
查询超时或大盘打开要十几秒。多半是高基数指标配长窗口 rate、或一张盘塞了几十个面板同时查 30 天范围。处理顺序：给大盘设默认时间范围（如近 6 小时）、给重查询面板单独设 Max data points 与 Min interval、Prometheus 侧对高频查询的表达式做 Recording Rule 预聚合。先降负载再谈加机器。
大盘越做越慢、越改越乱。根源是没人管口径与命名：定三条规矩——面板标题写"指标 + 单位"，查询表达式进 PR 时要评审，大盘按业务线分文件夹并指定负责人。没有归属的大盘半年必烂。
图上莫名出现断点。先区分是采集断了还是查询断了：去 Explore 用同一表达式拉原始序列，原始序列也断就是采集或目标存活问题，与大盘无关，别在大盘里瞎调。
小结
一张合格的业务大盘标准不高：变量能切换、口径说得清、按排障顺序排、变更进 Git。把这四条做扎实，大盘才会从"截图汇报用"变成真正的值班工具。
