Grafana 是开源的可观测性与可视化平台,核心定位是「把分散在各处的监控数据统一画到一块面板上」:它通过数据源插件接入 Prometheus、Loki、Elasticsearch、MySQL、ClickHouse、云厂商 API 等几十种数据源,提供统一的查询、可视化、仪表盘与告警能力。它的典型用户是 SRE/DevOps 工程师:服务器指标、日志、链路追踪、数据库状态、AI 训练集群的 GPU 利用率,都可以收敛到同一个 Web 入口,并在指标越界时通过统一的告警规则通知到人。与深度绑定 Elastic 生态的 Kibana、商业闭环的 Datadog 不同,Grafana 对数据源保持中立,本身不存储时序数据,部署自由度高,核心版本开源免费,是企业自建监控体系的事实标准之一。 本篇按「为什么需要 → 安装配置 → 快速上手 → 核心能力 → 生产部署 → 选型对比 → 误区 → 面试题 → 资源」的顺序组织,读者按章节走一遍即可在半小时内搭建出第一个可用的大盘。
对 AI 从业者而言,Grafana 是 AI 基础设施(训练集群、LLM 服务、RAG 管道)可观测性的通用入口,掌握它等于掌握了「指标 → 面板 → 告警」全链路交付能力,是 MLOps/Infra 岗位的标配技能。
速览卡是工具类内容的固定首屏模块: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 界面。
# 方式一: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>
# 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
helm repo add grafana https://grafana.github.io/helm-chartshelm upgrade --install grafana grafana/grafana --namespace monitoring --create-namespace
| 维度 | Grafana | Kibana | Datadog | Zabbix |
|---|---|---|---|---|
| 定位 | 数据源中立的观测可视化平台 | Elastic 生态专用可视化 | SaaS 全栈可观测商业平台 | 自带采集与存储的一体化监控系统 |
| 数据接入 | 70+ 数据源插件,指标/日志/链路通吃 | 仅支持 Elasticsearch 后端 | 内置 Agent,闭源生态 | 自家 Agent 采集,模板化接入 |
| 查询语言 | 各数据源原生查询(PromQL/LogQL/SQL) | KQL 与 Lucene | 专有查询语法 | 类 SQL 触发器表达式 |
| 告警能力 | 内置统一告警,跨数据源混合评估 | 依赖 Elastic 告警,配置较重 | 告警丰富,自带智能降噪 | 触发器成熟,通知渠道多 |
| 部署方式 | 自托管/容器/Helm/云托管均可 | 通常随 Elastic Stack 一起部署 | 仅 SaaS,按主机与用量计费 | 自托管为主 |
| License | AGPLv3 核心开源可商用 | 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.5 | 2023-03 | 9.x 收官版,首个 LTS | 日志面板、权限与注释增强,生产环境稳定基线 |
| 10.0 | 2023-06 | Scenes 面板框架、子查询 | 面板渲染管线重构,为面板化仪表盘打基础 |
| 10.4 | 2024-03 | 可访问性与可观测性增强 | 第二个 LTS 版本,官方推荐长期使用基线 |
| 11.0 | 2025-04 | 面板化仪表盘、流式查询 | Prometheus 流式查询、告警规则文件化(file provisioning) |
| 11.1 | 2025-05 | 数据源与告警体验修补 | 修复 11.0 回归问题,完善插件生态 |
| 11.2 | 2025-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 界面的默认监听端口是?
- A.3000← 正确答案
- B.8080
- C.9090
- D.5601
答案:A。Grafana 默认监听 3000 端口;9090 是 Prometheus 的默认端口,5601 是 Kibana 的经典端口,8080 常被各种 Web 服务占用。记住「Grafana=3000」即可快速定位安装问题。
Q2. Grafana 首次登录的默认账号密码是?
- A.admin/admin← 正确答案
- B.root/toor
- C.admin/123456
- D.guest/guest
答案:A。默认账号密码均为 admin。Grafana 不会在初始化时强制改密,因此生产环境最容易出安全问题的就是遗留默认口令,面试考察点在「默认 admin/admin + 必须尽快修改」。
Q3. 关于 Grafana 的数据存储,哪种说法正确?
- A.时序指标存储于内置 TSDB
- B.指标存储依赖外部数据源← 正确答案
- C.面板配置全部存内存
- D.告警状态不支持持久化
答案:B。Grafana 不内置时序数据库,指标都存在 Prometheus、Mimir 等外部数据源里,它只用 SQLite/PostgreSQL 存面板、用户等元数据。A 错误地把它当成 TSDB;C、D 与事实相反,配置与告警状态都会持久化。
Q4. Prometheus 默认的数据采集模型是?
- A.服务端主动推送指标
- B.目标主动上报日志
- C.周期抓取暴露的指标← 正确答案
- D.消息队列中转指标
答案:C。Prometheus 是拉取(pull)模型:监控目标通过 HTTP 暴露 /metrics 接口,Prometheus 按配置的时间间隔主动抓取。A 是推送(push)模型的说法,B 是日志语义,D 不是 Prometheus 的默认采集方式。
Q5. 下列哪些是 Grafana 官方支持的数据源?
- A.Elasticsearch← 正确答案
- B.Prometheus← 正确答案
- C.CloudWatch← 正确答案
- D.TensorBoard
答案:ABC。Elasticsearch、Prometheus、CloudWatch(AWS)都有官方数据源插件;TensorBoard 是 TensorFlow 的可视化工具,不是 Grafana 数据源。这类题考察对「数据源插件生态」的了解,官方文档有完整目录。
Q6. 仪表盘变量(Dashboard Variables)的主要作用是?
- A.压缩面板的存储开销
- B.动态切换查询的过滤条件← 正确答案
- C.加密数据源的访问凭证
- D.定时刷新面板的缓存数据
答案:B。模板变量把查询中的常量(如主机名、环境、时间范围)参数化,用户通过下拉框动态切换过滤条件,避免为每个实例都建一个面板。A、C、D 分别是存储、安全、刷新机制的能力,与变量无关。
Q7. Grafana 代码化配置(Provisioning)能管理哪类资源?
- A.用户登录的密码策略
- B.数据源与仪表盘声明← 正确答案
- C.服务器内核参数配置
- D.底层时序库的存储引擎
答案:B。Provisioning 用 YAML 声明数据源、仪表盘、告警规则、联系点等 Grafana 内部资源,随代码仓库版本化,重启后按声明恢复。A、C、D 分别属于 Grafana 之外的安全策略、操作系统和数据库范畴。
Q8. 在 Grafana 统一告警中,告警评估完成后通知链路的第一跳是?
- A.联系点
- B.数据源
- C.通知策略← 正确答案
- D.静默规则
答案:C。通知链路为「告警规则 → 通知策略 → 联系点」:规则产生告警实例后,先匹配通知策略做路由、分组与抑制,再由策略指向的联系点发送通知。A 是最终目的地,B 是查询来源,D 是告警期间的临时屏蔽机制。
Q9. 多副本高可用部署 Grafana,下列哪些做法正确?
- A.多副本共享同一套数据库← 正确答案
- B.各副本使用独立 SQLite
- C.共享面板与快照存储← 正确答案
- D.开启高可用告警协调← 正确答案
答案:ACD。HA 要求用 PostgreSQL/MySQL 作为共享元数据库(A),面板、快照等文件放在 S3/EFS 类共享存储(C),并让副本间通过 gossip 协议协调告警归属,避免重复通知(D)。B 各副本独立 SQLite 会导致状态不一致,是错误的。
Q10. 关于 Grafana 版本与升级,哪些说法正确?
- 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 核对。