Grafana 是一个开源平台,用于对来自许多数据源的指标、日志和追踪进行可视化和告警。大多数人是通过它的 Web UI 接触它的,但 Grafana 安装中重要的一切,也都可以用文件来描述:服务器设置、数据源、仪表板、告警规则、联系点和通知策略。本系列专注于第二种工作方式,这样 Grafana 实例随时可以从 Git 重建,而没有人需要记得上个月有人点击了什么。

工作原理

Grafana 从你无需打开 UI 就能控制的几个层读取配置:

1. 服务器配置(grafana.ini 和 GF_* 环境变量)控制端口、数据库、认证、SMTP 和功能开关。
2. Provisioning 文件(provisioning/ 文件夹中的 YAML)在启动时创建数据源、仪表板 provider、告警资源和插件设置。
3. 磁盘上的仪表板 JSON 文件由仪表板 provider 加载,并在 Grafana 运行期间被重新扫描。
4. API 与 operator(Terraform、Grafana Operator、Git Sync、gcx CLI)管理仅靠文件无法管理的东西,例如团队、service account 和文件夹权限。

因为所有这些都是纯文本,它们契合与其余基础设施相同的 GitOps 工作流,包括 Flux 和 Argo CD。

核心概念

• Data source(数据源) —— 到 Prometheus、Loki 或 PostgreSQL 等后端的连接。仪表板和告警规则按名称或 UID 查询数据源。
• Dashboard(仪表板) —— 由面板和变量构成的 JSON 文档。Grafana 现在在内部使用更新的仪表板 schema,较旧的 JSON 在加载时会被自动迁移。
• Folder(文件夹) —— 组织仪表板和告警规则,并携带权限。
• Provisioning —— 在启动时从文件加载资源,使它们在任何人登录之前就已存在。
• Alerting(告警) —— 告警规则、联系点、通知策略、静默时段和模板,所有这些都可以被 provision。
• Organization(组织) —— 一个 Grafana 服务器内的租户边界;大多数文件都带有 orgId。

为什么要将 Grafana 作为代码运维

• 可复现。 丢失的或新的实例可以从仓库原样恢复。
• 可审查。 仪表板或告警的变更是带 diff 的拉取请求,而不是无从追踪的编辑。
• 跨环境一致。 Dev、staging 和 production 共享定义,只在值上有所不同。
• 漂移可见。 被 provision 的资源可以被锁定以防 UI 编辑,这样 Git 就保持为事实来源。

快速开始

在容器中运行 Grafana,挂载一个 provisioning/ 文件夹,添加一个数据源文件和一个仪表板 provider,并把仪表板 JSON 放在它们旁边。下面的指南从这里开始,并继续讲到告警、密钥、Kubernetes、Terraform 和 Operator。它们基于 Grafana 13 编写;请查阅你所安装版本的 Grafana 文档,因为一些”即代码”功能仍被标记为 alpha。