Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Como adicionar dashboards customizados do Grafana via código no Helm chart Kube-Prometheus-Stack

By Abrar AliApr 11, 20225 min read

Esta página também está disponível em English, Deutsch, Español, Français, Italiano e 日本語.

Com essa abordagem, seus dashboards continuam ativos mesmo quando você reimplanta o Grafana ou parte para outro ambiente ou cluster.

How-to-add-custom-Grafana-dashboards-in-code

Com essa abordagem, seus dashboards continuam ativos mesmo quando você reimplanta o Grafana ou parte para outro ambiente ou cluster

O Prometheus virou a ferramenta de monitoramento de fato e, junto com o Grafana e o Alertmanager, forma a stack completa de observabilidade e alertas em muitas organizações.

O problema é que gerenciar e implantar cada um desses componentes separadamente dá trabalho e abre espaço para falta de sincronização entre eles conforme a infraestrutura muda. Com o Helm chart kube-prometheus-stack, mantido pela prometheus-community, dá para concentrar a configuração das três ferramentas em um único lugar, com um único arquivo de values do Helm. Neste post, mostro como gerenciamos a inclusão de dashboards do Grafana no Helm chart para que, mesmo se você reimplantar o Grafana ou subir em outro ambiente/cluster, seus dashboards continuem lá.

Pré-requisitos

Primeiro, precisamos clonar o repositório com o Helm chart kube-prometheus-stack, já que não dá para versionar nossos dashboards customizados em código se estivermos puxando e aplicando o chart de forma remota; só é possível adicioná-los aplicando o chart a partir de uma cópia local. Também precisamos das seguintes ferramentas instaladas na máquina:

  • Git
  • Helm
  • Kubectl
  • IDE de sua preferência
$ git clone https://github.com/prometheus-community/helm-charts.git
$ cd helm-charts/charts/kube-prometheus-stack

Já dentro da pasta de charts, vamos até a pasta de dashboards do Grafana, que reúne todos os dashboards padrão que vêm de fábrica.

$ 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

Como dá para notar, a instalação do Grafana já vem com vários dashboards. Eles são aplicados a partir desse diretório por meio dos templates de configmaps que ficam ali dentro.

Exportando o dashboard customizado

Depois de criar e salvar um dashboard customizado no Grafana, precisamos exportar o JSON que será incluído no nosso configmap na próxima etapa. Clique na engrenagem de configurações do dashboard e selecione "JSON Model" no painel à esquerda. Aqui dá para copiar o JSON e guardar para depois:

graphana-dashboards

kube-prometheus

Adicionando o dashboard customizado

Agora podemos adicionar nosso próprio template Helm de configmap à pasta de dashboards. O caminho mais fácil é duplicar um dos arquivos yaml existentes na pasta, renomeá-lo com o nome do seu dashboard e colar o JSON nele. No meu exemplo, vai se chamar "time-series-graph.yaml", em referência ao dashboard customizado mostrado acima. Agora dá para começar a ajustar o template. Primeiro, removemos o comentário no início do arquivo — esta 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
*/ -}}

Em seguida, atualizamos o nome do nosso ConfigMap em alguns pontos — primeiro aqui:

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 "-" }}

Vou trocar "alertmanager-overview", de onde copiamos o template originalmente, por "time-series-graphs", para bater com o nome do meu dashboard e do arquivo 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 "-" }}

Depois, alteramos o nome da seção de dados do template do configmap, conforme abaixo:

data:
alertmanager-overview.json: |-

para

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

Em seguida, substituímos o JSON do dashboard existente pelo JSON que copiamos das configurações do dashboard do Grafana, exatamente abaixo desta linha, conforme o exemplo, lembrando de indentar todo o JSON com pelo menos 1 tab:

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

Gerando os templates renderizados do Helm\

Agora que adicionamos o arquivo yaml do template Helm de configmap do dashboard, vamos conferir quais manifests yaml são gerados pelo Helm chart e validar se o ConfigMap do nosso dashboard foi criado corretamente:
\

# Adicione ao Helm os repositórios dos charts que vamos usar\
$ Helm repo add grafana https://grafana.github.io/Helm-charts\
\
$ Helm repo add prometheus-community https://prometheus-community.github.io/Helm-charts\
\
# Baixe todas as dependências dos charts e atualize\
$ Helm dependency build\
\
$ Helm repo update\
```\
\
Agora podemos executar o comando Helm template para renderizar os manifests yaml a partir dos nossos templates Helm e salvá-los em arquivo para conferir depois. Usamos a flag —validate para checar se os manifests yaml do Kubernetes são válidos no contexto atual do cluster Kubernetes:\
\
```\
$ Helm template kube-prometheus-stack . --validate > rendered-template.yaml\
```\
\
Na sequência, inspecionamos o arquivo rendered-template.yaml para confirmar que o ConfigMap foi criado e será aplicado quando rodarmos o comando Helm install na próxima etapa:\
\
```\
$ 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",\
```\
\
Uma busca rápida por "time-series" no arquivo mostra que o ConfigMap foi criado e que os dados contêm o JSON do dashboard que adicionamos antes.\
\
Por fim, aplicamos o Helm chart no cluster Kubernetes e, assim que o Grafana sobe, conseguimos confirmar que o dashboard está lá:\
\
```\
$ Helm install kube-prometheus-stack .\
```\
\
![graphana-dashboards](https://media.doit.com/imports/wordpress/2022/04/f4aa0c1fd59e-graphana-dashboards.jpg)\
\

Posts relacionados\

amazon bedrock pricing
\

Preços do Amazon Bedrock: um guia de CloudOps para gerenciar custos de IA\

O Amazon Bedrock cobra por token de entrada e saída processado, com custos que variam conforme o modelo, o modo de cobrança e o workload

databricks pricing explained
\

Preços do Databricks explicados: DBUs, planos e controle de custos\

O Databricks cobra pelo compute em Databricks Units (DBUs), faturadas por segundo, além de uma fatura separada do seu

cloud infrastructure
\

O que são serviços de infraestrutura em nuvem? Um guia de CloudOps\

Os serviços de infraestrutura em nuvem — compute, storage e rede — são a base operacional que toda equipe de CloudOps gerencia. Escolher o

Buscar

Buscar
\

Agende uma conversa com nosso time\

Selecione uma regiãoAmericasEMEAAPACVocê verá opções de data e horário na próxima etapa