Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Cómo agregar dashboards personalizados de Grafana en código con el Helm chart de Kube-Prometheus-Stack

By Abrar AliApr 11, 20225 min read

Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.

Con este enfoque, tus dashboards se conservan aunque redespliegues Grafana o lo lleves a otro entorno o cluster.

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

Con este enfoque, tus dashboards se conservan aunque redespliegues Grafana o lo lleves a otro entorno o cluster

Prometheus se ha convertido en la herramienta de monitoreo de facto y, junto con Grafana y Alertmanager, conforma el stack completo de observabilidad y alertas en muchas organizaciones.

Sin embargo, gestionar y desplegar cada uno de estos componentes por separado resulta engorroso y conlleva el riesgo de que se desincronicen a medida que cambia la infraestructura. Con la llegada del Helm chart kube-prometheus-stack, mantenido por la prometheus-community, puedes centralizar de forma ordenada la configuración de las tres herramientas en un único archivo Helm values. En este post te mostramos cómo agregamos dashboards de Grafana dentro del Helm chart, para que tus dashboards se conserven incluso si redespliegas Grafana o lo llevas a otro entorno o cluster.

Requisitos previos

Lo primero es clonar el repositorio que contiene el Helm chart de kube-prometheus-stack, ya que no es posible guardar nuestros dashboards personalizados en código si descargamos y aplicamos el chart de forma remota; solo se pueden agregar si aplicamos el chart desde una copia local del código. También necesitamos las siguientes herramientas instaladas en nuestras estaciones de trabajo:

  • Git
  • Helm
  • Kubectl
  • El IDE de tu preferencia
$ git clone https://github.com/prometheus-community/helm-charts.git
$ cd helm-charts/charts/kube-prometheus-stack

Una vez dentro de la carpeta de charts, vamos a la carpeta de dashboards de Grafana, donde están todos los dashboards predeterminados que vienen listos para usar.

$ 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 ves, la instalación de Grafana incluye varios dashboards. Estos se aplican desde este directorio mediante los templates de configmaps que contiene.

Exportar nuestro dashboard personalizado

Una vez creado y guardado el dashboard personalizado en Grafana, necesitamos exportar el JSON que usaremos para agregarlo a nuestro configmap en el siguiente paso. Haz clic en el ícono de configuración del dashboard y selecciona "JSON Model" en el panel izquierdo. Allí podemos copiar el JSON y guardarlo para más tarde:

graphana-dashboards

kube-prometheus

Agregar nuestro dashboard personalizado

Ahora podemos agregar nuestro propio template de Helm para el configmap dentro de la carpeta de dashboards. Lo más sencillo es duplicar uno de los archivos yaml existentes en esa carpeta, renombrarlo con el nombre de tu dashboard y pegarle el JSON. En mi ejemplo, se llamará "time-series-graph.yaml", en línea con el dashboard personalizado anterior. Ya podemos empezar a modificar el template. Primero, eliminamos el comentario al inicio del archivo, 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
*/ -}}

Luego actualizamos el nombre de nuestro ConfigMap en un par de lugares; primero aquí:

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

Voy a cambiar "alertmanager-overview", de donde copiamos el template originalmente, por "time-series-graphs" para que coincida con el nombre de mi dashboard y de mi archivo 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 "-" }}

A continuación, cambiamos el nombre de la sección de datos del template del configmap, así:

data:
alertmanager-overview.json: |-

por

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

Después, reemplazamos el JSON del dashboard existente por el JSON que copiamos directamente desde la configuración del dashboard de Grafana, justo debajo de esta línea, como se muestra abajo, asegurándonos de indentar todo el JSON con al menos 1 tabulación:

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

Generar los templates renderizados de Helm\

Ya que agregamos el archivo yaml con el template de Helm para el configmap del dashboard, revisamos qué manifiestos yaml se generan a partir del Helm chart para verificar que el ConfigMap de nuestro dashboard se haya creado correctamente:
\

# Agregar los repos a Helm para los charts que necesitamos\
$ Helm repo add grafana https://grafana.github.io/Helm-charts\
\
$ Helm repo add prometheus-community https://prometheus-community.github.io/Helm-charts\
\
# Descargar todas las dependencias de los charts y actualizar\
$ Helm dependency build\
\
$ Helm repo update\
```\
\
Ahora podemos ejecutar el comando Helm template para renderizar los manifiestos yaml a partir de nuestros templates de Helm y guardarlos en un archivo para revisarlos después. Usamos el flag —validate para comprobar que tenemos manifiestos yaml válidos para Kubernetes contra el contexto actual del cluster de Kubernetes:\
\
```\
$ Helm template kube-prometheus-stack . --validate > rendered-template.yaml\
```\
\
Luego revisamos el archivo rendered-template.yaml para verificar que nuestro ConfigMap se haya creado y se aplique cuando ejecutemos el comando Helm install en el siguiente paso:\
\
```\
$ 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 búsqueda rápida de "time-series" en el archivo confirma que nuestro ConfigMap se creó y que los datos contienen el JSON del dashboard que agregamos antes.\
\
Por último, aplicamos el Helm chart a nuestro cluster de Kubernetes y, una vez que Grafana esté en marcha, podemos verificar que el dashboard exista:\
\
```\
$ Helm install kube-prometheus-stack .\
```\
\
![graphana-dashboards](https://media.doit.com/imports/wordpress/2022/04/f4aa0c1fd59e-graphana-dashboards.jpg)\
\

Blogs relacionados\

amazon bedrock pricing
\

Precios de Amazon Bedrock: guía CloudOps para gestionar los costos de IA\

Amazon Bedrock cobra por cada token de entrada y salida procesado, con costos que varían según el modelo, el modo de Precios y el workload

databricks pricing explained
\

Precios de Databricks explicados: DBUs, planes y control de costos\

Databricks cobra el cómputo en Databricks Units (DBUs), facturadas por segundo, además de una factura aparte de tu

cloud infrastructure
\

¿Qué son los servicios de infraestructura en la nube? Una guía CloudOps\

Los servicios de infraestructura en la nube —cómputo, almacenamiento y red— son la base operativa que gestiona todo equipo de CloudOps. Elegir los adecuados

Buscar

Buscar
\

Agenda una llamada con nuestro equipo\

Selecciona una regiónAmericasEMEAAPACEn el siguiente paso se mostrarán las opciones de fecha y hora