数据源管理

Grafana 自己不生产也不存储数据，面板上每一根曲线都是从数据源（Data Source）实时查出来的。架构层面的定位上一篇核心概念与架构已经讲过，这篇落到实操：数据源有哪些类型、常用的几种怎么配、多用户场景下组织/团队/角色怎么划分，以及怎么用 provisioning 把数据源配置固化成代码。示例环境：Grafana 10/11/12 均适用，界面入口以 11 为准。

数据源类型总览

Grafana 的数据源按「查什么」分几大类，日常打交道的都在这张表里：

类别	代表数据源	典型用途
时序库	Prometheus / VictoriaMetrics / Mimir	指标曲线、告警，运维监控的主力
日志	Loki / Elasticsearch / OpenSearch	日志检索、错误日志量趋势
关系库	MySQL / PostgreSQL	直接查业务表出运营报表
云厂商	CloudWatch / Azure Monitor / Google Cloud Monitoring	云上资源的指标与日志
Tracing	Tempo / Jaeger / Zipkin	调用链查询，常与日志、指标互相跳转

数据源就是插件

上表这些是开箱自带的核心插件（core plugins），更多在 Grafana 官方插件目录里一键安装，装完重启生效。企业版插件（Oracle、ServiceNow 这类）需要 Enterprise/Cloud 授权，自建开源版一般用不到。

配置 Prometheus 数据源

入口：左侧菜单 Connections → Data sources → Add data source，搜索选 Prometheus（老版本在齿轮 Configuration → Data sources，位置略有差异）。

真正要填的就几项：

URL：Prometheus 的 HTTP 地址，比如 http://prometheus:9090。注意这是 Grafana 服务器视角的地址——浏览器只跟 Grafana 打交道，查数据是 Grafana 后端替你去连 Prometheus。容器部署的地址写法见「常见坑」。
HTTP Method：GET / POST，新版本默认 POST。PromQL 很长、target 很多的场景保持 POST，GET 容易撞 URL 长度上限。
Query timeout：单次查询超时，默认 60s 一般不动；查询频繁超时才调大，同时该反思 PromQL 是不是写重了。
Scrape interval：填 Prometheus 实际的抓取间隔（15s）。Grafana 拿它计算 $__interval 自动步长，填错会让曲线出现锯齿或空点。

填完点底部 Save & Test，绿色提示 Successfully queried the Prometheus API 就算通了。它验证的是 Grafana → Prometheus 这一跳，跟你本机浏览器没有任何关系。

同一套 Prometheus 可以接多次

数据源条目按名字区分，同一个 URL 配几条互不冲突。真实场景：接 Mimir/Cortex 时同地址配不同 X-Scope-OrgID 请求头实现租户切换；或者把最常用的那条打开 Default 开关，新建面板时默认选中它，其余条目保持非默认。

配置 Loki 与 MySQL

Loki：同样 Add data source 选 Loki，核心配置就一项 URL——http://loki:3100，保存测试通过后即可在 Explore 里用 LogQL 查日志。进阶项里值得知道的是 derived fields：从日志行里正则提取 traceID，在日志详情旁生成一个跳转 Tempo 的按钮，排障时日志 → 调用链一键穿过去。具体配置放到日志专题再展开。

MySQL：填 Host（如 10.0.2.11:3306）、Database、账号密码即可。关键是账号别图省事用 root，单独建一个只读账号：

# 在 MySQL 里建 Grafana 专用只读账号，只允许 SELECT
mysql -uroot -p <<'EOF'
CREATE USER 'grafana_ro'@'%' IDENTIFIED BY 'change-me-strong-password';
GRANT SELECT ON appdb.* TO 'grafana_ro'@'%';
FLUSH PRIVILEGES;
EOF

别把生产库当 BI 用

Grafana 查 MySQL 是直连生产库发 SQL，一条没加时间过滤的全表扫描就能把库拖垮。两条纪律：账号只授 SELECT；面板 SQL 永远带时间范围条件，用 $__timeFilter(create_time) 这类宏让查询自动跟随右上角时间范围。报表需求重的场景，老老实实抽数到数仓再查。

组织、团队与角色

Grafana 的多用户体系分三层：

Organization（Org）：最高隔离单位。不同 Org 之间数据源、仪表盘、用户完全隔离，右上角头像旁可以切换。一套 Grafana 服务多个互不相关的团队（或 SaaS 多租户）才需要多 Org；绝大多数公司用默认的 Main Org. 一个就够。
Team（团队）：Org 内的用户分组，本身不隔离数据，用途是批量授权——给文件夹、仪表盘分配权限时按 Team 给，人员进出只调 Team 成员，不用挨个改权限。
Role（角色）：每个用户在 Org 内有一个角色，决定能力上限。

三种内置角色的差异：

能力	Viewer	Editor	Admin
查看仪表盘、用 Explore	✓	✓	✓
创建和修改仪表盘	✗	✓	✓
创建告警规则	✗	✓	✓
管理数据源	✗	✗	✓
管理用户、团队、插件	✗	✗	✓

Editor 不能管数据源了

Grafana 9 之前 Editor 也能增删数据源，9 起收紧到 Admin 专属。确实需要「能配数据源但不是全管理员」这类细粒度授权，得上 Enterprise/Cloud 的 RBAC；开源版的常见做法是 Admin 只给少数几个人，其余一律 Editor。

Provisioning 声明式管理

界面上点出来的数据源配置存在 Grafana 的内置数据库里，换一台机器、换一个环境就得重新点一遍，还没法评审和回滚。正经做法是配置即代码：把数据源写成 YAML 文件交给 provisioning 自动加载，跟着 Git 走。

配置文件放在 provisioning 目录下（包安装默认 /etc/grafana/provisioning/datasources/，官方容器镜像同路径），文件名随意、放几个文件都行：

# provisioning/datasources/prometheus.yaml
apiVersion: 1

# 先按名字删掉同名旧配置，保证文件是唯一事实来源
deleteDatasources:
  - name: Prometheus
    orgId: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy            # 查询由 Grafana 后端转发；浏览器直连模式已在 10 移除
    url: http://prometheus:9090
    isDefault: true
    jsonData:
      httpMethod: POST
      timeInterval: 15s

带密码的数据源用 secureJsonData，写入后界面不再回显明文：

datasources:
  - name: appdb
    type: mysql
    url: 10.0.2.11:3306
    user: grafana_ro
    database: appdb
    secureJsonData:
      password: 'change-me-strong-password'

容器部署把目录挂进去即可：

docker run -d \
  --name grafana \
  -p 3000:3000 \
  -v ~/grafana/provisioning:/etc/grafana/provisioning \
  grafana/grafana:11.2.0

几个要点：

生效方式：数据源的 provisioning 改完要重启 Grafana 进程才生效，没有热加载（仪表盘 provisioning 才有定时扫描，别搞混）。
与界面配置的关系：provision 出来的数据源在界面上带 Provisioned 标记、不可编辑，要改就改 YAML 再重启——这正是目的，杜绝「界面上随手改、重启后配置漂移」的破窗。
deleteDatasources 段按名字先删后建，文件里移除某个条目后重启也会同步删掉它；不需要可整段去掉。

与环境变量配合

URL、密码这类因环境而异的值，可以在 YAML 里写 $PROMETHEUS_URL 或 ${PROMETHEUS_URL} 形式，Grafana 启动时从环境变量展开。同一套配置文件，开发、测试、生产各挂各的 env，不用改文件本身。

常见坑

容器里 URL 写 localhost 连不上：Grafana 容器里的 localhost 指容器自己。同一 docker network 里写容器名（如 http://prometheus:9090）；要连宿主机上的服务，macOS/Windows 用 host.docker.internal，Linux 启动时加 --add-host=host.docker.internal:host-gateway。Prometheus 侧的同款坑见部署与快速上手。
切了 Org 数据源「消失」：数据源按 Org 隔离，右上角切到别的 Org，列表自然是空的，不是被删了。多 Org 部署时每个 Org 各配各的，互不可见。
Save & Test 成功但面板没数据：连通性 OK 只说明网络通，不代表有你要的数据。按顺序查：右上角时间范围对不对 → 查询里 job/instance 标签值跟实际抓取是否一致（写法见 [PromQL 查询语言](/docs/observability/prometheus/PromQL 查询语言)）→ 去 Explore 用同一个数据源跑同一条查询复现，绕开面板设置干扰。
Viewer 找不到数据源菜单：正常，数据源配置只对 Admin 可见，Viewer 和 Editor 的菜单里压根没有 Connections 入口，不是浏览器缓存问题。

小结

数据源就是「Grafana 去哪查数据」：指标找 Prometheus 系，日志找 Loki/ES，报表找关系库，调用链找 Tempo/Jaeger。
Prometheus 数据源核心就 URL 一项；Save & Test 验证的是 Grafana 到 Prometheus 这一跳；同一地址可按不同名字接多次。
MySQL 务必只读账号加时间过滤，别把生产库拖垮。
多用户记三层：Org 隔离、Team 分组授权、角色定上限；Editor 从 Grafana 9 起不能管数据源。
生产环境数据源一律 provisioning 成 YAML：重启生效、界面只读、跟着 Git 走。

数据源通了，下一步就是用这些数据画图——见下一篇「仪表盘制作」。

数据源类型总览​

配置 Prometheus 数据源​

配置 Loki 与 MySQL​

组织、团队与角色​

Provisioning 声明式管理​

常见坑​

小结​

数据源类型总览

配置 Prometheus 数据源

配置 Loki 与 MySQL

组织、团队与角色

Provisioning 声明式管理

常见坑

小结