Grafana 核心概念与架构
Grafana 是什么
一句话定位：Grafana 是开源的可视化与可观测性展示平台，它本身不存储任何监控数据。它做的事情只有两件——连上你的数据源（Data Source），按查询条件把数据取回来，渲染成图表给你看。
「只负责查和看」的架构带来几个直接推论：
- 数据永远留在原地：指标在 Prometheus 里，日志在 Loki 里，业务数据在 MySQL 里。Grafana 只是查询的发起方和结果的渲染方，删掉 Grafana，监控数据一条不少。
- 多数据源能拼在一张图上：左边是 Prometheus 的 QPS 曲线，右边是 Loki 的错误日志流，上面是 MySQL 的实时订单量——一次故障排查不用在三个系统之间来回切。
- Grafana 自身状态很小：用户、数据源配置、仪表盘定义这些「Grafana 自己的数据」默认只存在一个 SQLite 文件里，备份迁移都很轻。
一次查询的完整链路：
浏览器打开 Dashboard
→ Grafana 服务端按 Panel 的查询配置请求各数据源（Prometheus / Loki / MySQL ...）
→ 数据源返回结果集
→ Grafana 渲染成图表，浏览器拿到最终的图
注意方向：查数据的是 Grafana 服务端，不是浏览器直连数据源。所以数据源配置里的 URL 要以 Grafana 进程的网络位置为准——你的浏览器能通不算数。这个坑在下一篇接第一个数据源时会马上遇到。
所以不要把 Grafana 当成「监控系统」：它是监控体系里的显示器。谁采数据、谁存数据、谁算告警，都是数据源那一侧的事。这也是它 2013 年从 Kibana 3 fork 出来之后一路壮大的原因——专注做展示层，反而成了几乎所有监控后端的事实标准前端。
Tableau、Superset 这类 BI 工具面向「业务数据分析」，查询以 SQL 为主、交互以拖拽报表为主；Grafana 面向「运维与可观测性」，查询以 PromQL、LogQL 为主、交互以时间轴缩放和实时刷新为主。拿 Grafana 做经营报表能做但很别扭，反之亦然。
与 Prometheus 的关系
这对组合几乎是云原生监控的代名词，分工非常清晰：
| 角色 | 负责什么 | 不负责什么 |
|---|---|---|
| Prometheus | 采集指标、存储时序、评估告警规则 | 画好看的图、多数据源拼图、权限与分享 |
| Grafana | 查询展示、仪表盘、交互式分析 | 采集与存储（它有自己的告警引擎，定位见下文「适用边界」） |
Prometheus 自带的 Web UI 只适合临时查询和调试，这一点在 Prometheus 核心概念与架构 里也明确说了，正经的看板从一开始就约定俗成交给 Grafana。为什么它俩总是成对出现：
- PromQL 一等公民：Grafana 的 Prometheus 数据源对 PromQL 支持最完整——语法高亮、自动补全、指标浏览器、即时与区间查询切换，写错函数名当场提示。
- 生态双向绑定：kube-prometheus-stack 这类全家桶默认把 Grafana 打包进去；grafana.com 上社区贡献的现成仪表盘，大半都是基于 Prometheus 指标画的。
- 各干各的强项：存储压缩、告警评估这些重活 Prometheus 干，交互体验、多源关联这些细活 Grafana 干，互不抢饭碗。
Prometheus 是「数据的仓库和发动机」，Grafana 是「驾驶舱的仪表盘」。同一台发动机可以配多个驾驶舱（多套 Grafana 共用数据源），一个驾驶舱也可以接多台发动机（一条 Dashboard 查多个 Prometheus）。
数据源模型
Grafana 的能力边界由「接了哪些数据源」决定。每条数据源是一份「类型 + 地址 + 认证 + 查询语言」的配置，生态里能接的后端大致分几类：
| 类别 | 代表数据源 | 典型用途 |
|---|---|---|
| 时序指标 | Prometheus、VictoriaMetrics、Mimir、InfluxDB、Graphite | 监控指标、SLO 曲线 |
| 日志 | Loki、Elasticsearch、OpenSearch、ClickHouse | 日志检索、错误分析 |
| 链路追踪 | Tempo、Jaeger、Zipkin | 调用链分析 |
| 关系数据库 | MySQL、PostgreSQL、SQL Server | 业务数据、工单报表 |
| 云厂商监控 | CloudWatch、Azure Monitor、Google Cloud Monitoring | 云上资源的托管指标 |
| 其他 | Infinity（任意 HTTP API）、TestData（造测试数据） | 接没有专用插件的系统 |
几个使用要点：
- VictoriaMetrics、Mimir 直接用 Prometheus 类型数据源连：它们兼容 PromQL 查询接口，Grafana 端无感知。这也说明「数据源类型」本质是查询协议，不是后端品牌。
- 同一类后端可以配多条数据源：生产 Prometheus、测试 Prometheus 各配一条，面板查询时下拉切换，也可以在一张 Dashboard 上混用。Panel 的查询编辑器里还有个 Mixed（混合）模式，一次查询同时拉多条不同数据源的结果叠着画。
- 核心数据源内置：Prometheus、Loki、MySQL 这些官方维护的数据源开箱即用；更多第三方后端以插件形式安装，插件市场在 grafana.com/grafana/plugins。
第三方数据源和面板插件维护质量参差不齐，装之前看一眼最近更新时间和下载量。Grafana 11 起彻底移除了基于 Angular 的老插件体系，升级大版本前先盘点在用插件是否已迁移到新体系，否则面板会直接打不开。
插件体系的三种形态
- Datasource 插件：接一类新后端，定义「怎么连、用什么查询语言」。
- Panel 插件：一种新的可视化类型，比如流程图、增强饼图、地图面板。
- App 插件：把前两者加定制页面打包成一个「应用」，装上就是一套完整体验，比如 Kubernetes Monitoring 这类全家桶插件。
未签名的插件默认拒绝加载，自建插件要在配置里显式放行——这个开关等于关掉一道安全门，生产环境慎用。
核心概念
Grafana 的概念不多，记住这四组名词就够日常使用。
权限与组织：
- Organization（组织）：多租户隔离单位，数据源、仪表盘、用户都归属某个 Org，Org 之间互不可见。单机自用通常只有一个 Main Org——别为了「隔离」一上来建一堆 Org，多数场景用 Team 和文件夹就够。
- Team（团队）：Org 内把用户分组，权限按 Team 授予，新人进组即获得该组的看板权限。
- User（用户）：登录账号，内置三种角色——Admin（管实例）、Editor（建改看板）、Viewer（只能看）。更细粒度的 RBAC 是 Enterprise 的能力。
看板结构：
- Dashboard（仪表盘）：一张看板，由若干 Panel 组成，支持用变量（Variables）做全局下拉筛选。看板按**文件夹（Folder）**归类存放，权限通常挂在文件夹上而不是单张看板上。
- Row（行）：Dashboard 里的可折叠分组条，把 Panel 按主题归类；Grafana 12 起还提供了 Tab 等新布局。
- Panel（面板）：最小展示单元——一条时序曲线、一个大数字（Stat）、一张表格、一段日志流，背后绑定一个或多个查询。
连接与扩展：
- Data Source（数据源）：上一节的主角，一份「怎么连、怎么查」的配置。
- Plugin（插件）：datasource、panel、app 三种形态，见上节。
版本怎么选
| 版本 | 性质 | 适合谁 |
|---|---|---|
| OSS | 开源版（AGPLv3 协议），核心功能完整 | 绝大多数团队，本系列以 OSS 为准 |
| Enterprise | 商业订阅，在 OSS 基础上加 SAML、报表导出、细粒度权限、数据源缓存等 | 有合规审计、大团队权限治理需求的企业 |
| Cloud | Grafana Labs 官方托管的 SaaS，免运维，有免费额度档 | 不想自己维护、规模小或想快速验证的团队 |
两个容易混淆的点：
- Docker 官方主镜像 grafana/grafana 其实是 Enterprise 发行版：不激活 license 时行为等同 OSS，功能不会少。想用纯粹的开源发行版，选 grafana/grafana-oss 镜像。
- 版本口径：当前（2026）主流是 Grafana 11.x 与 12.x，12 是 2025 年发布的大版本，带来了新版动态仪表盘和一套免写查询语言的 Drilldown 下钻分析应用。本系列内容两个大版本通用。
适用边界
明确 Grafana 不是什么，以及它的主战场在哪。
它不是告警核心。 Grafana 8 起内置了 Unified Alerting，9 起成为唯一告警体系，能跨数据源定义告警规则——在「一份数据在 Loki、一份在 Prometheus」的场景里这是独一份的能力。但多数生产仍把 Prometheus 加 Alertmanager 作为告警中枢：链路短、与存储同生共死、生态成熟。Grafana 告警更适合当补充，比如基于 Loki 日志内容的告警。告警体系第 6 篇专门展开。
它不是存储。 前面反复强调过：Grafana 挂了、删了，监控数据毫发无损；反过来，数据保留多久、磁盘够不够，Grafana 一概不管，那是各数据源自己的容量规划。
两个主战场：
- 大屏展示：NOC 值班大屏、机房电视墙。Kiosk 模式（TV 模式）隐藏导航只留图表，Playlist 功能让多张看板定时轮播。
- 排查分析：值班排障时的时间轴缩放、变量联动过滤、Explore 临时查询、面板间下钻跳转，配合前面说的多数据源拼图，是「从症状定位到根因」的主工作台。
Grafana 是可观测性体系的「眼睛」：负责让你看见，不负责替你记住，也不负责替你喊。记忆是 Prometheus、Loki 的事，喊话是 Alertmanager 的事。
小结
- Grafana 是纯可视化层：本身不存数据，连接各类数据源做查询和展示，自身状态只有一个 SQLite 文件。
- 与 Prometheus 是黄金搭档：一个存数算告警，一个画图做分析，生态双向绑定，所以总是成对出现。
- 数据源模型按「时序、日志、追踪、关系库、云厂商」分类，VictoriaMetrics 等兼容后端直接走 Prometheus 类型；能力扩展靠 datasource、panel、app 三类插件。
- 核心概念四组：Organization、Team、User 管权限，Dashboard、Row、Panel 管看板，Data Source 管连接，Plugin 管扩展。
- 版本三选一：OSS 免费够用（本系列基准）、Enterprise 加企业功能、Cloud 免运维托管；注意 Docker 官方主镜像是 Enterprise 发行版。
- 边界清晰：不是告警核心（第 6 篇细说）、不是存储；主战场是大屏展示和排查分析。
概念就绪，下一篇《安装与快速上手》把 Grafana 跑起来：Docker 一条命令起步，接上 Prometheus 数据源，导入第一块现成仪表盘。