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

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-stackJá 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/$ lsalertmanager-overview.yaml grafana-overview.yamlk8s-resources-pod.yaml namespace-by-workload.yamlpod-total.yaml statefulset.yamlapiserver.yaml k8s-coredns.yamlk8s-resources-workload.yaml node-cluster-rsrc-use.yamlComo 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:

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.yamlDo 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: v1kind: ConfigMapmetadata: 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: v1kind: ConfigMapmetadata: 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 .\
```\
\
\
\
Posts relacionados\
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
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
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



