Laboratorio - Anotaciones y alertas¶

Este laboratorio integra los conceptos estudiados en el módulo de anotaciones y alertas de Grafana.

Durante la práctica, el alumno creará reglas de alerta, registrará eventos mediante anotaciones, configurará notificaciones, utilizará silenciamientos y comprobará el ciclo completo de una incidencia:

Métrica
   |
   v
Consulta PromQL
   |
   v
Regla de alerta
   |
   v
Evaluación
   |
   v
Pending
   |
   v
Alerting
   |
   v
Notificación
   |
   v
Investigación
   |
   v
Recuperación
   |
   v
Normal

El laboratorio está diseñado para realizarse en un entorno controlado. Las acciones que detienen servicios o generan carga deben ejecutarse únicamente sobre máquinas de prácticas autorizadas.

Objetivos¶

Al finalizar este laboratorio, el alumno podrá:

Verificar el estado de un entorno Grafana y Prometheus.
Validar consultas PromQL en Explore.
Crear reglas de alerta para disponibilidad, CPU, memoria y almacenamiento.
Configurar expresiones, reducciones, umbrales y duraciones.
Añadir etiquetas y anotaciones descriptivas.
Crear anotaciones manuales sobre un dashboard.
Consultar el historial de estados de una alerta.
Crear contactos de notificación.
Configurar políticas de notificación.
Comprobar el envío de alertas a un canal autorizado.
Probar notificaciones de activación y recuperación.
Crear silenciamientos temporales.
Comprobar el alcance de un silenciamiento.
Diagnosticar reglas que no se activan.
Diagnosticar alertas en estado No data.
Revisar alertas desde la lista de alertas.
Correlacionar cambios operativos con métricas y alertas.
Documentar todas las pruebas realizadas.
Elaborar un informe final de la práctica.

Introducción¶

La observabilidad no consiste únicamente en mostrar gráficos. Una plataforma útil debe ayudar a responder preguntas como:

¿Qué está ocurriendo?

¿Cuándo comenzó?

¿Qué servicio está afectado?

¿La situación es nueva o recurrente?

¿Hubo un despliegue antes del problema?

¿Se envió una notificación?

¿Se trata de un problema real o de ruido?

¿Cuándo se resolvió?

En este laboratorio se utilizarán tres elementos principales:

Alertas¶

Detectan situaciones anómalas mediante reglas basadas en métricas.

Ejemplo:

Si la CPU supera el 90 % durante cinco minutos,
activar una alerta.

Anotaciones¶

Registran acontecimientos operativos en una línea temporal.

Ejemplos:

Despliegue de una nueva versión.
Inicio de una prueba de carga.
Mantenimiento programado.
Rollback de una aplicación.

Notificaciones¶

Informan al equipo responsable cuando una alerta cambia de estado.

Ejemplo:

[FIRING] HighCPUUsage en server-01

La combinación de estos elementos permite construir una línea temporal completa:

18:00 - Despliegue de una aplicación
18:03 - Aumento de la latencia
18:05 - Alerta de latencia en Pending
18:10 - Alerta en Alerting
18:11 - Notificación enviada
18:15 - Rollback
18:18 - Alerta resuelta

Escenario del laboratorio¶

El laboratorio utilizará un servidor de prácticas supervisado por Prometheus y visualizado en Grafana.

Componentes¶

Node Exporter
    |
    v
Prometheus
    |
    v
Grafana
    |
    v
Alertas y notificaciones

Servicios esperados¶

Componente	Función
Node Exporter	Expone métricas del sistema
Prometheus	Recopila y almacena métricas
Grafana	Visualiza métricas y gestiona alertas
Contacto de notificación	Recibe los avisos
Dashboard	Muestra el estado del sistema

Los nombres de servicios, puertos y rutas pueden variar según el entorno de formación.

Requisitos previos¶

Antes de comenzar, el alumno debe disponer de:

Acceso a Grafana.
Permisos para consultar dashboards.
Permisos para crear reglas de alerta.
Permisos para crear anotaciones.
Permisos para crear contactos de laboratorio.
Acceso a Prometheus desde Grafana.
Node Exporter instalado o una fuente de métricas equivalente.
Un contacto de correo, webhook o canal de laboratorio.
Una máquina de prácticas autorizada.
Acceso a una terminal, si se realizarán pruebas de servicio o carga.

Comprobar la versión¶

Desde Grafana:

Acceder al menú de ayuda.
Consultar la información de la instancia.
Registrar la versión utilizada.

Versión de Grafana:

Versión de Prometheus:

Sistema operativo:

Fecha de la práctica:

Alumno:

Grupo:

La interfaz puede presentar diferencias según la versión instalada.

Reglas de seguridad¶

Este laboratorio debe realizarse únicamente en un entorno autorizado.

No ejecutar sobre producción¶

No detener servicios ni generar carga en sistemas reales.

Incorrecto:

sudo systemctl stop node_exporter

sobre un servidor de producción.

Correcto:

Ejecutar la acción únicamente en la máquina de laboratorio asignada.

No utilizar credenciales reales¶

No incluir en la documentación:

Contraseñas
Tokens
Claves API
Secretos SMTP
URLs con credenciales
Cabeceras de autenticación

No crear notificaciones reales sin autorización¶

Utilizar:

Direcciones de laboratorio.
Contactos de formación.
Webhooks de prueba.
Canales controlados.
Sistemas ITSM de laboratorio.

No automatizar acciones destructivas¶

El laboratorio no debe ejecutar acciones como:

Borrar archivos automáticamente.
Reiniciar servidores de producción.
Modificar reglas de firewall.
Detener bases de datos.
Eliminar recursos.

Estructura de evidencias¶

Crear un directorio de trabajo:

mkdir -p ~/laboratorio-grafana/evidencias/laboratorio-integrador

Crear subdirectorios:

mkdir -p ~/laboratorio-grafana/evidencias/laboratorio-integrador/consultas
mkdir -p ~/laboratorio-grafana/evidencias/laboratorio-integrador/reglas
mkdir -p ~/laboratorio-grafana/evidencias/laboratorio-integrador/anotaciones
mkdir -p ~/laboratorio-grafana/evidencias/laboratorio-integrador/notificaciones
mkdir -p ~/laboratorio-grafana/evidencias/laboratorio-integrador/silencios
mkdir -p ~/laboratorio-grafana/evidencias/laboratorio-integrador/informe

Crear un registro general:

cat > ~/laboratorio-grafana/evidencias/laboratorio-integrador/registro-general.txt <<'EOF'
Alumno:

Grupo:

Fecha:

Versión de Grafana:

Versión de Prometheus:

Entorno:

Host de laboratorio:

Reglas creadas:

Anotaciones creadas:

Contacto utilizado:

Política utilizada:

Silencio creado:

Problemas encontrados:

Resultado final:

Firma o validación del instructor:
EOF

Fase 1: comprobar el entorno¶

Objetivo¶

Verificar que Grafana, Prometheus y Node Exporter funcionan antes de crear reglas.

Comprobar Node Exporter¶

En la máquina de laboratorio:

sudo systemctl status node_exporter

Si el servicio utiliza otro nombre, consultar el procedimiento del entorno.

Comprobar que el puerto está escuchando:

ss -lntp

La salida debe mostrar el puerto configurado para Node Exporter, habitualmente el 9100.

Comprobar Prometheus¶

Si Prometheus se ejecuta como servicio:

sudo systemctl status prometheus

Si se ejecuta mediante contenedor:

docker ps
docker logs prometheus --tail 50

Comprobar Grafana¶

sudo systemctl status grafana-server

o:

docker ps
docker logs grafana --tail 50

Registrar el resultado¶

Node Exporter:

Prometheus:

Grafana:

Conectividad entre componentes:

Observaciones:

Fase 2: validar la fuente de datos¶

Objetivo¶

Comprobar que Grafana puede consultar Prometheus.

Pasos¶

Acceder a Grafana.
Abrir Connections o Data sources.
Seleccionar Prometheus.
Ejecutar la prueba de conexión.
Confirmar que la fuente está disponible.

Resultado esperado¶

Data source is working

El texto exacto puede variar según la versión.

Si la prueba falla¶

Comprobar:

URL de Prometheus.
Resolución DNS.
Conectividad de red.
Credenciales, si existen.
Estado del servicio Prometheus.
Restricciones de firewall.
Logs de Grafana.
Logs de Prometheus.

Fase 3: validar consultas PromQL¶

Objetivo¶

Comprobar que las consultas devuelven datos antes de utilizarlas en reglas.

Abrir:

Explore → Prometheus

Consulta 1: disponibilidad¶

up{job="node_exporter"}

Resultado esperado:

1 = objetivo disponible
0 = objetivo no disponible

Registrar:

Número de series:

Valor actual:

Etiqueta job:

Etiqueta instance:

Consulta 2: CPU utilizada¶

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

Resultado esperado:

Porcentaje de CPU utilizado por instancia.

Comprobar:

¿El valor está entre 0 y 100?

¿Aparece la etiqueta instance?

¿Hay una serie por instancia?

¿El valor coincide aproximadamente con el sistema?

Consulta 3: memoria utilizada¶

100 * (
  1 -
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

Resultado esperado:

Porcentaje de memoria utilizada.

Consulta 4: memoria disponible¶

100 * (
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

Resultado esperado:

Porcentaje de memoria disponible.

Consulta 5: almacenamiento utilizado¶

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

Resultado esperado:

Porcentaje utilizado del sistema de ficheros raíz.

Registrar las consultas¶

Guardar las consultas en un fichero:

cat > ~/laboratorio-grafana/evidencias/laboratorio-integrador/consultas/consultas-promql.txt <<'EOF'
Disponibilidad:
up{job="node_exporter"}

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

Memoria utilizada:
100 * (
  1 -
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

Memoria disponible:
100 * (
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

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

Fase 4: crear un dashboard de laboratorio¶

Objetivo¶

Crear un dashboard que permita observar las métricas utilizadas por las alertas.

Crear un dashboard llamado:

Laboratorio - Anotaciones y alertas

Panel 1: disponibilidad¶

Consulta:

up{job="node_exporter"}

Configuración recomendada:

Título:
Disponibilidad de Node Exporter

Unidad:
none

Visualización:
Stat o Time series

Panel 2: CPU¶

Consulta:

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

Configuración:

Título:
CPU utilizada por instancia

Unidad:
Percent (0-100)

Umbral visual:
80 = amarillo
90 = rojo

Panel 3: memoria¶

Consulta:

100 * (
  1 -
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

Configuración:

Título:
Memoria utilizada

Unidad:
Percent (0-100)

Panel 4: almacenamiento¶

Consulta:

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

Configuración:

Título:
Almacenamiento utilizado

Unidad:
Percent (0-100)

Guardar el dashboard¶

Guardar el dashboard con:

Nombre:
Laboratorio - Anotaciones y alertas

Copiar su URL:

URL del dashboard:

La URL se utilizará posteriormente en las anotaciones y notificaciones.

Fase 5: crear anotaciones manuales¶

Objetivo¶

Registrar eventos operativos para relacionarlos con las métricas.

Crear una anotación de inicio de práctica:

Título:
Inicio de práctica de observabilidad

Descripción:
Comienzo del laboratorio sobre anotaciones y alertas.

Añadir etiquetas:

event = lab-start
environment = laboratory
team = training

Crear una anotación de prueba de carga¶

Título:
Inicio de prueba de carga

Descripción:
Se inicia una prueba de carga controlada sobre la máquina de laboratorio.

Etiquetas:

event = load-test
environment = laboratory

Crear una anotación de mantenimiento¶

Título:
Mantenimiento de laboratorio

Descripción:
Se detendrá temporalmente Node Exporter para probar la alerta de disponibilidad.

Etiquetas:

event = maintenance
service = node_exporter
environment = laboratory

Comprobar las anotaciones¶

Abrir el dashboard.
Seleccionar un rango temporal que incluya las anotaciones.
Confirmar que aparecen sobre los paneles.
Seleccionar una anotación.
Revisar su título, descripción y etiquetas.

Registrar¶

Anotación de inicio creada:

Anotación de carga creada:

Anotación de mantenimiento creada:

Anotaciones visibles en el dashboard:

Observaciones:

Fase 6: crear la alerta de disponibilidad¶

Objetivo¶

Detectar que Node Exporter deja de responder.

Nombre¶

NodeExporterDown-Laboratory

Consulta¶

up{job="node_exporter"}

Expresión¶

Utilizar el último valor disponible:

Reduce:
Last

Condición¶

Valor igual a 0

Evaluación¶

Intervalo:
30 segundos

Duración:
1 minuto

Etiquetas¶

alertname = NodeExporterDown-Laboratory
severity = critical
team = systems
service = node_exporter
environment = laboratory
resource = availability

Anotaciones¶

summary = Node Exporter no disponible en {{ $labels.instance }}

description = El objetivo {{ $labels.instance }}
no responde a Prometheus en el entorno de laboratorio.

runbook_url = https://example.com/runbooks/node-exporter-down
dashboard_url = URL_DEL_DASHBOARD_DE_LABORATORIO

Sustituir URL_DEL_DASHBOARD_DE_LABORATORIO por la URL real, si procede.

Ausencia de datos¶

Para esta alerta, decidir y documentar el comportamiento ante ausencia de datos:

No data:
Alerting o No data

La elección depende del diseño del laboratorio. Lo importante es justificarla.

Crear la regla¶

Abrir Alerting.
Seleccionar Alert rules.
Crear una regla.
Introducir la consulta.
Configurar la reducción.
Configurar la condición.
Añadir la duración.
Añadir etiquetas.
Añadir anotaciones.
Guardar.

Fase 7: crear la alerta de CPU¶

Objetivo¶

Detectar un uso sostenido de CPU superior al 90 %.

Nombre¶

HighCPUUsage-Laboratory

Consulta¶

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

Reducción¶

Last

Condición¶

Mayor que 90

Evaluación¶

Intervalo:
1 minuto

Duración:
5 minutos

Etiquetas¶

alertname = HighCPUUsage-Laboratory
severity = warning
team = systems
service = node_exporter
environment = laboratory
resource = cpu

Anotaciones¶

summary = CPU elevada en {{ $labels.instance }}

description = La CPU de {{ $labels.instance }}
supera el 90 % durante cinco minutos.

runbook_url = https://example.com/runbooks/high-cpu
dashboard_url = URL_DEL_DASHBOARD_DE_LABORATORIO

Crear la regla¶

Validar la consulta en Explore.
Crear la regla.
Configurar el umbral.
Configurar la duración.
Añadir etiquetas.
Añadir anotaciones.
Guardar.
Confirmar que aparece en estado Normal.

Fase 8: crear la alerta de memoria¶

Objetivo¶

Detectar un uso de memoria superior al 90 %.

Nombre¶

HighMemoryUsage-Laboratory

Consulta¶

100 * (
  1 -
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

Reducción¶

Last

Condición¶

Mayor que 90

Evaluación¶

Intervalo:
1 minuto

Duración:
5 minutos

Etiquetas¶

alertname = HighMemoryUsage-Laboratory
severity = warning
team = systems
service = node_exporter
environment = laboratory
resource = memory

Anotaciones¶

summary = Uso de memoria elevado en {{ $labels.instance }}

description = La memoria utilizada en {{ $labels.instance }}
supera el 90 % durante cinco minutos.

runbook_url = https://example.com/runbooks/high-memory
dashboard_url = URL_DEL_DASHBOARD_DE_LABORATORIO

Fase 9: crear la alerta de almacenamiento¶

Objetivo¶

Detectar una ocupación del sistema de ficheros superior al 80 %.

Nombre¶

FilesystemUsageHigh-Laboratory

Consulta¶

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

Reducción¶

Last

Condición¶

Mayor que 80

Evaluación¶

Intervalo:
5 minutos

Duración:
10 minutos

Etiquetas¶

alertname = FilesystemUsageHigh-Laboratory
severity = warning
team = systems
service = node_exporter
environment = laboratory
resource = filesystem
mountpoint = /

Anotaciones¶

summary = Sistema de ficheros con ocupación elevada

description = El sistema de ficheros raíz de
{{ $labels.instance }} supera el 80 % de uso.

runbook_url = https://example.com/runbooks/filesystem-full
dashboard_url = URL_DEL_DASHBOARD_DE_LABORATORIO

Fase 10: revisar la lista de alertas¶

Objetivo¶

Consultar el estado de todas las reglas creadas.

Acceder a:

Alerting → Alert rules

Comprobar:

NodeExporterDown-Laboratory
HighCPUUsage-Laboratory
HighMemoryUsage-Laboratory
FilesystemUsageHigh-Laboratory

Tabla de control¶

Regla	Estado inicial	Consulta válida	Etiquetas completas	Anotaciones
NodeExporterDown-Laboratory
HighCPUUsage-Laboratory
HighMemoryUsage-Laboratory
FilesystemUsageHigh-Laboratory

Filtrar por estado¶

Probar los filtros:

Normal
Pending
Alerting
No data
Error

Registrar:

Número de reglas normales:

Número de reglas pendientes:

Número de reglas activas:

Número de reglas sin datos:

Número de reglas con error:

Fase 11: crear un contacto de notificación¶

Objetivo¶

Crear un destino de laboratorio para recibir alertas.

Utilizar uno de los siguientes canales:

Correo de laboratorio.
Webhook de laboratorio.
Canal colaborativo autorizado.
Sistema ITSM de prácticas.

Ejemplo de contacto¶

Nombre:
laboratory-systems

Tipo:
Correo electrónico o webhook

Entorno:
laboratory

Finalidad:
Pruebas del laboratorio de alertas

No utilizar contactos de producción.

Probar el contacto¶

Crear el contacto.
Guardar.
Ejecutar una prueba.
Comprobar la recepción.
Registrar el resultado.

Contacto:

Tipo:

Fecha de prueba:

Resultado:

Tiempo de entrega:

Problemas:

Fase 12: crear políticas de notificación¶

Objetivo¶

Enviar las alertas del laboratorio al contacto de formación.

Coincidencias¶

environment = laboratory

Contacto¶

laboratory-systems

Configuración de agrupación¶

Para la primera prueba, utilizar:

group_by:
- alertname
- instance

Temporización de laboratorio¶

Utilizar valores breves únicamente en el entorno de prácticas:

group_wait:
10 segundos

group_interval:
1 minuto

repeat_interval:
5 minutos

Estos valores son adecuados para acelerar las pruebas, pero no deben copiarse automáticamente a producción.

Crear la política¶

Abrir Alerting.
Acceder a las políticas.
Crear una ruta.
Añadir la coincidencia environment=laboratory.
Seleccionar el contacto.
Configurar agrupación.
Guardar.
Documentar.

Fase 13: probar la alerta de disponibilidad¶

Objetivo¶

Comprobar el ciclo completo de una alerta de disponibilidad.

Preparación¶

Crear una anotación:

Título:
Inicio de prueba Node Exporter

Descripción:
Se detendrá Node Exporter de laboratorio
para validar la alerta NodeExporterDown-Laboratory.

Comprobar el estado inicial¶

Regla:
NodeExporterDown-Laboratory

Estado esperado:
Normal

Detener Node Exporter¶

Ejecutar únicamente en la máquina de laboratorio:

sudo systemctl stop node_exporter

Observar el ciclo¶

En Grafana:

Normal
   |
   v
Pending
   |
   v
Alerting

Comprobar:

Hora de inicio de Pending.
Hora de entrada en Alerting.
Instancia afectada.
Etiquetas.
Anotaciones.
Notificación recibida.

Iniciar Node Exporter¶

sudo systemctl start node_exporter

Observar:

Alerting
   |
   v
Normal

Registro¶

Hora de detención:

Hora de Pending:

Hora de Alerting:

Hora de recepción:

Hora de inicio del servicio:

Hora de recuperación:

Hora de recepción de recuperación:

Resultado:

Fase 14: probar la alerta de CPU¶

Objetivo¶

Comprobar que la duración evita alertas por picos breves.

Preparación¶

Crear una anotación:

Título:
Inicio de prueba de carga

Descripción:
Se ejecuta una carga controlada para probar HighCPUUsage-Laboratory.

Generar carga controlada¶

En la máquina de laboratorio:

stress-ng --cpu 1 --timeout 60s

Si stress-ng no está instalado, utilizar el mecanismo aprobado por el instructor.

Observar el comportamiento¶

La regla está configurada con:

Umbral:
90 %

Duración:
5 minutos

Es posible que una prueba de 60 segundos no sea suficiente para alcanzar Alerting.

Esto permite observar que:

CPU elevada durante un periodo breve
    → Pending o Normal

Para una prueba de activación, utilizar una carga controlada y autorizada con una duración compatible con el laboratorio.

Registrar¶

Valor máximo:

Tiempo por encima del umbral:

Estado observado:

¿Se envió notificación?:

Motivo:

Resultado:

Fase 15: comparar reducciones¶

Objetivo¶

Comprender la diferencia entre Last, Mean y Max.

Utilizar la consulta de CPU.

Configuraciones¶

Crear expresiones de prueba:

Configuración A:
Reducción = Last
Umbral = 90

Configuración B:
Reducción = Mean
Umbral = 80

Configuración C:
Reducción = Max
Umbral = 95

Actividad¶

Ejecutar la consulta en Explore.
Observar la serie.
Registrar el último valor.
Registrar el promedio.
Registrar el máximo.
Generar una carga breve.
Comparar los estados.
Explicar las diferencias.

Registro¶

Último valor:

Valor medio:

Valor máximo:

Regla que se activó primero:

Regla que permaneció normal:

Explicación:

Fase 16: probar una alerta multidimensional¶

Objetivo¶

Comprobar que una alerta identifica la instancia concreta afectada.

Consulta¶

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

Configuración¶

Nombre:
HighCPUUsageByInstance-Laboratory

Condición:
Mayor que 90

Duración:
5 minutos

Anotación¶

summary = CPU elevada en {{ $labels.instance }}

description = La instancia {{ $labels.instance }}
supera el umbral configurado.

Actividades¶

Confirmar cuántas instancias devuelve la consulta.
Activar carga en una instancia.
Revisar la lista de alertas.
Identificar la instancia en estado Alerting.
Revisar el mensaje recibido.
Confirmar que la instancia aparece en la notificación.

Resultado esperado¶

server-01:9100 → Normal
server-02:9100 → Alerting

La salida concreta depende de las instancias disponibles.

Fase 17: probar una alerta `No data`¶

Objetivo¶

Diferenciar entre un valor cero y la ausencia de datos.

Consulta¶

up{job="node_exporter"}

Procedimiento¶

Ejecutar la consulta mientras Node Exporter funciona.
Detener Node Exporter.
Observar si aparece up=0 o si desaparece la serie.
Revisar la política de ausencia de datos.
Consultar la alerta en la lista.
Registrar el estado.
Volver a iniciar el servicio.

Registro¶

Estado con servicio activo:

Resultado de la consulta:

Estado con servicio detenido:

Resultado de la consulta:

Estado de la alerta:

Política No data:

Interpretación:

Fase 18: crear un silenciamiento¶

Objetivo¶

Suprimir temporalmente las notificaciones durante una actividad conocida.

Preparación¶

Crear una anotación:

Título:
Mantenimiento de laboratorio

Descripción:
Se detendrá temporalmente Node Exporter
para probar un silenciamiento.

Crear el silencio¶

Coincidencias:

alertname = NodeExporterDown-Laboratory
instance = server-01:9100
environment = laboratory

Configurar:

Inicio:
Hora actual

Fin:
20 minutos después

Comentario:
Práctica de mantenimiento autorizada.
Se valida el silenciamiento de NodeExporterDown-Laboratory.

Activar la alerta¶

sudo systemctl stop node_exporter

Comprobar:

La alerta se evalúa.
La alerta puede aparecer como Alerting.
El silencio está activo.
La notificación queda suprimida.

Recuperar¶

sudo systemctl start node_exporter

Registrar¶

Silencio:

Coincidencias:

Inicio:

Fin:

Alerta afectada:

Notificación durante el silencio:

Estado de la alerta:

Hora de recuperación:

Resultado:

Fase 19: comprobar el alcance del silencio¶

Objetivo¶

Comprobar que un silencio específico no afecta a otras instancias.

Preparación¶

Silenciar únicamente:

instance = server-01:9100

Actividad¶

Activar una alerta en server-01.
Activar la misma alerta en server-02, si existe.
Revisar los estados.
Revisar las notificaciones.
Comprobar qué instancia quedó silenciada.
Documentar el resultado.

Resultado esperado¶

server-01:
Notificación suprimida.

server-02:
Notificación entregada.

Si el entorno solo tiene una instancia, documentar la limitación.

Fase 20: revisar anotaciones y alertas juntas¶

Objetivo¶

Correlacionar eventos operativos con cambios en las métricas.

Línea temporal esperada¶

18:00 - Inicio de prueba de carga
18:01 - Anotación visible
18:02 - CPU comienza a aumentar
18:05 - CPU supera el umbral
18:05 - Alerta Pending
18:10 - Alerta Alerting
18:11 - Notificación recibida
18:12 - Fin de prueba de carga
18:16 - CPU vuelve a valores normales
18:17 - Alerta Normal

Actividad¶

Abrir el dashboard.
Seleccionar el rango temporal completo.
Revisar las anotaciones.
Revisar la serie de CPU.
Revisar la línea de alerta.
Comparar los tiempos.
Escribir una conclusión.

Conclusión¶

La anotación de la prueba de carga permite relacionar
el aumento de CPU con una actividad conocida.
La alerta se activó después de mantenerse la condición
durante el periodo configurado.

Fase 21: diagnosticar una alerta que no se activa¶

Objetivo¶

Investigar una regla que permanece en Normal.

Situación¶

El panel muestra CPU elevada,
pero HighCPUUsage-Laboratory no se activa.

Procedimiento¶

Ejecutar la consulta en Explore.
Comprobar la unidad.
Comprobar el umbral.
Comprobar la reducción.
Comprobar la duración.
Comprobar el estado de la regla.
Comprobar el grupo de evaluación.
Comprobar las etiquetas.
Revisar los logs si existe un error.
Documentar la causa.

Causas posibles¶

El valor no supera realmente el umbral.
La duración no ha transcurrido.
La regla utiliza una reducción incorrecta.
La consulta devuelve otra instancia.
La alerta está pausada.
El umbral utiliza una unidad incorrecta.
La consulta no devuelve datos.

Registro¶

Regla:

Valor observado:

Umbral:

Reducción:

Duración:

Estado:

Causa:

Corrección:

Resultado posterior:

Fase 22: diagnosticar una alerta sin notificación¶

Objetivo¶

Investigar una alerta que aparece como Alerting, pero no genera ningún mensaje.

Procedimiento¶

Confirmar que la regla está activa.
Revisar sus etiquetas.
Revisar la política coincidente.
Confirmar el contacto.
Revisar si existe un silencio.
Revisar la agrupación.
Revisar el intervalo de repetición.
Probar el contacto directamente.
Revisar los logs.
Registrar la causa.

Posibles causas¶

La alerta no coincide con la política.
El contacto no funciona.
Existe un silencio activo.
La notificación está agrupada.
El intervalo de repetición todavía no ha transcurrido.
El destinatario es incorrecto.
La integración externa devuelve un error.

Fase 23: probar una ruta sin coincidencia¶

Objetivo¶

Comprobar el comportamiento de una alerta que no coincide con ninguna política específica.

Crear una alerta de prueba¶

Utilizar etiquetas como:

alertname = TestUnmatchedAlert
team = unknown
environment = laboratory
severity = warning

Actividad¶

Crear una política para environment=laboratory.
Crear una alerta con team=unknown.
Activarla.
Comprobar el contacto utilizado.
Revisar la política predeterminada.
Añadir una ruta específica.
Repetir la prueba.
Comparar los resultados.

Registro¶

Política inicial:

Contacto inicial:

Ruta añadida:

Contacto posterior:

Resultado:

Fase 24: probar la recuperación¶

Objetivo¶

Comprobar que el sistema informa tanto de la activación como de la resolución.

Procedimiento¶

Confirmar el estado Normal.
Activar una condición.
Esperar Alerting.
Confirmar la notificación.
Resolver la condición.
Esperar Normal.
Confirmar la notificación de recuperación.
Comparar ambos mensajes.

Tabla¶

Evento	Hora en Grafana	Hora de recepción	Resultado
Activación
Recuperación

Revisar en el mensaje¶

Estado:
FIRING o RESOLVED

Nombre de la alerta:

Instancia:

Severidad:

Valor:

Hora:

Descripción:

Runbook:

Fase 25: revisar el historial de estados¶

Objetivo¶

Reconstruir la evolución de una alerta.

Ejemplo¶

18:00 - Normal
18:05 - Pending
18:10 - Alerting
18:16 - Normal

Actividad¶

Para cada alerta probada, registrar:

Estado inicial:

Hora de Pending:

Hora de Alerting:

Hora de recuperación:

Duración total:

Número de notificaciones:

Silencio aplicado:

Observaciones:

Análisis¶

Responder:

¿La duración configurada fue adecuada?

¿La alerta se activó demasiado pronto?

¿La alerta tardó demasiado?

¿La notificación llegó al contacto correcto?

¿La recuperación fue clara?

¿La regla generó ruido?

Fase 26: elaborar el informe operativo¶

Resumen general¶

Fecha:

Alumno:

Grupo:

Entorno:

Periodo de la práctica:

Número de reglas creadas:

Número de anotaciones creadas:

Número de alertas activadas:

Número de recuperaciones:

Número de notificaciones:

Número de silenciamientos:

Resultado general:

Incidencias observadas¶

Alerta	Instancia	Inicio	Recuperación	Causa	Acción

Problemas de configuración¶

Problema	Causa	Corrección	Resultado

Conclusión del alumno¶

¿Qué regla fue más fácil de configurar?

¿Qué problema fue más difícil de diagnosticar?

¿Qué diferencia existe entre una alerta y una anotación?

¿Qué utilidad tuvo el silenciamiento?

¿Qué mejora aplicarías al sistema?

Fase 27: limpieza del entorno¶

Al finalizar:

Confirmar que Node Exporter está funcionando.
Confirmar que Prometheus recibe métricas.
Confirmar que Grafana está operativo.
Revisar las reglas creadas.
Eliminar reglas temporales.
Revisar contactos de laboratorio.
Eliminar o dejar expirar silenciamientos.
Revisar políticas de prueba.
Eliminar anotaciones que no deban conservarse.
Guardar las evidencias.
Informar al instructor.
Confirmar que no quedan cambios no documentados.

Comprobar el servicio¶

sudo systemctl status node_exporter

Comprobar la consulta¶

up{job="node_exporter"}

Resultado esperado:

Plantilla final de evaluación¶

Reglas¶

Regla	Creada	Probada	Activación	Recuperación
NodeExporterDown-Laboratory
HighCPUUsage-Laboratory
HighMemoryUsage-Laboratory
FilesystemUsageHigh-Laboratory

Anotaciones¶

Anotación	Creada	Visible	Comentario
Inicio de práctica
Prueba de carga
Mantenimiento

Notificaciones¶

Prueba	Contacto	Enviada	Recibida	Observaciones
Contacto directo
CPU
Disponibilidad
Recuperación

Silenciamientos¶

Silencio	Alcance	Activo	Suprimió	Revisado

Criterios de evaluación¶

Criterio	Puntuación
Verificación inicial del entorno	1
Validación de consultas	1
Creación de reglas	2
Configuración de expresiones y condiciones	1
Etiquetas y anotaciones	1
Configuración de notificaciones	1
Prueba de activación y recuperación	1
Uso correcto de silenciamientos	1
Documentación e informe final	1
Total	10

Indicadores de una práctica correcta¶

Las consultas devuelven datos válidos.
Las reglas tienen nombres descriptivos.
Las unidades y umbrales son coherentes.
Las etiquetas permiten enrutar las alertas.
Las anotaciones incluyen contexto.
Las notificaciones llegan al contacto esperado.
Las alertas pasan por los estados esperados.
Las recuperaciones se comprueban.
Los silenciamientos tienen alcance limitado.
El entorno queda limpio al finalizar.

Puntos clave¶

El laboratorio integra consultas, reglas, anotaciones, notificaciones y silenciamientos.
Las consultas deben validarse antes de crear reglas.
Una regla debe tener un objetivo operativo claro.
Las expresiones y condiciones deben utilizar unidades coherentes.
Las etiquetas permiten clasificar y enrutar alertas.
Las anotaciones proporcionan contexto temporal.
El estado Pending ayuda a evitar alertas por picos breves.
El estado Alerting indica que la condición se ha mantenido.
Una alerta Normal no significa que nunca haya existido un problema.
La recuperación debe probarse igual que la activación.
Las políticas conectan las etiquetas con los contactos.
Una alerta activa no garantiza que la notificación haya llegado.
Los silenciamientos suprimen notificaciones, pero no resuelven problemas.
Los silenciamientos deben tener una duración y un motivo.
La lista de alertas permite investigar el estado global.
Las anotaciones ayudan a correlacionar cambios y métricas.
Las pruebas deben ejecutarse en un entorno autorizado.
Las credenciales nunca deben incluirse en las evidencias.
Los contactos de laboratorio deben estar separados de producción.
Las reglas ruidosas deben corregirse, no silenciarse indefinidamente.
Un buen laboratorio comprueba activación, notificación, investigación y recuperación.
La limpieza final evita dejar configuraciones temporales activas.
La documentación es parte del resultado técnico.
Una alerta útil debe permitir actuar sobre un problema concreto.
La observabilidad mejora cuando las métricas, los eventos y las alertas se analizan juntos.

Preguntas de comprobación¶

¿Qué componentes se integran en este laboratorio?
¿Por qué deben validarse las consultas antes de crear reglas?
¿Qué diferencia existe entre una métrica y una alerta?
¿Qué función cumple una anotación?
¿Qué diferencia existe entre Pending y Alerting?
¿Qué diferencia existe entre una alerta activa y una alerta notificada?
¿Qué información deben contener las etiquetas?
¿Qué función cumplen las políticas de notificación?
¿Qué ocurre si una alerta no coincide con ninguna política específica?
¿Qué diferencia existe entre un silencio y una regla deshabilitada?
¿Por qué un silencio debe tener una fecha de finalización?
¿Cómo comprobarías que un silencio tiene el alcance correcto?
¿Qué revisarías si una alerta no se activa?
¿Qué revisarías si una alerta está activa, pero no llega la notificación?
¿Cómo probarías una alerta de disponibilidad?
¿Cómo probarías una alerta de CPU?
¿Cómo distinguirías entre un valor cero y la ausencia de datos?
¿Por qué es importante conservar la etiqueta instance?
¿Qué relación existe entre una anotación de despliegue y una alerta de latencia?
¿Qué información incluirías en un informe operativo?
¿Qué acciones de limpieza deben realizarse al terminar?
¿Qué evidencias deben guardarse?
¿Qué riesgos existen al ejecutar pruebas de carga?
¿Por qué no deben utilizarse credenciales reales durante la práctica?
¿Qué características debe tener una implementación completa de alertas?

Resultado esperado¶

Al finalizar el laboratorio, el alumno debe haber construido y probado un flujo completo de observabilidad:

Validar la fuente de datos
        |
        v
Validar las consultas
        |
        v
Crear el dashboard
        |
        v
Añadir anotaciones
        |
        v
Crear reglas de alerta
        |
        v
Configurar etiquetas
        |
        v
Configurar contactos
        |
        v
Configurar políticas
        |
        v
Activar una condición
        |
        v
Observar Pending
        |
        v
Observar Alerting
        |
        v
Recibir la notificación
        |
        v
Investigar el contexto
        |
        v
Aplicar un silenciamiento si procede
        |
        v
Resolver la condición
        |
        v
Comprobar la recuperación
        |
        v
Revisar el historial
        |
        v
Documentar el resultado
        |
        v
Limpiar el entorno

La práctica está completada correctamente cuando:

Grafana consulta Prometheus sin errores.
Las consultas devuelven datos esperados.
Las reglas se activan con condiciones controladas.
Las anotaciones aparecen en el dashboard.
Las etiquetas permiten identificar el recurso y el equipo.
Las políticas enrutan las alertas correctamente.
Las notificaciones llegan a un contacto de laboratorio.
Las recuperaciones se observan y documentan.
Los silenciamientos afectan únicamente al alcance previsto.
Los problemas se diagnostican con un procedimiento ordenado.
El entorno queda limpio.
El informe final contiene evidencias suficientes.

El objetivo no es únicamente conseguir que una alerta cambie a Alerting. El objetivo es demostrar que todo el ciclo funciona: detectar, contextualizar, notificar, investigar, silenciar cuando corresponde, recuperar y documentar. Ahí es donde la monitorización deja de ser un conjunto de gráficos y se convierte en una herramienta operativa.