关于运维: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/v1alpha1
kind: Dashboard
metadata:
    name: as-code-dashboard
spec:
    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/v1alpha1
kind: Dashboard
metadata:
  name: as-code-dashboard
spec:
  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/v1alpha1
kind: GrafanaDashboard
metadata:
  name: simple-dashboard
  labels:
    app: grafana
spec:
  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.1
Accept: application/json
Content-Type: application/json
Authorization: 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 开发.

已知限度

无

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

总结

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

这里定义的大多数工具能够互相联合应用，使用户实现 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 编写.