Grafana系列-GaC-1-Grafana即代碼的幾種實作方式

系列文章

• 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 撰寫.

標籤：其他

上一篇：A First course in FEM —— matlab代碼實作求解傳熱問題（穩態）

下一篇：返回列表