关于运维:Grafana系列GaC1Grafana即代码的几种实现方式

系列文章

Grafana 系列文章
Terraform 系列文章

概述

GaC(Grafana as Code, Grafana 即代码) 很显著是扩大自 IaC(Infrastructure as Code, 基础设施即代码)的概念.

在Terraform 系列 - 什么是 IaC?一文中, 咱们曾经具体地阐明了相干的概念, 咱们能够间接套用在 GaC 上:

Grafana 即代码 (Grafana as Code, GaC) 是指通过代码而不是手动流程 / 控制台点击来治理和配置 Grafana。

这里有 2 个关键词：

Grafana
Code

Grafana 是被治理对象，在这里，不仅仅是指 Grafana OSS 这一款产品, 还包含 Grafana Labs 提供的商业产品和云服务. 包含不限于:

Grafana Alerting
Grafna Cloud Stack, 包含 Grafana Cloud 的:
- 认证
- 权限
- 策略
- Service Account
- 组织
- ...
Grafana Enterprise (企业版)
Grafana OnCall: 事件响应和治理平台(IRM)
Grafana SLO: SLA 和可用性治理
Grafana Synthetic Monitoring: 拨测, 相似 BlackBoxProbe

Code 是治理形式，即像治理代码一样治理 Grafana 资源。那么治理代码最重要的局部：版本治理是绕不开的。
...

当然, 这一系列文章, 次要还是关注于通过代码的模式来治理 Grafana 这个产品.

这篇文章次要跟着Grafana as code: A complete guide to tools, tips, and tricks 这篇官网文章的逻辑来进行, 变交叉笔者的评估和最终抉择.

GaC 的几种官网计划

官网举荐这么几种计划, 另外我也会加几个我认为可行的计划:

基于 Terraform 的 Grafana Terraform provider
基于 Ansible 的 Grafana Ansible collection
Grizzly: Grafana 官网开源的一个部署和配置Grafana 一体化 cli 工具.
Tanka: Grafana 官网开源的一个基于 jsonnet 的 Kubernetes 集群管理工具
基于 Crossplane 的Grafana Crossplane provider
基于 Kubernetes CRD 的 Kubernetes Grafana Operator
基于 API 的定制化开发:
- grafana-api-golang-client
- Grafana API
基于 Jsonnet 的 Dashboard as Code
- grafana/jsonnet-libs: Grafana Labs' Jsonnet libraries (github.com)
- grafana/grafonnet: Jsonnet library for generating Grafana dashboards. (github.com)
- grafana/grafonnet-lib: Jsonnet library for generating Grafana dashboard files. (github.com) (已弃用, 然而仍有很多 Dashboard 资源依赖它)
- Prometheus Monitoring Mixins | Monitoring Mixins
- kubernetes-monitoring/kubernetes-mixin: A set of Grafana dashboards and Prometheus alerts for Kubernetes. (github.com)

是不是有点目不暇接, 是不是有点挑花眼了?

我刚开始也是这样, 不必放心, 咱们一一过一下. 很快 GaC 的脉络就会清晰起来.

Notes:
这外面 Crossplane 大家可能没怎么听过, 刚好我 2021 年有一篇介绍其的文章, 感兴趣的能够作为扩大浏览.
Crossplane - 比 Terraform 更先进的云基础架构治理平台？

Jsonnet

依据 Grafana 的一些官网演讲视频和代码库以及博客文章, Grafana 是重度依赖 Jsonnet 这一配置语言的. 前面咱们会具体介绍其历史及应用办法.

无论咱们应用哪一种 GaC 计划, 基于 Jsonnet 的 Dashboard as Code 都是必选的.

在 Terraform 中, 能够通过Jsonnet Provider 和 Grafana 配合应用
在 Ansible 中, 能够在 task 之前退出对 jsonnet 相干依赖的装置, 以及 jsonnet 生成 Dashboard 的前置 tasks
在 Grizzly 和 Tanka 中, jsonnet 就是一级公民. 如 Grizzly 能够间接应用 Jsonnet
...

小结, Jsonnet 是目前简直惟一的深度 Dashboard as Code 计划, 必选.

Notes:
如果是通俗地利用 GaC, 那么 Dashboard 间接通过 Dashboard json 文件作为代码治理也能够.
然而进入应用深水区, 在 Dashboard 多起来, 且有大量反复的配置的状况下, Jsoonet 是惟一抉择.

Grafana Terraform provider

Grafana 管理员能够应用Grafana的Terraform Provider 治理 dashboards 和 alerts，增加 synthetic monitoring probes 和查看，治理身份和拜访，等等。

用于创立仪表盘的Terraform配置示例如下：

resource "grafana_dashboard" "metrics" {  config_json = jsonencode({    title   = "as-code dashboard"    uid     = "ascode"  })}

实用用户

Grafana Terraform Provider 更适宜那些曾经在非Grafana应用案例中应用Terraform的用户。

对于目前心愿在Grafana Cloud 或Grafana的OSS部署上治理整个Grafana生态系统资源的用户，最好应用Grafana Terraform Provider，因为与Grafana的其余作为代码的解决方案相比，它还反对最多的Grafana资源。

笔者的最终抉择, 就是:

Grafana Terraform Provider + Jsonnet

其中很大的一个起因就是下面提到的: 反对最多的Grafana资源.

笔者打算在 Aws Managed Grafana 中应用 Grafana, Aws Managed Grafana 相比 Grafana OSS, 性能还是有一点点的细微差别:

AWS Managed Grafana 有 DataSource 的 Permission 治理性能, 而 Grafana OSS 并没有这项性能.

然而 Grafana Terraform Provider 是提供这一性能的, 该性能位于 Grafana Enterprise 上面. 但的确可用.

目前我须要用到的 Grafana 性能有:

Grafana 用户
Grafana Team
Grafana 组织
Grafana DataSource
Grafana DataSource Permission
Grafana Folder
Grafana Folder Permission
Grafana Dashboard
Grafana Dashboard Permission
Grafana Alerting

只有 Grafana Terraform Provider 提供了残缺的性能.

已知的限度

治理仪表盘并不是一个最简略的过程--用户必须解决长长的JSON，这也会变得难以审查和更新。Grafonnet能够帮忙生成可用于Terraform的仪表盘JSON，但Grafonnet须要理解Jsonnet，所以这对一些用户来说是不可取的。

不论哪种计划, Jsonnet 其实是对所有进入 GaC 深水区的用户都必须把握的, 逃不掉的.

Grafana Ansible collection

配置管理的资源能够通过Ansible Collection for Grafana提供。它能够用来治理各种资源，包含 folders、cloudstack和dashboards。用户能够通过编写应用HTTP API治理Grafana资源的Ansible playbooks，以编程形式治理Grafana上目前还不属于Grafana Ansible汇合的资源。

创立仪表盘的Ansible配置示例如下：

- name: dashboard as code  grafana.grafana.dashboard:    dashboard: {      "title": "as-code dashboard",      "uid": "ascode"    }    stack_slug: "{{ stack_slug }}"    grafana_api_key: "{{ grafana_api_key }}"    state: present

实用用户

和Terraform一样，Grafana Ansible Collection 更适宜曾经将Ansible用于非Grafana用例的人。此外，该 Collection 目前只实用于Grafana Cloud，所以它对那些心愿应用Ansible申明式治理资源的Grafana Cloud客户最有意义。

已知的限度

截至目前，Grafana Ansible Collection 只实用于Grafana Cloud，并且只反对8种资源：

API密钥
Cloud Stack
plugins
dashboards
folders
data sources
alert contact points
alert notification policies

对于心愿用Ansible以代码模式治理整个Grafana生态系统的用户来说，这可能是一个毛病。与Terraform一样，仪表盘的构建也不是最简略的过程。

小结, Grafana Ansible Collection 最大的毛病在于: 只实用于Grafana Cloud，并且只反对8种资源.

Grizzly

Grizzly 是一个命令行工具，容许你用代码治理你的可察看性资源。Grizzly反对Kubernetes启发的YAML示意的Grafana资源，这使得它更容易相熟。Grizzly反对在Grafana实例内挪动仪表盘，也能够检索曾经配置的Grafana资源的信息。Grizzly目前反对：

Grafana dashboards/dashboard folders
Grafana data sources
Grafana Cloud 中的 Prometheus recording rules/alerts
Grafana Cloud Synthetic Monitoring checks

Grizzly也能够应用 Grafonnet 部署在Jsonnet中构建的仪表盘。(在Grafonnet文档中理解更多信息)。

用于创立仪表盘的Kubernetes格调的Grizzly配置样本看起来是这样的：

apiVersion: grizzly.grafana.com/v1alpha1kind: Dashboardmetadata:    name: as-code-dashboardspec:    title: as-code dashboard    uid: ascode

实用用户

Grizzly最适宜应用Jsonnet来治理Grafana资源的用户，或者喜爱用Kubernetes格调的YAML定义他们的Grafana资源。

已知的限度

Grizzly目前不反对Grafana OnCall和Grafana Alerting资源。

也不反对 DataSource/Folder/Dashboard Permission 等资源.

小结, Grizzly最适宜应用Jsonnet来治理Grafana资源的用户. 然而反对的 Grafana 资源也不够全.

Grafana Crossplane provider

Grafana Crossplane Provider 应用Terrajet构建，为Grafana Terraform Provider 反对的所有资源提供反对。它使用户可能将Grafana资源定义为Kubernetes清单，也会帮忙那些应用ArgoCD等工具围绕Kubernetes清单建设GitOps管道的用户。

要开始应用Grafana Crossplane Provider，请在Kubernetes集群中装置Crossplane，并应用此命令装置 provider：

kubectl crossplane install provider grafana/crossplane-provider-grafana:v0.1.0

在装置 provider 的过程中，Terraform provider 反对的所有资源的CRD被增加到集群中，因而用户能够开始将他们的Grafana资源定义为Kubernetes自定义资源。Crossplane provider 确保在 CRD 中所定义的内容在Grafana用户界面中是可见的。如果在用户界面中间接进行了任何更改，那么当提供者从新同步时，这些更改将被抛弃。这有助于确保集群中的任何申明性定义都将是Grafana资源的实在起源。

要开始应用，请参考Grafana Crossplane资源库中的示例文件夹。

用于创立 Dashboard 的Kubernetes CRD 样本看起来像这样：

apiVersion: grafana.jet.crossplane.io/v1alpha1kind: Dashboardmetadata:  name: as-code-dashboardspec:  forProvider:    configJson: |      {        "title": "as-code dashboard",        "uid": "ascode"      }  providerConfigRef:    name: grafana-crossplane-provider

实用用户

Grafana Crossplane provider 适宜现有的Crossplane用户，他们心愿从Kubernetes内治理Grafana资源，并作为Kubernetes清单用于GitOps管道。

已知限度

Crossplane provider 依赖于在Kubernetes集群中装置了Crossplane CLI和Crossplane。这种依赖性对于非Crossplane用户来说是没有吸引力的。它也处于alpha阶段，所以还没有达到稳固的状态。

小结, 适宜曾经用了 CrossPlane 的用户, 但对于非Crossplane用户来说就没啥吸引力了. 另外, 它还不稳固.

Kubernetes Grafana Operator

Grafana Operator 是一个 Kubernetes Operator，用于配置和治理Grafana及其应用Kubernetes CR 的资源。它是一个由Grafana社区建设的Kubernetes原生解决方案。它还能够把在Grafonnet中构建的仪表盘作为仪表盘配置的起源。

请参考grafana-operator仓库中的文档局部来开始应用。

一个应用Grafana操作器创立仪表盘的Kubernetes配置样本看起来是这样的：

apiVersion: integreatly.org/v1alpha1kind: GrafanaDashboardmetadata:  name: simple-dashboard  labels:    app: grafanaspec:  json: >    {      "title": "as-code dashboard",      “uid” : “ascode”    }

实用用户

对于心愿从Kubernetes内治理Grafana资源的用户来说，Grafana-operator十分好用，并作为Kubernetes清单用于GitOps管道。

已知的限度

这只实用于Grafana OSS，所以Grafana Cloud用户将无奈应用它。另外，Grafana-operator没有Helm Chart，这对于领有围绕Helm构建的管道的组织来说可能是个问题。

小结, 笔者集体认为, Kubernetes Grafana Operator 是非常适合这类用户的:

自托管 Grafana OSS
Grafana OSS 部署在 Kubernetes 集群内

并且其还有这些劣势:

反对 Grafana OSS 各种细节配置
Grafana Dashboard 能够来自 Grafana com 的 id(其余工具如同都没有)
反对装置 Grafana Plugin(其余工具如同都没有)
完满符合 GitOps

相应地, 也有一些劣势:

社区开发的, 短少 Grafana 官网反对
不反对 Grafana Cloud/AWS Managed Grafana 等云服务.

Tanka

为你的Kubernetes集群提供洁净、简洁和超级灵便的YAML替代品

简洁：Jsonnet语言比YAML更显著地表白了你的应用程序。
复用：构建库，随时导入它们，甚至在GitHub上分享它们
简洁：应用Kubernetes库和形象，你将永远不会再看到模板!
信念：进行猜想，应用tk diff来看看到底会产生什么
Helm：可重现的Helm Chart 中的 vendor、批改和导出。
生产就绪：Tanka部署了Grafana Cloud和更多的生产设置

一个应用 tanka 创立 Prometheus + Grafana K8s 资源的配置样本看起来是这样的：

local k = import "github.com/grafana/jsonnet-libs/ksonnet-util/kausal.libsonnet";{  _config:: {    grafana: {      port: 3000,      name: "grafana",    },    prometheus: {      port: 9090,      name: "prometheus"    }  },  local deployment = k.apps.v1.deployment,  local container = k.core.v1.container,  local port = k.core.v1.containerPort,  local service = k.core.v1.service,  prometheus: {    deployment: deployment.new(      name=$._config.prometheus.name, replicas=1,      containers=[        container.new($._config.prometheus.name, "prom/prometheus")        + container.withPorts([port.new("api", $._config.prometheus.port)]),      ],    ),    service: k.util.serviceFor(self.deployment),  },  grafana: {    deployment: deployment.new(      name=$._config.grafana.name, replicas=1,      containers=[        container.new($._config.grafana.name, "grafana/grafana")        + container.withPorts([port.new("ui", $._config.grafana.port)]),      ],    ),    service:      k.util.serviceFor(self.deployment)      + service.mixin.spec.withType("NodePort"),  },}

实用用户

严格来说, Tanka 不应该呈现在这里. Tanka 实质上是一个 Kubernetes 基础设施管理工具. 对标的竞品是:

Kustomize
Helm
Kubernetes Operator

甚至是:

Terraform
Ansible

如果你是 Jsonnet 配置语言的狂热粉丝, 并且想要通过 Jsonnet 治理 Kubernetes 基础设施和可察看性的 Grafana Dashboard、Prometheus rule 和 Alert rule。那么 tanka 是适宜你的。

已知的限度

摈弃 Kubernetes YAML，齐全采纳 jsonnet 治理资源，你须要另外把握以下常识：

Jsonnet
Tanka 应用
Kubernetes 资源的相干 Jsonnet Library
Grafana 相干的 Jsonnet Library

小结，不倡议应用 tanka，除非你是 Jsonnet 配置语言的狂热粉丝和专家。

基于 API 的定制化开发

Grafana 的 API，我也认真找了一圈，官网有这么几种 API：

Grafana API：最底层的 API 接口。
grafana-api-golang-client: 基于 Grafana API 的低级别的 golang 客户端. 也是 Grafana Terraform provider 的底层实现

如果应用 Grafana API, 创立 Dashboard 的示例如下:

POST /api/dashboards/db HTTP/1.1Accept: application/jsonContent-Type: application/jsonAuthorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk{  "dashboard": {    "id": null,    "uid": null,    "title": "Production Overview",    "tags": [ "templated" ],    "timezone": "browser",    "schemaVersion": 16,    "version": 0,    "refresh": "25s"  },  "folderId": 0,  "folderUid": "l3KqBxCMz",  "message": "Made changes to xyz",  "overwrite": false}

如果应用 grafana-api-golang-client, 创立 Dashboard 的示例能够参考这个测试用例:

https://github.com/grafana/grafana-api-golang-client/blob/master/dashboard_test.go

实用用户

首先, 基于 API 的定制化开发都实用于开发能力强、有更多自定义需要、上述 GaC 计划都不满足需要、须要和公司企业外部的自动化工具整合的状况.

其次, Grafana 提供了基于 golang 的 grafana-api-golang-client, 如果您的技术栈是 golang, 倡议间接应用 grafana-api-golang-client.

如果您的技术栈不是 golang, 则倡议基于 Grafana API 开发.

已知限度

无

惟一的限度就是您/贵团队/贵司的技术能力和资源投入.

总结

这里有一个不便的比照表格，比照了下面提到的所有属性和工具。

属性/工具	Grafana Terraform Provider	Grafana Ansible Collection	Grizzly	Tanka	Grafana CrossPlane Provider	Grafana Operator	Grafana API
反对的Grafana资源	所有资源	Grafana Cloud Stack, plugins, API keys, dashboards, data sources, folders	Synthetic Monitoring checks, dashboards, data sources, folders, Prometheus rules	Unknown	所有次要资源	Folders, data sources, dashboards, notification channels, Grafana plugin, Grafana oss deploy	所有资源
格式化工具	HCL/JSON/Jsonnet	YAML	Jsonnet/YAML/JSON	Jsonnet	YAML/JSON	YAML	取决于你
Kubernetes格调清单			✔️		✔️	✔️	取决于你
在K8s中治理定义资源				✔️	✔️	✔️	取决于你
简略的Dashboard构建流程			✔️				取决于你
获取Grafana资源信息	✔️		✔️	Unknown			取决于你
内置资源同步流程			✔️	Unknown	✔️	✔️	取决于你
实用用户	已在用Terraform的用户	已在用Ansible的用户	冀望Kubernetes格调清单治理Grafana, 内置工作流和同步流程的用户	部署在K8s上且是Jsonnet粉丝/专家的用户	已在用CrossPlane, 或冀望用K8s资源管理Grafana的用户	全副应用Grafana OSS, 并且部署在K8s中, 冀望应用K8s资源管理的用户.	现有计划都不满足, 定制需要较多, 须要和外部工具集成的用户

这里定义的大多数工具能够互相联合应用，使用户实现 1 + 1 > 2 的成果.

我的最终抉择是:

Grafana Terraform provider
Jsonnet

我的 Grafana 次要是以下几类:

AWS Managed Grafana
Grafana OSS
Grafana Cloud Free

我须要用到的 Grafana 性能有:

Grafana 用户
Grafana Team
Grafana 组织
Grafana DataSource
Grafana DataSource Permission
Grafana Folder
Grafana Folder Permission
Grafana Dashboard
Grafana Dashboard Permission
Grafana Alerting

欲了解更多信息或开始应用 Grafana ，请查看每个工具的代码库或和我交换, 敬请期待我的后续文章。

️参考文档

Grafana as code: A complete guide to tools, tips, and tricks

三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.