看板性能优化清单
看板慢的根因集中在两处：查询量太大与渲染量太多。优化思路是先聚合再展示、给变量查询加选择器、把高频重查询交给记录规则、控制刷新间隔与默认时间窗。每一项都能单独见效，组合起来效果更明显，且可用 Query Inspector 的 Stats 做前后对比。
基本信息
| 优化层面 | 查询层 / 变量层 / 预处理 / 展示层 / 时间窗 |
|---|---|
| 衡量手段 | Query Inspector 的 Stats 耗时与数据量 |
| 最常见瓶颈 | 未聚合的高基数查询与过长时间窗 |
| 预处理手段 | 记录规则预计算 |
| 刷新建议 | 值班看板 1m 起步，不必更密 |
| 默认时间窗 | 贴合业务需要，不要都设 7 天 |
典型使用场景
- 值班大屏打开缓慢，先优化被高频打开的核心看板
- 变量下拉框加载很久，用 label_values 带选择器收窄范围
- 长区间曲线渲染卡顿，先做聚合或改用记录规则
- 多实例看板曲线过多，用 topk 或标签过滤减少序列
- 告警风暴时看板卡死，检查是否所有面板都在跑重查询
- 把优化前后的 Stats 记录下来，作为看板维护的变更依据
五点速查
五点速查
# 1. 查询层：先聚合再画
sum by (route) (rate(http_requests_total[5m]))
# 2. 变量层：label_values 带选择器
label_values(up{job="api"}, instance)
# 3. 预处理：高频重查询用 recording rules 落盘
# 4. 展示层：Max data points 固定、刷新 >= 1m
# 5. 范围层：默认时间窗贴合业务需要，别默认 7 天优化项与预期收益
| 优化项 | 做法 | 收益 |
|---|---|---|
| 先聚合再展示 | sum by 后再画 | 减少序列数与渲染负担 |
| 变量加选择器 | label_values 带标签过滤 | 变量查询显著变快 |
| 记录规则预计算 | 复杂表达式落盘 | 看板查询变成简单取值 |
| 控制时间窗 | 默认 1h 或 6h | 减少数据点与传输量 |
| 限制刷新 | 固定 1m 以上 | 降低数据源与浏览器压力 |
优化前后用 Query Inspector 的 Stats 对比耗时与数据量，改动有据可查，也方便向团队说明收益。
优先修高频打开的核心看板：全量铺开容易顾此失彼，收益也不明显。
把一切归因到 Grafana 之前，先看每段查询的实际耗时：多数「Grafana 慢」其实是查询本身慢。
面板数不是问题，同时发起的重查询才是：把长区间面板放进折叠行或改为按需刷新，能明显改善首屏速度。