2. Grafana 架构:前端架构、后端架构、数据源插件机制、面板渲染引擎、报警引擎

Grafana 并非一个单体巨石应用,而是一个由前端、后端、插件系统、渲染引擎和报警引擎组成的模块化架构。理解这一架构是后续进行仪表盘定制、数据源接入以及报警规则调试的基础。本章将从五个核心维度拆解 Grafana 的内部构造。

2.1 整体架构概览

Grafana 采用经典的前后端分离架构,前端负责 UI 交互与面板渲染,后端负责数据代理、认证、持久化与报警调度。数据源插件作为桥梁,连接后端与各类时序数据库。报警引擎则作为独立子系统,周期性评估查询结果并触发通知。

架构要点: 前端不直接连接数据库,所有数据请求均通过后端 API 代理转发,这保证了安全性与跨域控制。
Grafana 整体架构(核心子系统) 前端层(React / TypeScript) 面板渲染引擎 · 路由 · 状态管理 后端层(Go / Gin) API 网关 · 认证 · 数据代理 · 报警引擎 数据源插件层(Plugin SDK) Prometheus · InfluxDB · Elasticsearch · 自定义 存储层(SQLite / PostgreSQL / MySQL) 仪表盘 · 用户 · 组织 · 报警规则

2.2 前端架构

Grafana 前端基于 React 和 TypeScript 构建,采用组件化架构。核心职责包括面板渲染、仪表盘编辑、数据查询构建以及报警规则 UI 配置。

前端模块 技术栈 核心职责
面板渲染引擎 React + D3.js / ECharts 将查询结果渲染为图表、表格、统计值等
数据查询构建器 React Hook + Redux 提供可视化查询编辑器,生成数据源查询语句
路由与状态管理 React Router + Redux Toolkit 管理页面导航、仪表盘状态、用户会话
报警规则 UI React Form + Yup 校验 报警规则创建、编辑、测试与静默管理
调试提示: 前端面板渲染异常时,打开浏览器开发者工具(F12),查看 Network 标签中 /api/ds/query 接口的返回数据,确认后端返回的数据结构是否与面板预期一致。

2.3 后端架构

后端使用 Go 语言 编写,基于 Gin 框架提供 RESTful API。后端不直接存储时序数据,而是作为代理层转发查询请求,并负责用户认证、仪表盘 CRUD、报警规则评估与通知分发。

后端请求处理流程 HTTP 请求 认证中间件 路由分发 业务 Handler 数据源代理 报警引擎 数据库

2.4 数据源插件机制

数据源插件是 Grafana 最灵活的扩展点。每个数据源插件实现统一的 DataSourcePlugin 接口,后端通过插件 SDK 加载并执行查询。前端则提供对应的配置页面和查询编辑器。

核心接口: 每个数据源插件必须实现 Query() 方法,接收 DataSourceQueryRequest,返回 DataQueryResponse。报警引擎也通过此接口获取评估数据。
// 数据源插件核心接口示例(Go)
type DataSourcePlugin interface {
    Query(ctx context.Context, req *DataSourceQueryRequest) (*DataQueryResponse, error)
    TestConnection(ctx context.Context) error
    GetHealth(ctx context.Context) (*HealthCheckResult, error)
}
数据源类型 查询语言 典型用途 报警支持
Prometheus PromQL 容器、微服务监控 ✅ 原生支持
InfluxDB Flux / InfluxQL IoT、系统指标 ✅ 原生支持
Elasticsearch Lucene / ES DSL 日志分析、APM ✅ 原生支持
MySQL / PostgreSQL SQL 业务数据可视化 ✅ 原生支持
CloudWatch Metric Math AWS 基础设施监控 ✅ 原生支持
联动调试注意: 报警规则使用的数据源必须支持报警功能。在数据源配置页面的“报警”选项卡中,确认“Alerting”状态为“已启用”。部分社区插件可能不支持报警。

2.5 面板渲染引擎

面板渲染引擎位于前端,负责将后端返回的时序数据或表格数据转换为可视化图表。Grafana 内置了多种面板类型,每种面板都有独立的渲染逻辑。

  • 时序图(Time Series): 基于 D3.js 和 uPlot,支持多维度曲线、区域填充、阈值线。
  • 柱状图(Bar Chart): 基于 ECharts,适用于分类对比。
  • 统计值(Stat): 显示单个数值,支持颜色阈值和迷你趋势线。
  • 表格(Table): 支持列排序、搜索、单元格格式化。
  • 日志(Logs): 专门用于展示日志流,支持高亮和搜索。
面板渲染流程 用户选择面板 构建查询请求 后端返回数据 面板渲染引擎 用户看到图表

2.6 报警引擎

报警引擎是 Grafana 后端中独立运行的子系统,负责周期性评估报警规则、管理报警状态以及触发通知。从 Grafana 8.0 开始,统一使用 Grafana Alerting(统一报警)体系。

报警引擎组件 说明
Scheduler(调度器) 按规则配置的评估间隔(如 1m、5m)周期性触发评估
Evaluator(评估器) 执行规则中的查询,将结果与阈值条件比较,输出状态(Alerting / OK / Pending)
State Manager(状态管理器) 维护每条规则的状态机,处理 Pending → Alerting 的转换
Notifier(通知器) 根据规则配置的通知渠道(邮件、Slack、PagerDuty 等)发送告警
联动调试关键点: 报警引擎通过数据源插件执行查询。如果数据源返回数据格式异常或超时,报警规则将进入 Error 状态。调试时可在报警规则列表查看“状态历史”和“查询预览”。
报警规则状态机 OK(正常) Pending(待定) Alerting(告警) Error(错误) 阈值触发 持续超阈值 恢复 查询失败 配置变更

2.7 架构联动调试要点

在后续章节的仪表盘与报警规则联动调试中,需要时刻关注架构各层的交互。以下表格总结了常见问题定位方法:

现象 可能原因 排查层
面板显示“No data” 数据源查询超时、查询语句错误、数据源未配置 后端 → 数据源插件
报警规则一直 Pending 评估间隔内未持续超阈值、查询返回空数据 报警引擎 → 数据源插件
面板渲染卡顿 返回数据量过大、前端渲染性能瓶颈 前端渲染引擎
报警通知未收到 通知渠道配置错误、网络问题、联系点未绑定 报警引擎 → Notifier
实战建议: 在调试报警规则时,先使用“测试规则”功能手动触发一次评估,查看返回的查询结果和状态判断。这可以快速区分是数据源问题还是报警逻辑问题。