Conceptos de dashboards¶

Un dashboard es una interfaz visual que reúne información relevante para facilitar la supervisión y el análisis de un sistema.

En Grafana, un dashboard se construye combinando paneles, consultas, visualizaciones, variables, rangos temporales, unidades y umbrales.

El objetivo no es mostrar el mayor número posible de métricas, sino presentar la información necesaria de forma clara y útil.

Objetivos¶

Al finalizar esta sección, el alumno podrá:

Explicar qué es un dashboard.
Diferenciar entre dashboard, panel, consulta y visualización.
Identificar los componentes principales de un dashboard.
Seleccionar una visualización adecuada para cada tipo de dato.
Configurar títulos, descripciones, unidades y leyendas.
Utilizar rangos temporales.
Configurar umbrales y colores.
Interpretar correctamente los valores mostrados.
Diseñar dashboards claros y fáciles de utilizar.
Identificar errores habituales de diseño.
Crear un dashboard básico con métricas de Prometheus y Node Exporter.

Introducción¶

Grafana permite convertir métricas almacenadas en fuentes de datos como Prometheus en representaciones visuales.

El flujo general es:

Fuente de datos
      |
      v
Consulta
      |
      v
Resultado
      |
      v
Visualización
      |
      v
Panel
      |
      v
Dashboard

Por ejemplo:

Prometheus
      |
      v
Consulta PromQL: up
      |
      v
Resultado: 1 o 0
      |
      v
Panel Stat
      |
      v
Estado de los objetivos

Un dashboard bien diseñado debe ayudar a responder preguntas operativas:

¿El sistema está disponible?
¿Hay algún objetivo caído?
¿Qué servidor consume más CPU?
¿La memoria está cerca del límite?
¿Cuánto espacio queda en disco?
¿Desde cuándo se produce el problema?
¿El problema afecta a un único servidor o a varios?

Un dashboard no debe ser una colección desordenada de gráficos. Cada panel debe tener un propósito concreto.

Componentes de un dashboard¶

Dashboard¶

El dashboard es el contenedor principal.

Puede incluir:

Paneles.
Consultas.
Variables.
Rangos temporales.
Enlaces.
Anotaciones.
Descripciones.
Configuración de actualización.
Permisos.

Ejemplo de nombre:

Monitorización de servidores Linux

Panel¶

Un panel es una unidad visual dentro del dashboard.

Ejemplos:

Estado de los objetivos.
Uso de CPU.
Uso de memoria.
Espacio utilizado.
Tráfico de red.
Carga del sistema.

Cada panel puede tener:

Una o varias consultas.
Una visualización.
Un título.
Una descripción.
Una unidad.
Umbrales.
Una leyenda.
Transformaciones.

Consulta¶

La consulta obtiene datos desde la fuente configurada.

Ejemplo:

up

Esta consulta devuelve el estado de los objetivos monitorizados por Prometheus.

Otro ejemplo:

node_load1

Esta consulta devuelve la carga del sistema durante el último minuto.

Visualización¶

La visualización define cómo se muestran los datos.

Algunas visualizaciones habituales son:

Visualización	Uso recomendado
Stat	Mostrar un valor resumido
Gauge	Mostrar un valor frente a un rango
Bar Gauge	Comparar varios valores
Time series	Mostrar evolución temporal
Table	Mostrar datos tabulares
Heatmap	Mostrar distribuciones
Text	Añadir documentación
Canvas	Crear diseños personalizados

Fuente de datos¶

La fuente de datos es el sistema desde el que Grafana obtiene la información.

En este curso se utilizará principalmente:

Prometheus

URL habitual:

http://localhost:9090

La fuente de datos debe estar configurada antes de crear paneles con métricas.

Rango temporal¶

El rango temporal determina qué periodo se consulta.

Ejemplos:

Last 5 minutes
Last 15 minutes
Last 1 hour
Last 6 hours
Last 24 hours
Last 7 days

Un gráfico puede parecer vacío porque el rango temporal no contiene datos.

Unidad¶

La unidad indica cómo debe interpretarse un valor.

Ejemplos:

Métrica	Unidad recomendada
Uso de CPU	Percent (0-100)
Uso de memoria	Percent (0-100)
Memoria disponible	Bytes
Tráfico de red	Bytes/sec
Duración	Seconds
Temperatura	Celsius
Disponibilidad	None o Percent

Umbral¶

Un umbral define los límites entre distintos estados.

Ejemplo para el uso de memoria:

0 - 70 %: normal
70 - 90 %: advertencia
90 - 100 %: crítico

Los umbrales suelen representarse mediante colores:

Verde    Estado normal
Amarillo Advertencia
Rojo     Estado crítico

Leyenda¶

La leyenda identifica las series representadas en un panel.

Una leyenda puede mostrar:

Instancia.
Job.
Interfaz de red.
Punto de montaje.
Nombre de la métrica.
Valor actual.
Valor mínimo.
Valor máximo.
Promedio.

Una leyenda mal configurada puede dificultar la interpretación del gráfico.

Diferencia entre métrica, consulta y panel¶

Estos conceptos están relacionados, pero no son equivalentes.

Métrica:
node_memory_MemAvailable_bytes

Consulta:
100 * (
  1 -
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

Panel:
Uso de memoria

Visualización:
Gauge

La métrica es el dato original.

La consulta puede transformar o calcular un valor nuevo.

El panel contiene la consulta y muestra el resultado.

La visualización determina la forma en que se presenta.

Tipos de información¶

Valores individuales¶

Son valores que representan una situación actual.

Ejemplos:

Objetivos disponibles.
Porcentaje actual de memoria.
Número de alertas.
Estado de un servicio.

Visualizaciones apropiadas:

Stat
Gauge

Consulta de ejemplo:

sum(up)

Evolución temporal¶

Representa cómo cambia una métrica durante un periodo.

Ejemplos:

CPU durante la última hora.
Memoria durante las últimas seis horas.
Tráfico de red.
Carga del sistema.

Visualización apropiada:

Time series

Consulta de ejemplo:

node_load1

Comparación entre elementos¶

Permite comparar varias instancias, interfaces o sistemas de ficheros.

Ejemplos:

CPU por servidor.
Memoria por instancia.
Tráfico por interfaz.
Uso de disco por punto de montaje.

Visualizaciones apropiadas:

Bar Gauge
Table
Time series

Consulta de ejemplo:

100 - (
  avg by (instance) (
    rate(node_cpu_seconds_total{mode="idle"}[5m])
  ) * 100
)

Datos tabulares¶

Muestran filas y columnas con etiquetas y valores.

Visualización apropiada:

Table

Consulta de ejemplo:

up

Principios de diseño¶

Mostrar primero la información importante¶

La parte superior del dashboard debe contener la información más relevante:

Disponibilidad.
Estado general.
Recursos críticos.
Problemas activos.
Detalle operativo.

Ejemplo:

+------------------------------------------------------+
| Estado general y disponibilidad                      |
+----------------------+-------------------------------+
| Uso de CPU           | Uso de memoria                |
+----------------------+-------------------------------+
| Uso de almacenamiento| Carga del sistema             |
+----------------------+-------------------------------+
| Tráfico de red       | Información del sistema      |
+----------------------+-------------------------------+

Utilizar títulos descriptivos¶

Evitar:

Panel 1
Panel 2
Consulta A

Utilizar:

Uso de CPU por instancia
Memoria utilizada
Estado de los objetivos
Espacio utilizado en /

Utilizar unidades adecuadas¶

Un valor como:

7340032000

es difícil de interpretar.

Con una unidad adecuada puede mostrarse como:

6.84 GiB

La unidad no modifica el dato. Solo mejora su representación.

Mantener una convención de colores¶

Utilizar colores consistentes:

Verde: estado normal
Amarillo: advertencia
Rojo: estado crítico
Gris: sin datos o no aplicable

No se deben utilizar colores sin significado claro.

Evitar la saturación de información¶

Un dashboard con demasiados paneles puede ser difícil de interpretar.

Es preferible:

Utilizar menos paneles.
Agrupar información relacionada.
Ocultar detalles poco importantes.
Crear dashboards especializados.
Utilizar variables para cambiar el contexto.

Añadir contexto¶

Un panel de texto puede explicar:

Qué se está monitorizando.
Qué significa cada color.
Qué fuente de datos se utiliza.
Qué rango temporal es recomendable.
Qué hacer cuando aparece un valor crítico.

Ejemplos de consultas PromQL¶

Estado de los objetivos¶

up

Interpretación:

1 = objetivo disponible
0 = objetivo no disponible

Número de objetivos disponibles¶

sum(up)

Porcentaje de disponibilidad¶

100 * avg(up)

Uso de CPU¶

100 - (
  avg by (instance) (
    rate(node_cpu_seconds_total{mode="idle"}[5m])
  ) * 100
)

La consulta calcula el porcentaje de tiempo que no está en modo inactivo.

Uso de memoria¶

100 * (
  1 -
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

Uso del sistema de ficheros raíz¶

100 * (
  1 -
  node_filesystem_avail_bytes{
    mountpoint="/",
    fstype!~"tmpfs|overlay"
  }
  /
  node_filesystem_size_bytes{
    mountpoint="/",
    fstype!~"tmpfs|overlay"
  }
)

Carga del sistema¶

node_load1

Tráfico recibido¶

sum by (instance) (
  rate(node_network_receive_bytes_total{
    device!="lo"
  }[5m])
)

Tráfico enviado¶

sum by (instance) (
  rate(node_network_transmit_bytes_total{
    device!="lo"
  }[5m])
)

Ejemplo de diseño¶

Objetivo¶

Crear un dashboard llamado:

Monitorización de servidor Linux

El dashboard tendrá los siguientes paneles:

Orden	Panel	Visualización
1	Descripción	Text
2	Estado de los objetivos	Table
3	Uso de CPU	Time series
4	Uso de memoria	Gauge
5	Uso del sistema de ficheros	Gauge
6	Carga del sistema	Time series
7	Tráfico recibido	Time series

Distribución propuesta¶

+------------------------------------------------------+
| Descripción del dashboard                            |
+------------------------------------------------------+
| Estado de los objetivos                              |
+----------------------+-------------------------------+
| Uso de CPU           | Uso de memoria                |
+----------------------+-------------------------------+
| Uso de filesystem    | Carga del sistema             |
+----------------------+-------------------------------+
| Tráfico recibido     | Tráfico enviado               |
+----------------------+-------------------------------+

Panel de descripción¶

Contenido:

## Monitorización de servidor Linux

Este dashboard muestra el estado y el uso de recursos del servidor.

## Métricas incluidas

- Disponibilidad de los objetivos.
- Uso de CPU.
- Uso de memoria.
- Uso del sistema de ficheros.
- Carga del sistema.
- Tráfico de red.

## Colores

- Verde: estado normal.
- Amarillo: advertencia.
- Rojo: situación crítica.

## Fuente de datos

Prometheus.

Ejemplo de sesión 1: comprobar el entorno¶

Objetivo¶

Comprobar que los servicios necesarios están activos antes de trabajar con Grafana.

Comandos¶

systemctl is-active prometheus

systemctl is-active node_exporter

systemctl is-active grafana-server

curl http://localhost:9090/-/healthy

curl -I http://localhost:9100/metrics

curl -s http://localhost:3000/api/health | jq

Resultado esperado¶

active
active
active
Prometheus is Healthy.
HTTP/1.1 200 OK

La API de Grafana debe devolver un resultado con la base de datos en estado:

{
  "database": "ok"
}

Actividades¶

Comprueba el estado de los servicios.
Anota el resultado de cada comando.
Comprueba que Prometheus responde.
Comprueba que Node Exporter expone métricas.
Comprueba que Grafana responde.
Accede a Grafana desde el navegador.

Ejemplo de sesión 2: comprobar la fuente de datos¶

Objetivo¶

Comprobar que Grafana tiene configurada una fuente de datos Prometheus.

Pasos¶

Acceder a:

http://localhost:3000

Ir a:

Connections → Data sources

Seleccionar la fuente Prometheus.
Revisar la URL configurada.
Pulsar Save & test.

La URL habitual será:

http://localhost:9090

Actividades¶

Anota el nombre de la fuente.
Anota la URL.
Comprueba si está configurada como predeterminada.
Comprueba que la prueba de conexión es correcta.
Explica por qué Grafana necesita una fuente de datos.

Ejemplo de sesión 3: crear un dashboard básico¶

Objetivo¶

Crear un dashboard con un panel de disponibilidad.

Pasos¶

Ir a Dashboards.
Crear un dashboard nuevo.
Añadir un panel.
Seleccionar Prometheus.
Introducir la consulta:

up

Seleccionar la visualización:

Table

Configurar el título:

Estado de los objetivos

Guardar el panel.
Guardar el dashboard con el nombre:

Monitorización de servidor Linux

Actividades¶

Comprueba cuántos objetivos aparecen.
Identifica el job de Prometheus.
Identifica el job de Node Exporter.
Comprueba sus valores.
Explica el significado de cada valor.
Guarda una captura del panel.

Ejemplo de sesión 4: comparar visualizaciones¶

Objetivo¶

Comprobar que la misma consulta puede representarse mediante distintas visualizaciones.

Utilizar la consulta:

up

Probar las visualizaciones:

Table
Stat
Gauge
Bar Gauge
Time series

Actividades¶

Para cada visualización, responder:

¿Se entiende correctamente el resultado?
¿Es adecuada para esta consulta?
¿Qué información muestra mejor?
¿Qué información se pierde?
¿En qué situación utilizarías esa visualización?

Resultado esperado¶

La visualización Table suele ser adecuada para identificar los objetivos y sus etiquetas.

La visualización Stat puede ser adecuada para mostrar el número total de objetivos disponibles:

sum(up)

La visualización Gauge puede utilizarse para mostrar el porcentaje de disponibilidad:

100 * avg(up)

Ejemplo de sesión 5: configurar unidades y umbrales¶

Objetivo¶

Mostrar el uso de memoria como porcentaje y aplicar colores según su valor.

Consulta¶

100 * (
  1 -
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

Visualización¶

Gauge

Unidad¶

Percent (0-100)

Umbrales¶

0     Verde
70    Amarillo
90    Rojo

Actividades¶

Crea el panel.
Introduce la consulta.
Selecciona Gauge.
Configura la unidad.
Configura los umbrales.
Añade el título:

Uso de memoria

Añade una descripción:

Porcentaje de memoria utilizada en el servidor monitorizado.

Comprueba el color actual.
Explica qué ocurriría al superar el 90 %.

Ejemplo de sesión 6: crear un panel temporal¶

Objetivo¶

Representar la evolución del uso de CPU.

Consulta¶

100 - (
  avg by (instance) (
    rate(node_cpu_seconds_total{mode="idle"}[5m])
  ) * 100
)

Configuración¶

Visualización: Time series
Unidad: Percent (0-100)
Título: Uso de CPU
Rango temporal: Last 1 hour

Actividades¶

Crea el panel.
Ejecuta la consulta.
Cambia el rango temporal.
Comprueba la leyenda.
Configura la unidad.
Genera carga temporal:

yes > /dev/null &

Observa el gráfico.
Detén el proceso:

pkill yes

Observa la recuperación.
Explica por qué se utiliza rate().

Ejemplo de sesión 7: organizar un dashboard¶

Objetivo¶

Crear una organización visual clara.

Utilizar los siguientes paneles:

Estado de los objetivos
Uso de CPU
Uso de memoria
Uso del sistema de ficheros
Carga del sistema
Tráfico recibido
Tráfico enviado
Descripción

Actividades¶

Coloca la descripción en la parte superior.
Coloca la disponibilidad debajo de la descripción.
Agrupa CPU y memoria.
Agrupa almacenamiento y carga.
Coloca la red en la parte inferior.
Ajusta el tamaño de los paneles.
Evita que los títulos queden cortados.
Comprueba que el dashboard se entiende sin abrir los paneles.
Guarda los cambios.

Ejemplo de sesión 8: comprobar un problema de datos¶

Objetivo¶

Diferenciar entre un problema de Grafana, un problema de Prometheus y un problema de Node Exporter.

Detener Node Exporter¶

sudo systemctl stop node_exporter

Esperar más de un intervalo de scraping.

Consultar el estado¶

up{job="node_exporter"}

Resultado esperado:

Consultar el objetivo mediante la API¶

curl -s http://localhost:9090/api/v1/targets \
  | jq -r '
    .data.activeTargets[]
    | select(.labels.job == "node_exporter")
    | [
        .labels.instance,
        .health,
        .lastError
      ]
    | @tsv
  '

Recuperar el servicio¶

sudo systemctl start node_exporter

Esperar al siguiente scraping y volver a consultar:

up{job="node_exporter"}

Resultado esperado:

Actividades¶

Anota el estado inicial.
Detén Node Exporter.
Comprueba cuándo aparece DOWN.
Consulta el error.
Inicia el servicio.
Comprueba la recuperación.
Explica qué paneles dejan de mostrar datos actuales.
Explica por qué pueden continuar apareciendo datos históricos.

Ejemplo de sesión 9: aplicar una transformación¶

Objetivo¶

Mostrar en una tabla únicamente la información relevante.

Consulta¶

up

Pasos¶

Crear un panel de tipo Table.
Ejecutar la consulta.
Abrir la sección Transformations.
Ocultar columnas innecesarias.
Mantener:

job
instance
Value

Renombrar Value como:

Estado

Ordenar por job.
Guardar el panel.

Actividades¶

Compara el resultado antes y después de la transformación.
Explica qué columnas se han ocultado.
Explica por qué una transformación puede mejorar la legibilidad.
Comprueba que la transformación no elimina los datos originales de Prometheus.

Buenas prácticas¶

Utilizar nombres consistentes¶

Usar nombres claros y homogéneos:

Uso de CPU
Uso de memoria
Uso del sistema de ficheros
Carga del sistema
Tráfico recibido
Tráfico enviado

Configurar descripciones¶

Una descripción debe explicar:

Qué representa el panel.
Qué unidad utiliza.
Qué periodo se consulta.
Qué significa un valor elevado.
Qué acción debe realizarse.

Evitar consultas innecesariamente complejas¶

Una consulta debe ser suficientemente clara para que otro administrador pueda mantenerla.

Usar agregaciones cuando sea necesario¶

Si una consulta devuelve demasiadas series, utilizar una agregación.

Ejemplo:

sum by (instance) (
  rate(node_network_receive_bytes_total{
    device!="lo"
  }[5m])
)

Filtrar datos irrelevantes¶

Excluir interfaces o sistemas de ficheros que no aporten información útil:

device!="lo"

fstype!~"tmpfs|overlay"

Utilizar rangos temporales apropiados¶

Para observar actividad reciente:

Last 15 minutes

Para analizar tendencias:

Last 24 hours

Para estudiar cambios históricos:

Last 7 days

Diseñar para la acción¶

Cada panel debe ayudar a:

Detectar un problema.
Comprender el problema.
Comparar el problema.
Decidir una acción.

Errores habituales¶

Mostrar un valor sin unidad¶

Un valor como:

0.734

puede ser ambiguo.

Debe aclararse si representa:

Una proporción.
Un porcentaje.
Segundos.
Bytes.
Bytes por segundo.

Usar una visualización inadecuada¶

Un Gauge no suele ser la mejor opción para representar una evolución temporal.

Un Time series no siempre es la mejor opción para mostrar un único valor actual.

Mostrar demasiadas series¶

Un gráfico con cientos de series puede resultar ilegible.

En ese caso:

Filtrar.
Agrupar.
Utilizar una tabla.
Separar el dashboard.
Añadir variables.

No documentar los colores¶

El usuario debe conocer el significado de cada color.

Colocar todos los paneles al mismo nivel¶

La distribución debe reflejar la importancia de la información.

No probar los casos de error¶

Un dashboard debe probarse cuando:

El objetivo está disponible.
El objetivo está caído.
No hay datos.
La consulta es incorrecta.
La fuente de datos no responde.

Puntos clave¶

Un dashboard agrupa información relacionada.
Un panel es una visualización individual.
Una consulta obtiene o calcula los datos.
La visualización determina cómo se representan los datos.
La fuente de datos proporciona la información a Grafana.
Los paneles deben tener títulos descriptivos.
Las unidades deben corresponder al significado de los datos.
Los umbrales permiten comunicar estados.
Los colores deben utilizarse con un significado coherente.
La información más importante debe aparecer en la parte superior.
Un dashboard debe ser claro, legible y accionable.
La consulta up es una comprobación inicial fundamental.
rate() permite calcular velocidades de cambio a partir de contadores.
Las transformaciones modifican la presentación del resultado, no la métrica original.
Los rangos temporales influyen directamente en los datos visibles.
Un panel sin datos requiere comprobar la consulta, la fuente y los objetivos.
Un dashboard debe probarse tanto en situaciones normales como de error.
La documentación forma parte del diseño técnico del dashboard.

Preguntas de comprobación¶

¿Qué es un dashboard?
¿Qué diferencia existe entre un dashboard y un panel?
¿Qué función cumple una fuente de datos?
¿Qué función cumple una consulta?
¿Qué función cumple una visualización?
¿Para qué utilizarías un panel Stat?
¿Para qué utilizarías un panel Gauge?
¿Para qué utilizarías un panel Time series?
¿Para qué utilizarías un panel Table?
¿Qué significa el valor 1 en la consulta up?
¿Qué significa el valor 0 en la consulta up?
¿Qué unidad utilizarías para mostrar el uso de CPU?
¿Qué unidad utilizarías para mostrar el tráfico de red?
¿Qué función cumplen los umbrales?
¿Qué significado pueden tener los colores verde, amarillo y rojo?
¿Por qué es importante utilizar títulos descriptivos?
¿Qué problema puede producir un rango temporal incorrecto?
¿Por qué puede ser necesario utilizar una agregación?
¿Qué función cumple una transformación?
¿Qué comprobarías si un panel no muestra datos?
¿Qué consulta utilizarías para comprobar la disponibilidad?
¿Qué consulta utilizarías para mostrar la carga del sistema?
¿Por qué se utiliza rate() en la consulta de CPU?
¿Qué paneles colocarías en la parte superior de un dashboard?
¿Qué características debe tener un dashboard bien diseñado?

Resultado esperado¶

Al finalizar esta sección, el alumno debe ser capaz de diseñar un dashboard básico siguiendo este proceso:

Definir el objetivo
        |
        v
Seleccionar las métricas
        |
        v
Crear las consultas
        |
        v
Elegir las visualizaciones
        |
        v
Configurar unidades y umbrales
        |
        v
Organizar los paneles
        |
        v
Añadir documentación
        |
        v
Probar datos normales y errores
        |
        v
Guardar y revisar el dashboard

El resultado debe ser un dashboard que permita comprender rápidamente el estado del sistema sin necesidad de inspeccionar manualmente cada métrica.