Grafana 是开源的可观测性与可视化平台,核心定位是「把分散在各处的监控数据统一画到一块面板上」:它通过数据源插件接入 Prometheus、Loki、Elasticsearch、MySQL、ClickHouse、云厂商 API 等几十种数据源,提供统一的查询、可视化、仪表盘与告警能力。它的典型用户是 SRE/DevOps 工程师:服务器指标、日志、链路追踪、数据库状态、AI 训练集群的 GPU 利用率,都可以收敛到同一个 Web 入口,并在指标越界时通过统一的告警规则通知到人。与深度绑定 Elastic 生态的 Kibana、商业闭环的 Datadog 不同,Grafana 对数据源保持中立,本身不存储时序数据,部署自由度高,核心版本开源免费,是企业自建监控体系的事实标准之一。 本篇按「为什么需要 → 安装配置 → 快速上手 → 核心能力 → 生产部署 → 选型对比 → 误区 → 面试题 → 资源」的顺序组织,读者按章节走一遍即可在半小时内搭建出第一个可用的大盘。

岗位关联

对 AI 从业者而言,Grafana 是 AI 基础设施(训练集群、LLM 服务、RAG 管道)可观测性的通用入口,掌握它等于掌握了「指标 → 面板 → 告警」全链路交付能力,是 MLOps/Infra 岗位的标配技能。

目录
  1. 为什么需要 Grafana:从数据孤岛到统一观测
  2. 安装与环境配置:3 步就绪
  3. 快速上手:5 分钟跑通第一个大盘
  4. 核心能力详解:4 大支柱
  5. 生产部署与监控:从上线到运维
  6. 版本迭代
  7. AI 应用场景
  8. 常见误区
  9. 面试题
工具类型
可观测性与可视化平台(开源)
开发商
Grafana Labs(瑞典)
开源协议
AGPLv3(核心可商用)
GitHub Stars
无
主要语言
Go / TypeScript
当前版本
11.2(2025-07 最新正式版)
安装方式
apt / Docker / Helm / 二进制
官方文档
上手难度
★★☆☆☆(简单)
适合人群
SRE/DevOps · AI Infra 工程师 · 数据分析师
同类工具
Kibana · Datadog · Zabbix
托管服务
无

速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。

为什么需要 Grafana:从数据孤岛到统一观测

传统监控是割裂的:服务器指标看 Zabbix、日志查 ELK、云资源去云厂商控制台、链路追踪看 Jaeger,每个系统查询语法不同、界面不同,排障要在多个系统间来回切换,无法在一张图上对比指标与日志的因果关系。对同时负责多个服务的团队,这种割裂会直接拉长故障平均恢复时间(MTTR,即从故障发生到恢复的平均时长)。

Grafana 的解法是用统一的数据源抽象层把这些系统接入同一入口:官方与社区提供了 70+ 数据源插件,查询结果统一渲染成时间序列、柱状图、表格等面板;8.0 起内置统一告警(Unified Alerting),可以跨数据源定义规则,一处配置邮件、Slack、飞书、Webhook 等通知渠道。数据源不需要搬迁,Grafana 只负责读。

与同类工具的气质差异在于:Kibana 深度绑定 Elasticsearch,数据源单一;Datadog 是商业 SaaS 且按用量计费;Grafana 对数据源完全中立,后端只用 SQLite/PostgreSQL 存元数据,不碰业务时序数据。它聚焦「画图 + 告警」这件事本身,因此成为多数据源场景下的通用层。

安装与环境配置:3 步就绪

步骤一:安装。最快的方式是 Docker,一条命令启动;在 Debian/Ubuntu 上也可通过官方 apt 仓库安装为系统服务。

步骤二:配置。默认配置即可启动,生产环境建议通过环境变量或 grafana.ini 修改管理员初始密码(容器内对应 GF_SECURITY_ADMIN_PASSWORD)、监听地址与数据目录。

步骤三:验证。访问 /api/health 接口,返回 database: "ok" 即说明服务正常起效,随后即可用浏览器打开 Web 界面。

bash15 行
# 方式一:Docker(推荐,11.2.0 为当前最新正式版)docker run -d --name=grafana -p 3000:3000 \  -e GF_SECURITY_ADMIN_PASSWORD=admin123 \  grafana/grafana:11.2.0sleep 5curl http://localhost:3000/api/health# 期望输出:{"commit":"...","database":"ok","version":"11.2.0"} # 方式二:Debian/Ubuntu(apt 官方仓库)sudo apt-get install -y gnupg2 software-properties-commonsudo mkdir -p /etc/apt/keyrings/wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/nullecho "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.listsudo apt-get update && sudo apt-get install -y grafanasudo systemctl enable --now grafana-server

快速上手:5 分钟跑通第一个大盘

最小可用流程是「一个 Grafana + 一个能出数据的数据源」,不用自带采集,官方沙箱 play.grafana.org 可以直接体验。如果本机没有 Prometheus 目标可采,先用沙箱验证流程,再回来接真实数据源。

1. 按上节启动 Grafana,浏览器访问 http://localhost:3000,用 admin 与设置的密码登录(10.x 起首次登录会提示修改密码)。

2. 进入「连接 → 数据源 → 添加数据源」,类型选 Prometheus,URL 填 http://localhost:9090(指向已有的 Prometheus 服务),点击「保存并测试」。

3. 若暂时没有 Prometheus,跳过本步,打开 https://play.grafana.org 完成同样的添加数据源流程。

4. 在「仪表盘 → 新建 → 导入」中粘贴官方仪表盘 ID 1860(node_exporter 全览),加载后选择你的 Prometheus 数据源,点导入。

5. 打开大盘后,用右上角时间选择器切到「最近 15 分钟」并开启自动刷新,确认曲线上出现数据;再到「探索」页输入 PromQL 验证查询能力:rate(node_cpu_seconds_total[5m])。

出现指标曲线即说明链路通了。进阶技巧:把时间范围与主机标签做成仪表盘变量(如 instance),一个大盘即可在多个节点间动态切换;随后为该查询配置一条告警规则,就等于从「看图」升级到「被通知」。

核心能力详解:4 大支柱

支柱一:统一数据源与查询。Grafana 不存储业务时序数据,而是通过数据源插件对接外部系统,插件协议统一了连接、查询与返回格式。用户面对的是「选择数据源 → 写该数据源的原生查询」:Prometheus 写 PromQL、Loki 写 LogQL、数据库写 SQL。查询编辑器还支持变量、函数与区间宏(如 $__interval),让面板可以自适应时间范围与刷新频率。

支柱二:可视化与仪表盘。内置三十余种面板:时间序列、状态历史、仪表盘(gauge)、柱状图、热力图、日志、表格等。仪表盘支持模板变量、图层联动、注释(annotation,在曲线上标记发版/告警事件)与数据链接。权限体系分组织、团队、文件夹三级,可精确控制谁能看、谁能改、谁能导出。

支柱三:统一告警。8.0 起告警引擎内置化,支持 PromQL、SQL、log 查询等多数据源规则;一条规则会评估出多个告警实例(如「每台主机的 CPU 都独立评估」)。通知链路为:告警规则 → 通知策略(notification policy)→ 联系点(contact point),联系点可对接邮件、Slack、Webhook、飞书等渠道,并支持静默(silence)与抑制,避免故障风暴刷屏。

支柱四:配置即代码。所有资源都可通过 Provisioning(配置文件声明)或 HTTP API 管理:数据源、仪表盘、告警规则、联系点、通知策略均可写成 YAML 随代码仓库版本化,配合 Terraform Provider 做基础设施即代码(IaC)。插件管理用 grafana-cli,如 grafana-cli plugins install grafana-piechart-panel。

生产部署与监控:从上线到运维

方式一:Docker Compose 最小生产栈。Prometheus 负责采集与存储,node-exporter 暴露主机指标,Grafana 负责展示。三个容器挂载命名卷即可,适合中小团队快速落地。

方式二:Kubernetes Helm 部署。使用官方 Chart,支持 Ingress、持久卷、副本数配置,并能通过 sidecar 自动加载 ConfigMap 中的 Provisioning 文件——这是生产环境推荐路径:

方式三:高可用(HA)配置。生产环境至少 2 个副本,并满足三个条件:外部共享数据库(PostgreSQL/MySQL,不能用默认 SQLite)、共享存储(仪表盘、快照、插件写入 S3/EFS 一类存储)、多副本间开启 HA 告警协调(Alerting 在副本间自动做主备,通过 gossip 协议同步状态)。前面加负载均衡,告警通知不会重复发送。

可观测性方面,Grafana 自身暴露 /metrics(Prometheus 格式),可被 Prometheus 抓取后回画自己的面板;启用以结构化日志输出,并叠加 OpenTelemetry 支持将内部请求链路送给 Tempo。重点观察 http_request_duration_seconds 等延迟指标与 grafana_alerting_* 告警评估系列指标,防止「监控系统本身挂了」。

<p class="para-label">避坑清单:</p>

<ul class="dash-list"><li>默认账号密码或匿名访问未处理:首次登录后立即修改 admin 密码,生产环境接入企业 SSO(LDAP/OAuth2),并在「安全 → 匿名访问」中确认匿名浏览处于关闭状态。</li><li>SQLite 直接上生产:默认 SQLite 只适合单机体验,多副本或并发写面板时会锁库报 500;生产必须切换到 PostgreSQL/MySQL 作为元数据库。</li><li>升级前不备份:主版本升级会迁移元数据库,先备份 grafana.db 与配置文件,并用 grafana-cli 核对已安装插件是否兼容新版本。</li><li>告警通知渠道单一:只配一个邮箱或 Webhook,渠道故障时告警直接丢失;应为同一联系点配置多种通知方式,并用通知策略区分级别、做升级与收口。</li></ul>

bash12 行
# docker-compose.yml:Prometheus + node-exporter + Grafana 最小栈services:  prometheus:    image: prom/prometheus    ports: ["9090:9090"]  node-exporter:    image: prom/node-exporter  grafana:    image: grafana/grafana:11.2.0    ports: ["3000:3000"]    volumes:      - ./grafana-data:/var/lib/grafana
bash2 行
helm repo add grafana https://grafana.github.io/helm-chartshelm upgrade --install grafana grafana/grafana --namespace monitoring --create-namespace
维度GrafanaKibanaDatadogZabbix
定位数据源中立的观测可视化平台Elastic 生态专用可视化SaaS 全栈可观测商业平台自带采集与存储的一体化监控系统
数据接入70+ 数据源插件,指标/日志/链路通吃仅支持 Elasticsearch 后端内置 Agent,闭源生态自家 Agent 采集,模板化接入
查询语言各数据源原生查询(PromQL/LogQL/SQL)KQL 与 Lucene专有查询语法类 SQL 触发器表达式
告警能力内置统一告警,跨数据源混合评估依赖 Elastic 告警,配置较重告警丰富,自带智能降噪触发器成熟,通知渠道多
部署方式自托管/容器/Helm/云托管均可通常随 Elastic Stack 一起部署仅 SaaS,按主机与用量计费自托管为主
LicenseAGPLv3 核心开源可商用Elastic License(部分功能需商用订阅)商业闭源AGPLv3(6.0 起)
学习曲线低:导入面板即用中:需先理解 ES 索引模型低:开箱即用但成本高中高:模板与触发器 DSL 有门槛
适合谁SRE/DevOps、AI Infra、多数据源统一视图团队Elastic 技术栈重度用户预算充足、不想自建监控的团队偏好一体化自托管、强告警场景的管理员

选型建议:已有 Prometheus/Elasticsearch 等多套存储、想要统一展示入口的团队,Grafana 是默认选择;如果全家桶都是 Elastic 生态,Kibana 集成更省事;预算允许且不想维护监控设施,Datadog 开箱即用;需要单一软件覆盖采集到告警的全流程、且团队熟悉类 SQL 表达式,选 Zabbix 更直接。

版本迭代

Grafana 以约 6 周为周期快速迭代,从 2022 年的 9.x 演进到 2025 年的 11.x;官方明确了两条主线:仪表盘架构向面板化(Scenes)重构、告警引擎向统一告警收敛,同时 9.5 与 10.4 被标记为长期支持(LTS)版本,生产用户可长期固定在 LTS 上。

版本时间变化提升
9.52023-039.x 收官版,首个 LTS日志面板、权限与注释增强,生产环境稳定基线
10.02023-06Scenes 面板框架、子查询面板渲染管线重构,为面板化仪表盘打基础
10.42024-03可访问性与可观测性增强第二个 LTS 版本,官方推荐长期使用基线
11.02025-04面板化仪表盘、流式查询Prometheus 流式查询、告警规则文件化(file provisioning)
11.12025-05数据源与告警体验修补修复 11.0 回归问题,完善插件生态
11.22025-07当前最新稳定版告警与数据源插件稳定性增强、若干性能修复
结论

Grafana 官方未发布横向性能基准分数,选型评估应以「目标数据源的查询延迟 + 面板渲染耗时」实测为准。版本策略建议:追求长期稳定选 10.4(LTS),需要流式查询与文件化告警等新能力选 11.2,升级前务必核对插件兼容性。

AI 应用场景

LLM 服务可观测性

阶段:模型推理与在线服务监控

解决的问题:传统监控只看 CPU/内存,而 LLM 服务的 token 消耗、首字延迟、缓存命中率完全不可见;Grafana 面板承接业务侧通过 Prometheus 客户端暴露的自定义指标。

具体案例:服务导出 llm_tokens_total、llm_first_token_latency_seconds 等指标,团队搭建「服务健康 + 成本」大盘并按模型/版本分组;典型收益是 token 用量异常与 95 分位延迟劣化在几分钟内被告警触发定位,月度成本归因从半天手工报表缩短到一键面板。

RAG 管道监控

阶段:RAG 管道构建

解决的问题:向量库召回延迟、embedding 批量吞吐、重排序耗时是黑盒,管道出问题时无法判断卡在「检索」还是「生成」环节。

具体案例:在 ingest 脚本中暴露 embedding_time、retrieval_latency 等指标,用 Grafana 把各环节耗时与业务成功率画在同一时间轴上;典型收益是索引任务积压从「事后发现」变为「阈值触发告警」,高峰期 30 分钟内的延迟劣化即可定位到具体环节。

AI 训练集群资源管理

阶段:训练基础设施监控

解决的问题:GPU 利用率靠逐个节点执行 nvidia-smi 查看,显存泄漏、温度过高、空转占卡无法集中发现。

具体案例:用 dcgm-exporter 采集 GPU 指标,经 Prometheus 汇总后在 Grafana 输出「按任务/按节点」的利用率、显存、温度、功耗面板和告警;典型收益是空闲节点实时可见,故障定位从小时级缩短到分钟级,集群平均利用率从约 40% 提升到 70% 以上。

常见误区

误区我把 Grafana 装到服务器上,它应该能自动采集 CPU、内存这些指标,为什么画出来的面板是空的?

正解Grafana 只负责查询、可视化与告警,本身不采集时序数据、也不是时序数据库。指标采集由 Prometheus + Exporter(如 node_exporter)、Grafana Agent、Telegraf 完成,数据落在 Prometheus、Mimir、InfluxDB 等存储中,Grafana 通过数据源插件把数据读出来展示。安装包自带欢迎页与示例面板,容易让人误以为它有内置采集能力。

为何常见:Grafana 常与监控栈一起捆绑安装演示,用户难以分辨哪个组件在采集、哪个在展示。

误区大盘上堆满图表、色彩鲜艳,监控就算完备了。

正解监控闭环 = 数据采集 + 阈值规则 + 通知渠道 + 值班响应。所有指标都画进面板但一条告警规则都没有,故障时仍要人肉盯屏。高质量实践是先收敛关键指标到 SLO(服务级别目标)面板,再为每个 SLO 配置告警、联系点与升级策略,面板只是入口,不是终点。

为何常见:截图展示大盘比展示告警规则更直观,团队汇报时容易把可视化丰富度误当监控完备度。

误区开发环境一直用 admin/admin 登录很顺手,直接把这个习惯带到了生产。

正解Grafana 安装后不会强制修改默认密码,遗留默认口令会被扫描工具直接命中。生产环境应在首次登录后立即改密,接入企业 SSO(LDAP/OAuth2),关闭匿名访问与游客权限;高安全场景还需开启审计日志。

为何常见:自托管工具通常没有内置强密码策略,安装向导也允许一路回车跳过,缺少默认的「强制改密」拦截。

误区我想用 Grafana 做日志、指标、链路追踪,一个 Grafana 应该全部搞定。

正解Grafana 是统一前端入口,对应的后端存储各自独立:指标存 Prometheus/Mimir,日志存 Loki,链路存 Tempo,采集还需另配 Agent。所谓「Grafana 全家桶」指 LGTM(Loki + Grafana + Tempo + Mimir)这一套组合,而非单一二进制。

为何常见:厂商所有产品都冠以 Grafana 名(Grafana、Grafana Agent、Grafana Cloud),产品名混用造成了「一个软件全包」的印象。

误区Docker 一条命令跑起来很顺,生产环境也照抄这个单实例配置。

正解默认 SQLite 依赖单机文件锁,多副本并发写面板或告警状态时会锁库报 500。生产至少要切换到 PostgreSQL/MySQL 元数据库,并配合共享存储、反向代理与多副本;官方 Helm Chart 和 HA 部署文档都默认使用外部数据库。

为何常见:单实例 demo 往往连续运行几个月无感,问题只在扩容或多副本部署时集中爆发。

面试题

Q1. Grafana Web 界面的默认监听端口是?

单选题 · easy

  • A.3000← 正确答案
  • B.8080
  • C.9090
  • D.5601

答案:A。Grafana 默认监听 3000 端口;9090 是 Prometheus 的默认端口,5601 是 Kibana 的经典端口,8080 常被各种 Web 服务占用。记住「Grafana=3000」即可快速定位安装问题。

Q2. Grafana 首次登录的默认账号密码是?

单选题 · easy

  • A.admin/admin← 正确答案
  • B.root/toor
  • C.admin/123456
  • D.guest/guest

答案:A。默认账号密码均为 admin。Grafana 不会在初始化时强制改密,因此生产环境最容易出安全问题的就是遗留默认口令,面试考察点在「默认 admin/admin + 必须尽快修改」。

Q3. 关于 Grafana 的数据存储,哪种说法正确?

单选题 · easy

  • A.时序指标存储于内置 TSDB
  • B.指标存储依赖外部数据源← 正确答案
  • C.面板配置全部存内存
  • D.告警状态不支持持久化

答案:B。Grafana 不内置时序数据库,指标都存在 Prometheus、Mimir 等外部数据源里,它只用 SQLite/PostgreSQL 存面板、用户等元数据。A 错误地把它当成 TSDB;C、D 与事实相反,配置与告警状态都会持久化。

Q4. Prometheus 默认的数据采集模型是?

单选题 · mid

  • A.服务端主动推送指标
  • B.目标主动上报日志
  • C.周期抓取暴露的指标← 正确答案
  • D.消息队列中转指标

答案:C。Prometheus 是拉取(pull)模型:监控目标通过 HTTP 暴露 /metrics 接口,Prometheus 按配置的时间间隔主动抓取。A 是推送(push)模型的说法,B 是日志语义,D 不是 Prometheus 的默认采集方式。

Q5. 下列哪些是 Grafana 官方支持的数据源?

多选题 · mid

  • A.Elasticsearch← 正确答案
  • B.Prometheus← 正确答案
  • C.CloudWatch← 正确答案
  • D.TensorBoard

答案:ABC。Elasticsearch、Prometheus、CloudWatch(AWS)都有官方数据源插件;TensorBoard 是 TensorFlow 的可视化工具,不是 Grafana 数据源。这类题考察对「数据源插件生态」的了解,官方文档有完整目录。

Q6. 仪表盘变量(Dashboard Variables)的主要作用是?

单选题 · mid

  • A.压缩面板的存储开销
  • B.动态切换查询的过滤条件← 正确答案
  • C.加密数据源的访问凭证
  • D.定时刷新面板的缓存数据

答案:B。模板变量把查询中的常量(如主机名、环境、时间范围)参数化,用户通过下拉框动态切换过滤条件,避免为每个实例都建一个面板。A、C、D 分别是存储、安全、刷新机制的能力,与变量无关。

Q7. Grafana 代码化配置(Provisioning)能管理哪类资源?

单选题 · mid

  • A.用户登录的密码策略
  • B.数据源与仪表盘声明← 正确答案
  • C.服务器内核参数配置
  • D.底层时序库的存储引擎

答案:B。Provisioning 用 YAML 声明数据源、仪表盘、告警规则、联系点等 Grafana 内部资源,随代码仓库版本化,重启后按声明恢复。A、C、D 分别属于 Grafana 之外的安全策略、操作系统和数据库范畴。

Q8. 在 Grafana 统一告警中,告警评估完成后通知链路的第一跳是?

单选题 · mid

  • A.联系点
  • B.数据源
  • C.通知策略← 正确答案
  • D.静默规则

答案:C。通知链路为「告警规则 → 通知策略 → 联系点」:规则产生告警实例后,先匹配通知策略做路由、分组与抑制,再由策略指向的联系点发送通知。A 是最终目的地,B 是查询来源,D 是告警期间的临时屏蔽机制。

Q9. 多副本高可用部署 Grafana,下列哪些做法正确?

多选题 · hard

  • A.多副本共享同一套数据库← 正确答案
  • B.各副本使用独立 SQLite
  • C.共享面板与快照存储← 正确答案
  • D.开启高可用告警协调← 正确答案

答案:ACD。HA 要求用 PostgreSQL/MySQL 作为共享元数据库(A),面板、快照等文件放在 S3/EFS 类共享存储(C),并让副本间通过 gossip 协议协调告警归属,避免重复通知(D)。B 各副本独立 SQLite 会导致状态不一致,是错误的。

Q10. 关于 Grafana 版本与升级,哪些说法正确?

多选题 · hard

  • A.升级前应先备份数据库← 正确答案
  • B.8.0 起核心改为 AGPLv3← 正确答案
  • C.9.5 与 10.4 是长期支持版← 正确答案
  • D.所有插件在任意版本可用

答案:ABC。主版本升级会迁移元数据库,必须先备份(A);Grafana 自 8.0 起核心开源协议从 Apache 2.0 调整为 AGPLv3(B);官方将 9.5 与 10.4 标记为 LTS(C)。D 错误,插件与主版本存在兼容矩阵,升级前需用 grafana-cli 核对。