2. Grafana 架构:前端架构、后端架构、数据源插件机制、面板渲染引擎、报警引擎
Grafana 并非一个单体巨石应用,而是一个由前端、后端、插件系统、渲染引擎和报警引擎组成的模块化架构。理解这一架构是后续进行仪表盘定制、数据源接入以及报警规则调试的基础。本章将从五个核心维度拆解 Grafana 的内部构造。
2.1 整体架构概览
Grafana 采用经典的前后端分离架构,前端负责 UI 交互与面板渲染,后端负责数据代理、认证、持久化与报警调度。数据源插件作为桥梁,连接后端与各类时序数据库。报警引擎则作为独立子系统,周期性评估查询结果并触发通知。
架构要点: 前端不直接连接数据库,所有数据请求均通过后端 API 代理转发,这保证了安全性与跨域控制。
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、报警规则评估与通知分发。
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 状态。调试时可在报警规则列表查看“状态历史”和“查询预览”。
2.7 架构联动调试要点
在后续章节的仪表盘与报警规则联动调试中,需要时刻关注架构各层的交互。以下表格总结了常见问题定位方法:
| 现象 | 可能原因 | 排查层 |
|---|---|---|
| 面板显示“No data” | 数据源查询超时、查询语句错误、数据源未配置 | 后端 → 数据源插件 |
| 报警规则一直 Pending | 评估间隔内未持续超阈值、查询返回空数据 | 报警引擎 → 数据源插件 |
| 面板渲染卡顿 | 返回数据量过大、前端渲染性能瓶颈 | 前端渲染引擎 |
| 报警通知未收到 | 通知渠道配置错误、网络问题、联系点未绑定 | 报警引擎 → Notifier |
实战建议: 在调试报警规则时,先使用“测试规则”功能手动触发一次评估,查看返回的查询结果和状态判断。这可以快速区分是数据源问题还是报警逻辑问题。