Come aggiungere dashboard Grafana personalizzate via codice con il chart Helm Kube-Prometheus-Stack

Con questo approccio le sue dashboard restano disponibili anche dopo un nuovo deploy di Grafana o in un altro ambiente o cluster.

Con questo approccio le sue dashboard restano disponibili anche dopo un nuovo deploy di Grafana o in un altro ambiente o cluster

Prometheus si è ormai affermato come strumento di monitoraggio di riferimento e, insieme a Grafana e Alertmanager, costituisce per molte organizzazioni lo stack completo di observability e alerting.

Gestire e distribuire singolarmente ciascuno di questi componenti, però, è laborioso e comporta il rischio di disallineamenti man mano che l'infrastruttura evolve. Grazie al chart Helm kube-prometheus-stack, mantenuto dalla prometheus-community, è possibile centralizzare in modo ordinato la configurazione di tutti e tre gli strumenti in un unico file Helm values. In questo articolo vediamo come gestire l'aggiunta di dashboard Grafana direttamente nel chart Helm, così che le sue dashboard restino disponibili anche dopo un nuovo deploy di Grafana o in un altro ambiente/cluster.

Prerequisiti

Per prima cosa occorre clonare il repository del chart Helm kube-prometheus-stack: non è infatti possibile mantenere le dashboard personalizzate nel codice se il chart viene scaricato e applicato da remoto; possiamo aggiungerle solo applicando il chart da una copia locale. Sono inoltre necessari i seguenti strumenti, installati sulla propria workstation:

• Git
• Helm
• Kubectl
• L'IDE che preferisce

$ git clone https://github.com/prometheus-community/helm-charts.git
$ cd helm-charts/charts/kube-prometheus-stack

Una volta nella cartella charts, ci spostiamo nella cartella delle dashboard di Grafana, che contiene tutte le dashboard fornite di serie.

$ cd templates/grafana/dashboards-1.14/
$ ls
alertmanager-overview.yaml	   grafana-overview.yaml
k8s-resources-pod.yaml		   namespace-by-workload.yaml
pod-total.yaml			   statefulset.yaml
apiserver.yaml			   k8s-coredns.yaml
k8s-resources-workload.yaml	   node-cluster-rsrc-use.yaml

Come può notare, l'installazione di Grafana include numerose dashboard. Vengono applicate da questa directory tramite i template configmap che essa contiene.

Esportare la dashboard personalizzata

Dopo aver creato e salvato una dashboard personalizzata in Grafana, ci serve l'export del json da inserire nel configmap nel passaggio successivo. Faccia clic sull'ingranaggio delle impostazioni della dashboard e selezioni "JSON Model" nel pannello di sinistra. Da qui possiamo copiare il json e tenerlo da parte:

Aggiungere la dashboard personalizzata

A questo punto possiamo aggiungere il nostro template Helm configmap alla cartella dashboards. Il modo più semplice è duplicare uno dei file yaml già presenti, rinominarlo con il nome della propria dashboard e inserirvi il json. Nel mio esempio, in coerenza con la dashboard mostrata sopra, sarà "time-series-graph.yaml". Possiamo ora iniziare a modificare il template. Per prima cosa rimuoviamo il commento all'inizio del file, ovvero questa parte:

{{- /*
Generated from 'alertmanager-overview' from https://raw.githubusercontent.com/prometheus-operator/kube-prometheus/main/manifests/grafana-dashboardDefinitions.yaml
Do not change in-place! In order to change this file first read following link:
https://github.com/prometheus-community/Helm-charts/tree/main/charts/kube-prometheus-stack/hack
*/ -}}

Successivamente aggiorniamo il nome della ConfigMap in un paio di punti, a partire da qui:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: {{ template "kube-prometheus-stack-grafana.namespace" . }}
  name: {{ printf "%s-%s" (include "kube-prometheus-stack.fullname" $) "alertmanager-overview" | trunc 63 | trimSuffix "-" }}

Sostituirò "alertmanager-overview", da cui abbiamo copiato il template, con "time-series-graphs", in linea con il nome della mia dashboard e del relativo file yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: {{ template "kube-prometheus-stack-grafana.namespace" . }}
  name: {{ printf "%s-%s" (include "kube-prometheus-stack.fullname" $) "time-series-graph" | trunc 63 | trimSuffix "-" }}

Modifichiamo poi il nome della sezione data del template configmap, da:

data:
  alertmanager-overview.json: |-

a:

data:
  time-series-graph.json: |-

Sostituiamo quindi il JSON della dashboard esistente con quello copiato dalle impostazioni della dashboard di Grafana, posizionandolo subito sotto questa riga come mostrato di seguito e facendo attenzione a indentare l'intero json di almeno un tab:

data:
  time-series-graphs.json: |-
    {
        "__inputs": [\
\
        ],
        "__requires": [\
\
        ],
        "annotations": {
            "list": [\
\
            ]
        },
        "editable": false,
        "gnetId": null,
        "graphTooltip": 1,
        "hideControls": false,
        "id": null,
        "links": [\
\
        ],
        "refresh": "30s",
        "rows": [\
...\
```\
\

Generare i template Helm renderizzati\

Ora che abbiamo aggiunto il file yaml del template Helm configmap della dashboard, controlliamo quali manifest yaml vengono generati dal chart Helm per verificare che la ConfigMap della nostra dashboard sia stata prodotta correttamente:
\

# Aggiungiamo a Helm i repository dei chart che ci servono\
$ Helm repo add grafana https://grafana.github.io/Helm-charts\
\
$ Helm repo add prometheus-community https://prometheus-community.github.io/Helm-charts\
\
# Scarichiamo tutte le dipendenze dei chart e aggiorniamo\
$ Helm dependency build\
\
$ Helm repo update\
```\
\
Possiamo ora eseguire il comando Helm template per renderizzare i manifest yaml a partire dai nostri template Helm e salvarli su file per analizzarli successivamente. Usiamo il flag —validate per verificare che i manifest yaml Kubernetes siano validi rispetto al contesto attuale del cluster Kubernetes:\
\
```\
$ Helm template kube-prometheus-stack . --validate > rendered-template.yaml\
```\
\
Ispezioniamo poi il file rendered-template.yaml per verificare che la ConfigMap sia stata creata e venga applicata quando lanceremo il comando Helm install nel passaggio successivo:\
\
```\
$ cat rendered-template.yaml\
…\
---\
# Source: kube-prometheus-stack/templates/grafana/dashboards-1.14/time-series-graphs.yaml\
apiVersion: v1\
kind: ConfigMap\
metadata:\
  namespace: default\
  name: kube-prometheus-stack-time-series-graphs\
  annotations:\
    {}\
  labels:\
    grafana_dashboard: "1"\
    app: kube-prometheus-stack-grafana\
    app.kubernetes.io/managed-by: Helm\
    app.kubernetes.io/instance: kube-prometheus-stack\
    app.kubernetes.io/version: "32.2.1"\
    app.kubernetes.io/part-of: kube-prometheus-stack\
    chart: kube-prometheus-stack-32.2.1\
    release: "kube-prometheus-stack"\
    heritage: "Helm"\
data:\
  time-series-graphs.json: |-\
    {\
      "annotations": {\
        "enable": false,\
        "list": [\
          {\
            "builtIn": 1,\
            "datasource": "-- Grafana --",\
            "enable": true,\
            "hide": true,\
            "iconColor": "rgba(0, 211, 255, 1)",\
            "name": "Annotations & Alerts",\
```\
\
Una rapida ricerca di "time-series" nel file conferma che la ConfigMap è stata creata e che il campo data contiene il json della dashboard aggiunta in precedenza.\
\
Infine, applichiamo il chart Helm al nostro cluster Kubernetes e, non appena Grafana è attivo, possiamo verificare la presenza della dashboard:\
\
```\
$ Helm install kube-prometheus-stack .\
```\
\
![graphana-dashboards](https://media.doit.com/imports/wordpress/2022/04/f4aa0c1fd59e-graphana-dashboards.jpg)\
\

Articoli correlati\

\

Amazon Bedrock Pricing: la guida CloudOps alla gestione dei costi dell'AI\

Amazon Bedrock applica una tariffa per token di input e output elaborati, con costi che variano in base al modello, alla modalità di pricing e ai workloads

\

Pricing di Databricks: DBU, tier e controllo dei costi\

Databricks fattura il compute in Databricks Units (DBU), conteggiate al secondo, in aggiunta alla fattura separata del suo

\

Cosa sono i servizi di infrastruttura cloud? La guida CloudOps\

I servizi di infrastruttura cloud — compute, storage e networking — sono il sostrato operativo che ogni team CloudOps gestisce quotidianamente. Scegliere quello giusto

Cerca

Cerca
\

Fissi una call con il nostro team\

Selezioni una regioneAmericasEMEAAPACNel passaggio successivo le verranno proposte data e ora disponibili