Grafana 监控可视化

这篇笔记以 Grafana 官方文档为主线，围绕 data source、dashboard、panel、variable、Explore、alerting 与 provisioning 展开，重点说明 Grafana 在可观测性体系中的职责边界，以及它与 Prometheus 等后端的协作关系。

行文重点放在对象模型、查询链路、变量体系、排障方式、告警机制和 as-code 管理，不把 Grafana 简化为“连上 Prometheus 画图”的操作手册。

参考资料：

官方文档：Data sources 、 Dashboards 、 Panels and visualizations 、 Transform data

可视化与排障：Explore 、 Alerting

平台治理：Provisioning 、 Roles and permissions 、 Dashboard JSON model

[TOC]

1. Grafana 是什么

一句比较准确的概括是：

• Grafana 是一个面向观测数据的查询、可视化、探索与协作平台

它通常不承担“原始指标存储后端”的职责，而是：

• 连接数据源
• 发起查询
• 对结果做展示与整理
• 让人更高效地理解系统状态

Grafana 官方文档对 data source 的定义非常清楚：

• data source 是连接后端存储的入口
• Grafana 通过这些入口查询 metrics、logs、traces、profiles 等数据，再进行展示

因此最核心的一点是：

• Grafana 不是“存数据的地方”
• Grafana 是“把不同数据源组织成可观测界面的地方”

2. Grafana 不是什么

它不是 Prometheus

Prometheus 更偏：

• 指标采集
• 时序存储
• PromQL 查询
• 规则评估

Grafana 更偏：

• 展示
• 交互式查询
• 仪表盘组织
• 多数据源观察

它不是数据库

Grafana 官方文档明确说明：

• data source 才是数据真正所在的 backend

Grafana 只是：

• 把查询发过去
• 接结果回来
• 在 UI 中呈现

它也不是“只能看 metrics”

初次接触 Grafana 时，最常见的误解之一是：

• Grafana = Metrics Dashboard

实际上它可以连接很多类型的数据源，例如：

• Prometheus
• Loki
• Tempo
• Elasticsearch
• PostgreSQL
• MySQL
• 云监控服务

这意味着 Grafana 的价值并不局限于：

• 指标画图

而是：

• 统一观测入口

3. 为什么 Grafana 很重要

如果说 Prometheus 解决的是：

• 数据怎么采、怎么存、怎么算

Grafana 解决的就是：

• 人怎么高效理解这些数据

把“会查”变成“能看懂”

很多系统并不是没有数据，而是：

• 数据存在，但很难形成稳定观察视角
• 数据很多，但切换成本高
• 查询能力很强，但无法形成共享视图

Grafana 的价值就在这里：

• 把零散查询变成持续可用的观察界面

多数据源是它的关键优势

Grafana 官方文档强调：

• 一个 data source 就是一个后端连接

而 Grafana 可以同时挂多个 data source。

这带来的工程价值很大：

• 一张 dashboard 里同时看 metrics 和 logs
• 一个排障流程里同时看 Prometheus 和 SQL
• 同一个团队统一在一个入口观察不同系统

它是“团队协作层”

Prometheus 很强，但原生表达式浏览器更像：

• 专业工程师的临时调试工具

Grafana 更像：

• 团队可共享的可观测界面

它更适合承载：

• 日常看板
• 值班大盘
• 业务监控盘
• 管理层总览

4. Grafana 的核心对象

理解 Grafana，最好先理解下面几个核心对象：

• Data source
• Dashboard
• Panel
• Variable
• Explore

Data source

Grafana 官方文档定义得很直接：

• data source 是连接数据存储后端的入口

每个 data source 会提供：

• 自己的 query editor
• 自己的数据查询能力

因此，Grafana 查询 Prometheus 用的是：

• PromQL

查询 SQL 数据库用的是：

• SQL

Grafana 不会把这些语言硬统一成一种语言，它更像：

• 给不同后端提供统一的观察界面

Dashboard

Dashboard 可以理解成：

• 一组围绕某个主题组织起来的 panel 集合

例如：

• 服务总览 dashboard
• JVM dashboard
• Redis dashboard
• 业务订单 dashboard

Panel

Grafana 官方文档明确说明：

• panel 是 dashboard 的基本构建块
• 每个 panel 由 query 和 visualization 组成

这是一个很重要的认知：

• 一个 panel 不等于一个图
• 它是“查询结果 + 展示方式”的组合

Variable

Variable 的作用是：

• 让 dashboard 变成可切换、可复用、可参数化的界面

例如：

• 切环境
• 切集群
• 切实例
• 切命名空间

Explore

Explore 是 Grafana 中非常高价值、但常被忽略的能力。

它更像：

• 临时分析台

适合：

• 现场排障
• 快速试查询
• 顺着标签钻取数据

它不是固定 dashboard，而是：

• 即席探索空间

Folder 与 Library panel

如果只理解前面五个对象，已经可以覆盖绝大部分日常使用；但到了团队化阶段，还经常会接触两个组织层对象：

• Folder：用于组织 dashboard，也常常是权限控制的主要边界
• Library panel：把可复用 panel 抽成共享对象，便于在多张 dashboard 中统一维护

这两个对象不直接决定查询语义，但会直接影响：

• dashboard 组织方式
• 权限隔离
• 跨看板复用能力

5. Data source 是 Grafana 的入口

为什么 data source 不是小概念

Grafana 官方文档把 data source 定义为：

• 查询、面板、Explore、Alerting 的输入来源

这说明它不是“顺手配置一下的连接”，而是整个 Grafana 的基础能力入口。

一个 data source 配好后，Grafana 可以基于它：

• 写 panel query
• 在 Explore 中临时查询
• 建 alert rule

每个 data source 都有自己的 query editor

这一点非常关键。

Grafana 不会把 Prometheus、Loki、SQL 的语法硬统一。

它的设计更偏向：

• 用统一 UI 包裹不同后端的原生查询能力

因此，使用 Grafana 并不意味着可以绕开后端查询语言。更准确的理解是：

• Grafana 统一的是入口和交互界面
• 真正的查询语义仍然属于对应后端

查询链路长什么样

从执行边界看，一次 Grafana 查询大致会经过下面这条链路：

flowchart LR
  U[用户 / Dashboard / Explore] --> G[Grafana 查询层]
  G --> D[Data source 插件]
  D --> B[后端数据源<br/>Prometheus / Loki / SQL]
  B --> R[查询结果]
  R --> T[Transform / Field config / Visualization]
  T --> P[Panel 展示或告警计算]

这个链路有两个边界特别容易混淆：

• 查询的解释与执行通常发生在后端数据源，而不是 Grafana 自己内部
• 展示层上的 transform、field config、threshold 主要服务于可视化与整理，不等于后端存储语义

默认数据源和权限

Grafana 官方文档提到：

• 可以设置默认 data source
• 组织管理员才能添加或删除 data source

从权限模型看，还需要区分几类角色：

• Viewer：主要负责查看 dashboard 和查询结果
• Editor：可以编辑 dashboard、panel、folder 等内容
• Admin：负责组织级配置和资源管理

在 OSS 的默认权限模型下，Viewer 并不承担 data source 管理职责，Explore 也不是默认面向所有角色开放的“无边界调试台”。如果需要更细粒度的数据源权限控制，则通常要结合 Enterprise / Cloud 的 RBAC 能力理解。

Grafana 接 Prometheus，本质上就是“把 Prometheus 配成 data source”

“Grafana 接 Prometheus”最准确的表述就是：

• 把 Prometheus 配成 Grafana 的 data source

更具体地说，Grafana 并不是“导入 Prometheus 数据”，而是：

• 在 Grafana 里注册一个 Prometheus 连接
• 让 Grafana 知道去哪个 Prometheus 发 PromQL 查询
• 再把查询结果交给 Explore、Panel、Alerting 等能力使用

整个过程可以理解成两步：

1. 先连上 Prometheus
2. 再在 Grafana 里消费 Prometheus 的查询能力

因此可以把这件事概括为：

• Grafana 接 Prometheus = 把 Prometheus 配成 data source，然后在 Grafana 里写 PromQL

一个最小可跑通的实战案例

假设本机已经有：

• Grafana：http://localhost:3000
• Prometheus：http://localhost:9090

目标是：

• 让 Grafana 连上 Prometheus
• 在 Grafana 里查到 up
• 做出第一个最小监控图

第 1 步：在 Grafana 中添加 Prometheus 数据源

进入：

• Connections -> Data sources -> Add data source -> Prometheus

然后重点填写这几个配置：

• Name：Prometheus
• URL：http://localhost:9090

接着点击：

• Save & test

如果配置正确，通常会看到成功提示，说明：

• Grafana 已经能访问 Prometheus

到这一步，就完成了“Grafana 接 Prometheus”里最核心的动作。

第 2 步：先去 Explore 验证查询

进入：

• Explore

选择刚才创建的 Prometheus data source，然后先试最简单的查询：

up

这个表达式的含义非常直接：

• up = 1 表示目标最近一次抓取成功
• up = 0 表示目标抓取失败

如果这里已经能看到折线或表格结果，说明：

• Grafana 到 Prometheus 的链路是通的
• Prometheus 本身也已经抓到了目标

还可以继续试两个更像真实使用场景的查询：

sum by (job) (up)

rate(http_requests_total[5m])

到这里更容易建立正确认知：

• PromQL 仍然是 Prometheus 的能力
• Grafana 只是把这个查询过程做成了更易使用的界面

第 3 步：把 Explore 里的查询固化成一个 Panel

如果 Explore 里已经查通，就去新建 dashboard：

• Dashboards -> New -> New dashboard -> Add visualization

选择 Prometheus data source，先做一个最小可用图表。

比如想看每个实例的请求速率，可以写：

sum by (instance) (rate(http_requests_total[5m]))

一个常见的配置组合是：

• Visualization：Time series
• Unit：根据指标语义选择，例如 req/s
• Legend：显示 instance

如果暂时没有业务指标，最小验证也可以直接用：

up

这时就已经完成了一个完整闭环：

1. Prometheus 采集指标
2. Grafana 把 Prometheus 配成 data source
3. 在 Explore 验证 PromQL
4. 在 Dashboard 里把查询做成 panel

第 4 步：一个更贴近实际工作的服务总览小例子

如果要给某个 HTTP 服务做最小监控盘，通常至少会先放 3 个 panel：

1. 请求速率
2. 错误率
3. 延迟

例如：

请求速率：

sum(rate(http_requests_total[5m]))

5xx 错误率：

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

P95 延迟：

histogram_quantile(
  0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

这个例子很能说明 Grafana 和 Prometheus 的分工：

• 指标名字、标签、PromQL 语义来自 Prometheus 体系
• 图表组织、展示、变量切换、团队共享来自 Grafana

最常见的几个踩坑

“Grafana 没连上 Prometheus”这类判断，很多时候并不准确，问题常常出在下面几类：

踩坑 1：localhost 填对了自己，但填错了 Grafana

如果 Grafana 和 Prometheus 都跑在本机，下面这个地址通常没问题：

1
http://localhost:9090

但如果 Grafana 跑在 Docker 里，localhost 指的是：

• 容器自己

这时往往应该写成：

1
http://prometheus:9090

也就是 Docker 网络中的服务名。

踩坑 2：Prometheus 自己就没抓到数据

Grafana 能连上 Prometheus，不等于一定能看到业务指标。

因为 Grafana 查到数据的前提是：

• Prometheus 已经成功 scrape 到目标

所以如果 up 都没有结果，先去 Prometheus 自己的页面确认：

• Status -> Targets

踩坑 3：查询没结果，不一定是连接问题

很常见的真实原因是：

• 指标名写错
• 当前时间范围太短
• 标签筛选条件不匹配
• 业务服务当前根本没流量

因此排查顺序最好是：

1. 先 Save & test
2. 再在 Explore 里查 up
3. 再查具体业务指标
4. 最后再做 dashboard 美化

踩坑 4：把“接入成功”和“监控做好了”混为一谈

接上 Prometheus 只说明：

• 查询链路通了

但真正能不能支撑值班和排障，还取决于：

• 指标设计是否合理
• panel 是否回答了关键问题
• dashboard 是否有变量和统一阈值
• 是否能从总览继续下钻

所以“接上”只是第一步，不是终点。

6. Panel 和 Visualization 怎么理解

Grafana 官方文档明确说明：

• panel 是 query + visualization

一个 panel 的本质

一个 panel 至少做了三件事：

1. 发查询
2. 可选地对结果做 transform
3. 选择可视化方式呈现

因此更合理的思考顺序通常是：

• 想回答什么问题
• 需要什么查询结果
• 什么图最适合表达这个结果

而不是：

• 先选一个好看的图，再反过来硬凑数据

图表类型不是越花越高级

Grafana 的可视化很多，但选择标准不是“炫”，而是“信息表达是否清楚”。

一个简单经验：

• 趋势变化：Time series
• 单值概览：Stat
• 占比或阈值：Gauge / Bar gauge
• 排名与 TopN：Bar chart / Table
• 明细与原始值：Table
• 分布：Heatmap

标准化配置很重要

Grafana panel 提供很多标准配置，例如：

• unit
• display name
• color
• thresholds
• field overrides

真正成熟的 dashboard，价值很大一部分不在 query 本身，而在：

• 单位统一
• 阈值明确
• 图例可读
• 展示一致

Field config 和 transformation 的边界

这两类能力经常一起出现，但作用不同：

• Field config / overrides 更偏展示规则，例如单位、别名、颜色、阈值、某字段单独覆盖
• Transformation 更偏结果整理，例如合并结果、排序、过滤、拼表

如果只是想让一个字段显示成 ms、把图例改名或给某一列单独设阈值，通常优先考虑 field config，而不是上来就堆 transformation。

7. Variable 是 Dashboard 复用能力的关键

Grafana 官方文档列出了多种 variable 类型，例如：

• Query
• Custom
• Text box
• Constant
• Data source
• Interval
• Ad hoc filters

Variable 解决什么问题

如果没有 variable，通常需要：

• 每个环境复制一份 dashboard
• 每个集群复制一份 dashboard
• 每个实例复制一份 dashboard

这样很快就会：

• 仪表盘爆炸
• 版本失控
• 修改成本高

有了 variable 后，一个 dashboard 就可以支持：

• 环境切换
• 集群切换
• 实例切换

最常用的几类 variable

Query variable

最常用。

它会从 data source 动态查出可选值。

例如在 Prometheus 类型的 variable editor 中，经常会写：

1
label_values(up, job)

这里有一个需要单独区分的边界：

• label_values(up, job) 是 Grafana 在变量查询场景中提供的查询写法
• 它不是普通 panel 里直接执行的 PromQL 表达式

这一点如果不区分清楚，就很容易出现“在变量里能用、在 panel 里却报错”的困惑。

Data source variable

适合：

• 在多个 Prometheus 或多个环境数据源之间切换

Interval variable

适合：

• 控制查询窗口和聚合粒度

多选变量与正则匹配

Prometheus 场景里还有一个非常常见的细节：

• 单选变量经常写成 job="$job"
• 多选变量和 All 选项往往要写成 job=~"$job"

原因在于：

• 多选变量展开后通常不是单个精确值，而是正则匹配表达式

如果这里写成 = 而不是 =~，就很容易出现：

• 单选时正常
• 一开多选就查不出结果

Variable 不是越多越好

过多 variable 会让 dashboard 变得：

• 操作复杂
• 初学者不敢用
• 查询链路过重

更稳妥的做法通常是：

• 只保留最核心的切换维度
• 让变量直接服务于排障路径，而不是为了“看起来灵活”堆满页面

8. Explore 是排障效率提升器

很多团队会做 dashboard，但没有真正把 Explore 用起来。

Explore 的定位

Grafana 官方文档提到：

• data source 可以被 Explore 使用

它更像：

• 实时试验查询的工作台

它和 Dashboard 的区别

Dashboard 偏：

• 固定视角
• 长期复用
• 团队共享

Explore 偏：

• 临时查询
• 快速下钻
• 排障过程中的动态探索

Explore 的几个高价值用法

• 异常刚发生时先临时验证 query，而不是立刻改正式 dashboard
• 对某个 panel 的 PromQL、LogQL、SQL 先做即席实验
• 使用 Query inspector 观察查询请求和返回结果，判断是 Grafana 展示问题还是后端查询问题
• 在 logs、metrics、traces 之间做关联观察，而不是在不同系统界面来回切换

因此，一个成熟团队的工作流往往是：

• 先在 Explore 中把问题查明白
• 再把稳定结论固化进 Dashboard 或 Alerting

9. Transformations 是 Grafana 的中层能力

很多人以为 Grafana 只是“后端怎么返回，它就怎么画”，其实不完全如此。

Grafana 官方文档在 panel 体系里明确提到：

• 可以 query and transform data

Transformation 的作用

它适合：

• 合并多个查询结果
• 排序
• 重命名字段
• 过滤字段
• 做表格拼装

顺序会影响结果

如果一个 panel 上配置了多个 transformation，它们不是并列生效，而是按顺序依次执行。

这会直接带来一个结果：

• 前一个 transformation 的输出，会成为后一个 transformation 的输入

例如：

• 先 Reduce 再 Join，和先 Join 再 Reduce，结果可能完全不同

因此 transformation 一多，最好把每一步都当成独立的数据加工节点来理解，而不是把它看成一堆随手勾选的显示选项。

它不应该替代后端逻辑

Transformation 很有用，但不应该把它用成：

• 复杂业务计算引擎

更稳妥的原则通常是：

• 业务语义和重计算尽量放在后端查询、recording rules 或上游数据处理层
• Grafana transformation 负责最后一层展示整理

否则 dashboard 很容易变成：

• 只有创建者自己看得懂

什么时候要切回 Table view

Grafana 官方文档也特别强调：

• transformed data 有时并不适合直接图形化

一旦出现下面这些情况，优先切回 Table view 看最终结果：

• transformation 链变长后，图表突然空白
• 查询本身有数据，但 visualization 看起来不对
• 多个 transformation 叠加后，不确定最终字段结构是什么

10. Grafana Alerting 怎么看

Grafana 官方文档说明：

• Grafana Alerting 可以基于多个数据源建立查询和表达式，并统一管理告警

它和 Prometheus Alerting 的关系

这点非常容易混淆。

Prometheus 的 alerting 是：

• Prometheus server 周期执行 PromQL

Grafana Alerting 是：

• Grafana 在统一告警框架里管理查询、表达式、通知和状态

一个告警规则通常包含什么

从工程实现看，一条可运行的告警规则通常至少包含：

• 查询
• 表达式或阈值判断
• 评估周期
• 告警状态管理
• Contact points 与 notification policies

这意味着“有一张图”与“有一条告警规则”并不是同一件事。

它的优势

• 多数据源
• 统一 UI
• 统一通知管理
• 更容易在同一平台里查看告警状态

但它不等于 Prometheus 规则系统

仍然要分清：

• 谁在存数据
• 谁在解释查询语义
• 谁在做周期评估
• 谁在发通知

Grafana 可以统一视图，但不意味着后端系统边界消失。

一个很常见的误解

经常会把下面两件事混为一谈：

• panel 上配置了 thresholds
• 系统里已经有了对应告警

实际上这两者是不同资源：

• panel threshold 主要解决“图怎么显示”
• alert rule 解决“什么时候触发事件和通知”

颜色变红，不等于告警已经建好。

工程上怎么选

比较实用的判断标准通常是：

• 如果团队已经高度依赖 Prometheus rule files 与 Alertmanager，Grafana Alerting 不一定要全盘替代
• 如果体系本身是多数据源，希望统一告警入口和通知管理，Grafana Alerting 的价值就很高

11. Provisioning 和 As Code 是 Grafana 走向成熟的关键

Grafana 官方文档明确指出：

• 可以通过文件 provisioning 定义 data sources 和 dashboards
• dashboard 本身也可以用 JSON model 表达

这使 GitOps 和版本化管理更自然。

为什么不能全靠 UI 手工点

小项目手工点没问题，但规模一上来就会出现：

• 环境间配置不一致
• 人工修改难审计
• dashboard 漂移
• 迁移困难

Provisioning 适合什么

• data source
• dashboard provider
• alerting 资源

一个最小目录结构

1
2
3
4
5
6
7
8
grafana/
├── provisioning/
│   ├── datasources/
│   │   └── prometheus.yaml
│   └── dashboards/
│       └── default.yaml
└── dashboards/
    └── service-overview.json

Data source provisioning 最小示例

1
2
3
4
5
6
7
8
apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

这段配置说明的事情非常直接：

• 用文件把 Prometheus 注册成默认 data source
• Grafana 启动时按配置自动加载

Dashboard provisioning 最小示例

1
2
3
4
5
6
7
8
9
10
11
apiVersion: 1

providers:
  - name: default
    orgId: 1
    folder: Services
    type: file
    disableDeletion: false
    updateIntervalSeconds: 30
    options:
      path: /var/lib/grafana/dashboards

这个 provider 的含义是：

• 指定某个目录下的 dashboard JSON 文件由 Grafana 周期扫描并加载

Dashboard JSON model 为什么重要

Grafana 官方文档说明：

• 一个 dashboard 本质上可以表示为一个 JSON 对象

其中会包含：

• uid
• title
• panels
• templating
• annotations
• time
• refresh

这件事的工程意义很大，因为它意味着：

• dashboard 可以进 Git
• 变更可以 code review
• 不同环境可以复用同一份结构
• uid 可以作为稳定标识，避免简单靠标题做人肉同步

它的真正价值

• 配置可版本控制
• 环境可复制
• 发布可自动化
• 平台治理更清晰

如果 Grafana 已经是团队正式平台，通常都应逐步走向：

• data source as code
• dashboard as code
• alerting as code

12. Dashboard 设计不是拼图，而是叙事

Grafana 的难点往往不在于“会不会点”，而在于：

• 能不能设计出真正回答问题的 dashboard

一个好 dashboard 回答的是一组连续问题

例如服务总览盘，通常应该从上到下回答：

1. 流量有没有变化
2. 错误有没有上升
3. 时延有没有劣化
4. 哪个实例或接口最异常
5. 资源层是不是打满

如果 dashboard 只是一堆无关图表堆在一起，通常说明：

• 它不是观察工具，而只是图表仓库

一个常见结构

服务总览类 dashboard 常见可以分成 4 层：

“图多”不等于“信息全”

图太多通常会导致：

• 扫描成本上升
• 重点不突出
• 值班时读图变慢

更好的做法通常是：

• 一页回答最核心问题
• 细节另开 drill-down dashboard

单位、颜色、阈值要统一

例如：

• 时间统一用 ms 或 s
• 容量统一用 bytes 或 MiB
• 绿色 / 黄色 / 红色的阈值保持一致

这些细节往往比“query 会不会写”更影响 dashboard 的可读性。

从 dashboard 到下钻链路

一张成熟的 dashboard，最好不是终点，而是排障入口。

因此常见的设计思路是：

• 总览盘负责快速发现异常
• 面向实例、接口、队列、数据库的 drill-down dashboard 负责进一步定位
• Explore 负责承接临时查询与动态验证

这样整个观察链路才是连贯的。

13. Grafana 和 Prometheus 最容易混淆的地方

查询写在 Grafana，不代表计算属于 Grafana

比如在 panel 里写：

rate(http_requests_total[5m])

看起来像是 Grafana 在“执行”这个表达式，但真正解释和计算它的其实是：

• Prometheus

Grafana 更像：

• 查询发起者和结果展示者

看到图在 Grafana，不代表数据在 Grafana

数据通常在：

• Prometheus
• Loki
• SQL
• 其他 data source

Grafana 不等于数据仓库。

Grafana 可以建告警，不代表 Prometheus 规则就没意义了

两者是不同层面的能力。

选哪种，要看：

• 后端数据源类型
• 团队使用习惯
• 平台治理模式

在变量里能用，不代表在 panel 里也能用

例如：

1
label_values(up, job)

它在 Grafana 的变量查询场景中很常见，但它并不是普通 panel 中直接执行的 PromQL。

这类“看起来像查询语句”的辅助写法，尤其容易把 Grafana UI 语法和后端查询语言混在一起。

14. 常见误区

把 Grafana 当数据库

这是最根本的误解。

只会导入社区 dashboard

社区 dashboard 可以拿来参考，但不能替代：

• 自己的业务语义设计

否则常见结果是：

• 图很多
• 关键问题一个也回答不好

每个环境复制一套 dashboard

这通常说明：

• variable 还没有用好

把 transformation 用成业务计算引擎

后期可维护性会很差。

panel 样式五花八门、单位不统一

这会导致：

• 图表看起来很丰富
• 实际读起来很累

只会做 dashboard，不会用 Explore

排障效率会明显受限。

完全手工管理 data source 和 dashboard

一旦环境增多、团队变大，就会暴露出：

• 配置漂移
• 不可审计
• 难复制

把变量查询辅助语法当成 PromQL

这会导致：

• variable 里能跑
• panel 里报错
• 对查询边界的理解越来越混乱

把 panel 阈值颜色当成告警条件

这会导致：

• 图上看起来“已经红了”
• 实际上没有任何 rule 在评估，也没有通知链路

15. 一个更工程化的 Grafana 使用方式

更稳妥的心智模型如下：

把 Grafana 当成观测界面层

它负责：

• 查询入口
• 图表承载
• 团队共享
• 现场排障

把后端系统当成语义来源

• Metrics 语义来自 Prometheus / Micrometer
• 日志语义来自 Loki / Elasticsearch
• Trace 语义来自 Tempo / Jaeger

Grafana 不替代它们，而是把它们组织起来。

把 Dashboard 当产品，而不是临时截图

好的 dashboard 应该：

• 可复用
• 可维护
• 可版本化
• 能支撑真实值班和排障

把 Folder、权限和版本控制一起设计

到了团队使用阶段，Grafana 的问题就不再只是“图能不能画出来”，还包括：

• dashboard 放在哪个 folder
• 谁能看、谁能改、谁能管 data source
• 变更是走 UI 直接修改，还是走 JSON / provisioning / Git

这些治理层问题处理得越早，后期维护成本越低。

16. 这篇笔记最该带走的结论

1. Grafana 的核心定位是查询、可视化、探索和协作，不是存储后端。
2. Data source 是 Grafana 的基础对象，它决定查询能力来源。
3. Panel 的本质是 query + visualization，不只是“一个图”。
4. Variables 决定 dashboard 能否复用、参数化和规模化。
5. Explore 是排障工具，不应只把 Grafana 用成固定 dashboard 平台。
6. Transformation 适合做展示整理，不适合承载重业务逻辑。
7. panel threshold 与 alert rule 是两类不同资源，不能混为一谈。
8. 真正成熟的 Grafana 使用方式，通常会走向 dashboard JSON、provisioning 与 as-code。
9. 好 dashboard 的核心是回答问题和讲清状态，不是堆很多图。
10. Grafana 和 Prometheus 是协作关系，不是替代关系。

17. 相关阅读

和本文衔接最自然的一篇是：

• Metrics、Prometheus、Grafana 三者关系笔记

因为到这一步，最值得继续彻底讲清楚的就是：

• Metrics 是什么抽象
• Prometheus 是哪个层
• Grafana 又是哪个层
• 为什么三者经常一起出现，但绝不能混成一个概念

• Previous
  Prometheus 监控系统
• Next
  Metrics、Prometheus、Grafana 三者关系