Anotaciones y alertas¶

Este bloque presenta las funcionalidades de Grafana relacionadas con la detección de problemas, el registro de eventos y el envío de notificaciones.

El alumno aprenderá a crear reglas de alerta a partir de métricas de Prometheus, documentar eventos mediante anotaciones y configurar los mecanismos necesarios para notificar una incidencia.

El recorrido formativo será:

Métrica
  |
  v
Consulta PromQL
  |
  v
Condición
  |
  v
Regla de alerta
  |
  v
Estado de alerta
  |
  v
Notificación
  |
  v
Anotación y seguimiento

Una alerta no sustituye al análisis técnico. Su función es avisar de que una condición relevante requiere atención.

Objetivos¶

Al finalizar este bloque, el alumno podrá:

Explicar la diferencia entre una métrica, una alerta y una notificación.
Crear anotaciones manuales y comprender su utilidad.
Crear reglas de alerta basadas en consultas PromQL.
Utilizar condiciones, expresiones y umbrales.
Interpretar los estados de una alerta.
Configurar contactos de notificación.
Configurar notificaciones por correo electrónico.
Comprender el funcionamiento de webhooks y otras integraciones.
Crear políticas de notificación.
Enrutar alertas mediante etiquetas.
Crear silenciamientos temporales.
Diferenciar un silencio de la desactivación de una regla.
Diagnosticar alertas que no se activan.
Probar una alerta en un entorno de laboratorio.
Documentar reglas, contactos, políticas y silenciamientos.
Aplicar buenas prácticas de seguridad y mantenimiento.

Introducción¶

La monitorización permite observar el estado de un sistema, pero observar no siempre es suficiente.

Un operador necesita saber cuándo una situación requiere atención. Para ello se utilizan las alertas.

Ejemplos:

La CPU supera el 90 % durante cinco minutos.
La memoria disponible es inferior al 10 %.
Un sistema de ficheros supera el 85 % de uso.
Un objetivo deja de responder.
La latencia p95 supera el límite establecido.

Una regla de alerta transforma una condición técnica en una señal operativa.

Ejemplo conceptual¶

Uso de CPU
    |
    v
Consulta PromQL
    |
    v
CPU > 90 %
    |
    v
Durante 5 minutos
    |
    v
Alerta activa
    |
    v
Correo o webhook

La calidad de una alerta depende de varios factores:

La consulta debe ser correcta.
El umbral debe ser razonable.
La duración debe evitar falsos positivos.
Las etiquetas deben permitir enrutarla.
La notificación debe llegar al destinatario adecuado.
La anotación debe explicar qué ocurre.
El procedimiento de respuesta debe estar documentado.

Una alerta mal diseñada puede generar ruido, fatiga y pérdida de confianza. Una alerta bien diseñada ayuda a detectar problemas relevantes en el momento adecuado.

Conceptos fundamentales¶

Métrica¶

Una métrica es un valor que describe el estado o comportamiento de un sistema.

Ejemplos:

node_load1

up

node_memory_MemAvailable_bytes

node_filesystem_avail_bytes

Consulta¶

Una consulta obtiene y procesa datos de una fuente como Prometheus.

Ejemplo:

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

Esta consulta calcula el porcentaje de CPU utilizada por instancia.

Condición¶

Una condición compara el resultado de una consulta con un criterio.

Ejemplo:

CPU mayor que 90 %

Regla de alerta¶

Una regla combina:

Consulta.
Condición.
Duración.
Etiquetas.
Anotaciones.
Comportamiento ante errores.
Comportamiento ante ausencia de datos.

Estado de alerta¶

Indica la situación actual de una regla.

Estados habituales:

Normal
Pending
Alerting o Firing
No data
Error

Los nombres exactos pueden variar según la versión de Grafana y el tipo de regla.

Notificación¶

Es el mensaje o evento enviado cuando una alerta cumple las condiciones definidas.

Ejemplos:

Correo electrónico.
Webhook.
Canal de mensajería.
Sistema de incidencias.
Integración externa.

Anotación¶

Una anotación registra un evento en una línea temporal.

Ejemplos:

Inicio de mantenimiento.
Despliegue de una nueva versión.
Reinicio del servicio.
Inicio de una prueba de carga.
Resolución de una incidencia.

Diferencia entre alerta y anotación¶

Elemento	Finalidad
Métrica	Medir un comportamiento
Consulta	Obtener o calcular datos
Alerta	Detectar una condición
Notificación	Comunicar la alerta
Anotación	Registrar un evento

Ejemplo¶

CPU = 93 %

Es una métrica.

CPU > 90 %

Es una condición.

CPU > 90 % durante 5 minutos

Es una regla de alerta.

Enviar un correo al equipo de sistemas

Es una notificación.

Registrar "inicio de investigación" en el gráfico

Es una anotación.

Estructura del bloque¶

Los contenidos se organizan de la siguiente forma:

01-index.md
  Introducción y organización del bloque

02-alertas.md
  Conceptos y estados de las alertas

03-anotaciones.md
  Registro de eventos sobre los gráficos

04-reglas-alerta.md
  Creación y configuración de reglas

05-condiciones-expresiones.md
  Condiciones, expresiones y evaluaciones

06-lista-alertas.md
  Consulta y gestión de alertas

07-contactos-notificacion.md
  Contactos y receptores

08-correo-electronico.md
  Configuración de correo electrónico

09-otras-notificaciones.md
  Webhooks e integraciones

10-politicas-notificacion.md
  Enrutamiento y agrupación

11-silenciados.md
  Supresión temporal de notificaciones

12-laboratorio.md
  Práctica integradora

Flujo de trabajo recomendado¶

Una implementación de alertas puede seguir este proceso:

1. Definir el problema operativo.
2. Identificar la métrica.
3. Crear la consulta.
4. Validar la consulta en Explore.
5. Definir el umbral.
6. Definir la duración.
7. Añadir etiquetas.
8. Añadir anotaciones.
9. Crear la regla.
10. Configurar el contacto.
11. Configurar la política.
12. Probar la alerta.
13. Revisar la notificación.
14. Documentar el resultado.

No se debe crear una alerta directamente sobre una consulta que no haya sido validada previamente.

Ejemplo de regla de alerta¶

Objetivo¶

Detectar un uso elevado de CPU.

Consulta¶

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

Condición¶

El valor es mayor que 90

Duración¶

5 minutos

Etiquetas¶

severity = warning
team = systems
alertname = HighCPUUsage

Anotaciones¶

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

description = La instancia {{ $labels.instance }}
mantiene un uso de CPU superior al 90 % durante 5 minutos.

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

La sintaxis disponible para plantillas puede depender de la versión y del contexto de evaluación.

Estados de una alerta¶

Normal¶

La condición no se cumple.

Ejemplo:

CPU = 45 %
Umbral = 90 %
Estado = Normal

Pending¶

La condición se cumple, pero todavía no ha transcurrido la duración configurada.

Ejemplo:

CPU = 93 %
Duración configurada = 5 minutos
Tiempo transcurrido = 2 minutos
Estado = Pending

Alerting o Firing¶

La condición se ha mantenido durante el tiempo requerido.

Ejemplo:

CPU = 93 %
Duración configurada = 5 minutos
Tiempo transcurrido = 6 minutos
Estado = Alerting

No data¶

Grafana no recibe datos suficientes para evaluar la regla.

Posibles causas:

El objetivo está caído.
La consulta no devuelve series.
El rango temporal es inadecuado.
La métrica no existe.
Hay un problema de conectividad.
La fuente de datos no responde.

Error¶

La consulta o la evaluación produce un error.

Posibles causas:

PromQL inválido.
Métrica incorrecta.
Expresión mal configurada.
Fuente de datos inaccesible.
Transformación no compatible.

Etiquetas y anotaciones¶

Etiquetas¶

Las etiquetas permiten clasificar y enrutar alertas.

Ejemplo:

severity = critical
team = systems
environment = laboratory
service = web

Anotaciones¶

Las anotaciones proporcionan contexto legible.

Ejemplo:

summary = El servidor presenta un uso elevado de CPU

description = La CPU de {{ $labels.instance }}
ha superado el umbral configurado.

runbook_url = https://example.com/runbooks/cpu

Diferencia¶

Etiqueta:
severity=critical

Anotación:
La CPU permanece por encima del 90 % durante cinco minutos.

Las etiquetas son útiles para clasificar y enrutar.

Las anotaciones son útiles para comprender y actuar.

Severidad de las alertas¶

Se puede utilizar una etiqueta para clasificar la severidad:

severity = info
severity = warning
severity = critical

Ejemplo¶

Severidad	Significado
`info`	Información relevante
`warning`	Requiere revisión
`critical`	Requiere intervención prioritaria

Los nombres deben acordarse dentro de la organización.

No se debe marcar todo como critical. Si todo es crítico, nada destaca; es la versión operativa de gritar en una biblioteca.

Contactos de notificación¶

Un contacto define dónde se entrega una notificación.

Ejemplos:

Equipo de sistemas
Equipo de desarrollo
Responsable de guardia
Canal de incidencias
Sistema de tickets

Un contacto puede utilizar:

Correo electrónico.
Webhook.
Integración de mensajería.
Canal externo.
Sistema de incidencias.

Antes de probar una notificación, comprobar:

Dirección.
Permisos.
Conectividad.
Configuración SMTP.
URL del webhook.
Certificados.
Restricciones de red.

Políticas de notificación¶

Una política decide qué ocurre con una alerta después de generarse.

Puede determinar:

Contacto.
Ruta.
Agrupación.
Espera inicial.
Intervalo de repetición.
Condiciones de coincidencia.
Nivel de severidad.
Equipo destinatario.

Ejemplo conceptual¶

Si severity=critical
    enviar al equipo de guardia

Si severity=warning
    enviar al equipo de sistemas

Si team=development
    enviar al equipo de desarrollo

Las etiquetas de las alertas deben coincidir con las condiciones de las políticas.

Silenciamientos¶

Un silenciamiento evita temporalmente que una alerta genere notificaciones.

Puede utilizarse durante:

Mantenimientos.
Despliegues.
Pruebas de carga.
Ventanas programadas.
Incidencias ya conocidas.
Cambios de infraestructura.

Un silencio no necesariamente detiene la evaluación de la alerta. Normalmente evita o reduce el envío de notificaciones.

Buen silenciamiento¶

Motivo: mantenimiento programado
Coincidencia: instance=server-01:9100
Inicio: 22:00
Fin: 23:00
Responsable: equipo de sistemas

Mal silenciamiento¶

Motivo: temporal
Duración: indefinida
Coincidencia: todas las alertas

Todo silencio debe tener:

Motivo.
Responsable.
Alcance limitado.
Inicio.
Finalización.
Revisión posterior.

Prácticas relacionadas¶

Las prácticas de este bloque se encuentran en:

05-anotaciones-alertas/

Práctica 1: explorar alertas¶

Archivo:

02-alertas.md

Actividades:

Revisar los estados.
Consultar alertas.
Filtrar por etiquetas.
Identificar alertas activas.
Diferenciar Pending y Alerting.

Práctica 2: crear anotaciones¶

Archivo:

03-anotaciones.md

Actividades:

Crear una anotación manual.
Añadir etiquetas.
Registrar un mantenimiento.
Registrar el inicio de una prueba.
Revisar la anotación en un Time series.

Práctica 3: crear una regla¶

Archivo:

04-reglas-alerta.md

Actividades:

Crear una consulta.
Configurar un umbral.
Añadir una duración.
Añadir etiquetas.
Añadir anotaciones.
Guardar la regla.

Práctica 4: configurar condiciones¶

Archivo:

05-condiciones-expresiones.md

Actividades:

Utilizar una expresión matemática.
Configurar una reducción.
Comparar con un umbral.
Probar ausencia de datos.
Revisar errores de evaluación.

Práctica 5: configurar contactos¶

Archivos:

07-contactos-notificacion.md
08-correo-electronico.md
09-otras-notificaciones.md

Actividades:

Crear un contacto.
Configurar correo.
Probar un webhook.
Revisar la entrega.
Diagnosticar un fallo.

Práctica 6: crear políticas¶

Archivo:

10-politicas-notificacion.md

Actividades:

Crear una ruta.
Enrutar por severidad.
Agrupar alertas.
Configurar repetición.
Probar rutas diferentes.

Práctica 7: silenciar alertas¶

Archivo:

11-silenciados.md

Actividades:

Crear un silencio.
Limitarlo mediante etiquetas.
Añadir un motivo.
Definir una finalización.
Comprobar la recuperación de las notificaciones.

Práctica 8: laboratorio integrador¶

Archivo:

12-laboratorio.md

Actividades:

Crear una regla completa.
Probarla.
Recibir una notificación.
Crear una anotación.
Crear un silencio.
Documentar todo el proceso.

Ejemplos de sesión¶

Sesión 1: identificar métricas para alertas¶

Objetivo¶

Localizar métricas adecuadas para crear reglas.

Consultas¶

Disponibilidad:

up

CPU:

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

Memoria disponible:

node_memory_MemAvailable_bytes

Uso de memoria:

100 * (
  1 -
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

Uso del sistema de ficheros:

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

Actividades¶

Ejecuta cada consulta en Explore.
Comprueba si devuelve datos.
Identifica las etiquetas.
Anota la unidad.
Propón un umbral razonable.
Explica qué problema detectaría cada métrica.

Sesión 2: crear una alerta de disponibilidad¶

Objetivo¶

Detectar que un objetivo deja de estar disponible.

Consulta¶

up{job="node_exporter"}

Condición¶

El valor es igual a 0

Duración¶

1 minuto

Etiquetas¶

severity = critical
team = systems
service = node-exporter

Anotaciones¶

summary = Objetivo no disponible

description = El objetivo {{ $labels.instance }}
no está respondiendo a Prometheus.

runbook_url = https://example.com/runbooks/target-down

Actividades¶

Crea la regla.
Guarda la regla.
Detén Node Exporter:

sudo systemctl stop node_exporter

Espera el periodo de evaluación.
Revisa el estado.
Inicia Node Exporter:

sudo systemctl start node_exporter

Comprueba la recuperación.
Documenta los tiempos.

Sesión 3: crear una alerta de CPU¶

Objetivo¶

Detectar un consumo sostenido de CPU.

Consulta¶

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

Condición¶

Valor mayor que 90

Duración¶

5 minutos

Etiquetas¶

severity = warning
team = systems
resource = cpu

Anotaciones¶

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

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

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

Actividades¶

Crea la regla.
Genera carga controlada.
Observa el estado Pending.
Mantén la carga el tiempo necesario.
Observa el estado Alerting.
Detén la carga.
Comprueba la recuperación.

Sesión 4: crear una alerta de almacenamiento¶

Objetivo¶

Detectar un sistema de ficheros con ocupación elevada.

Consulta¶

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

Condición¶

Valor mayor que 80

Etiquetas¶

severity = warning
team = systems
resource = filesystem
mountpoint = /

Anotaciones¶

summary = Sistema de ficheros con ocupación elevada

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

Actividades¶

Crea la regla.
Comprueba la unidad.
Revisa las etiquetas.
Comprueba el resultado en una tabla.
Explica por qué se excluyen tmpfs y overlay.

Sesión 5: crear una anotación manual¶

Objetivo¶

Registrar un evento visible sobre un gráfico.

Evento¶

Inicio de prueba de carga de CPU

Pasos¶

Abrir un panel Time series.
Seleccionar la opción de añadir anotación.
Introducir el texto:

Inicio de prueba de carga de CPU

Añadir etiquetas:

tipo = laboratorio
componente = cpu

Guardar la anotación.
Ejecutar la carga.
Añadir otra anotación:

Fin de prueba de carga de CPU

Actividades¶

Compara la posición de las anotaciones con la gráfica.
Explica qué relación existe entre el evento y el incremento de CPU.
Utiliza etiquetas para filtrar las anotaciones.

Sesión 6: configurar un contacto de correo¶

Objetivo¶

Crear un contacto de notificación para pruebas.

Requisitos¶

Cuenta de correo autorizada.
Configuración SMTP disponible.
Dirección de destino válida.
Permisos administrativos.

Pasos¶

Acceder a los contactos de notificación.
Crear un contacto.
Seleccionar correo electrónico.
Introducir una dirección autorizada.
Guardar.
Ejecutar una prueba de envío.
Revisar la bandeja de entrada.
Revisar la carpeta de correo no deseado.
Revisar los logs si no llega.

Actividades¶

Documentar:

Nombre del contacto:

Tipo:

Destinatario:

Fecha de la prueba:

Resultado:

Tiempo de entrega:

Problemas encontrados:

No incluir contraseñas SMTP en el dashboard, en capturas ni en el repositorio.

Sesión 7: configurar un webhook¶

Objetivo¶

Enviar una notificación a un endpoint de laboratorio.

Requisitos¶

Endpoint autorizado.
URL válida.
Método de autenticación definido.
Entorno de pruebas.

Pasos¶

Crear un contacto de tipo webhook.
Introducir la URL.
Configurar la autenticación si procede.
Guardar.
Ejecutar una prueba.
Revisar la respuesta.
Activar una alerta de laboratorio.
Comprobar la recepción.

Actividades¶

Registra el código de respuesta.
Registra el cuerpo recibido.
Comprueba el formato.
Documenta cualquier error.
Elimina los tokens de las evidencias.

Sesión 8: enrutar alertas por severidad¶

Objetivo¶

Enviar alertas según su nivel de severidad.

Etiquetas¶

Alerta de advertencia:

severity = warning

Alerta crítica:

severity = critical

Políticas¶

warning:
  contacto = equipo-sistemas

critical:
  contacto = equipo-guardia

Actividades¶

Crea dos contactos de laboratorio.
Crea una ruta para warning.
Crea una ruta para critical.
Crea una alerta de prueba para cada nivel.
Comprueba el contacto utilizado.
Documenta el resultado.

Sesión 9: agrupar alertas¶

Objetivo¶

Evitar recibir una notificación individual por cada instancia cuando varias presentan el mismo problema.

Escenario¶

Tres servidores presentan CPU elevada.

Agrupación posible¶

Agrupar por:

alertname
team

Actividades¶

Crear varias alertas con la misma etiqueta alertname.
Configurar la agrupación.
Activar las alertas.
Comprobar el mensaje recibido.
Explicar qué información se conserva.
Evaluar si la agrupación facilita o dificulta la respuesta.

Sesión 10: crear un silencio temporal¶

Objetivo¶

Silenciar una alerta durante una prueba autorizada.

Escenario¶

Se realizará mantenimiento sobre server-01.

Coincidencias¶

instance = server-01:9100

Motivo¶

Mantenimiento programado del laboratorio

Duración¶

30 minutos

Actividades¶

Crear el silencio.
Añadir el motivo.
Añadir el responsable.
Ejecutar la prueba.
Comprobar que la alerta puede seguir evaluándose.
Comprobar que no se envían notificaciones.
Esperar la finalización.
Comprobar la recuperación de las notificaciones.

Buenas prácticas¶

Diseñar alertas accionables¶

Una alerta debe indicar:

Qué ocurre.
Dónde ocurre.
Desde cuándo ocurre.
Qué nivel de severidad tiene.
Qué debe revisarse.
Dónde encontrar el procedimiento.

Evitar alertas demasiado sensibles¶

Una regla que se activa ante cada variación pequeña produce ruido.

Utilizar:

Duraciones.
Ventanas de evaluación.
Umbrales razonables.
Agregaciones.
Filtros.

Evitar alertas demasiado tolerantes¶

Una regla que tarda demasiado en activarse puede retrasar la respuesta.

El tiempo debe adaptarse al problema:

Disponibilidad: intervalos cortos
CPU: varios minutos
Almacenamiento: periodos más amplios
Tareas programadas: según la duración esperada

Utilizar etiquetas consistentes¶

Ejemplo:

severity
team
service
environment
instance

No mezclar nombres equivalentes sin necesidad:

team
owner
responsible_team

Elegir una convención y mantenerla.

Escribir anotaciones útiles¶

Evitar:

Problema detectado

Preferir:

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

Probar las alertas¶

Una alerta no está terminada cuando se guarda. Debe probarse.

Comprobar:

Activación.
Notificación.
Contenido.
Enrutamiento.
Recuperación.
Comportamiento ante ausencia de datos.

Revisar silenciamientos¶

Los silenciamientos deben expirar.

Revisar periódicamente:

Silencios activos.
Motivos.
Responsables.
Fechas de finalización.
Alcance.

Proteger los contactos¶

No incluir:

Contraseñas.
Tokens.
Claves privadas.
URLs con credenciales.
Datos personales innecesarios.

Errores frecuentes¶

La alerta no se activa¶

Comprobar:

La consulta devuelve datos.
La condición está correctamente configurada.
El umbral utiliza la misma unidad.
La duración ha transcurrido.
La regla está habilitada.
La evaluación se ejecuta.
No existe un filtro incorrecto.

La alerta se activa demasiado pronto¶

Comprobar:

Duración.
Intervalo de evaluación.
Fluctuaciones de la métrica.
Ausencia de agregación.
Umbral demasiado sensible.

La notificación no llega¶

Comprobar:

Contacto.
Dirección.
SMTP.
Webhook.
Política.
Coincidencia de etiquetas.
Silenciamientos.
Agrupación.
Logs.

La alerta aparece como `No data`¶

Comprobar:

La métrica existe.
El objetivo está disponible.
El rango temporal contiene datos.
La consulta no filtra demasiado.
Prometheus responde.
La política de ausencia de datos está definida.

La alerta aparece como `Error`¶

Comprobar:

Sintaxis PromQL.
Expresiones.
Fuente de datos.
Permisos.
Logs.
Variables.
Transformaciones.

La política no enruta correctamente¶

Comprobar:

Nombre de la etiqueta.
Valor de la etiqueta.
Coincidencia exacta.
Orden de las rutas.
Ruta predeterminada.
Contacto asignado.

El silencio no funciona¶

Comprobar:

Etiquetas coincidentes.
Fecha de inicio.
Fecha de finalización.
Zona horaria.
Regla afectada.
Alcance del silencio.

Seguridad¶

Las alertas y notificaciones pueden contener información sensible.

Revisar:

Direcciones internas.
Nombres de servidores.
Nombres de clientes.
Mensajes de error.
URLs internas.
Datos de contacto.
Tokens.
Credenciales.
Información de infraestructura.

Recomendaciones¶

Utilizar contactos de prueba.
No enviar datos de producción a cuentas personales.
Proteger los webhooks.
Limitar permisos.
Revisar los destinatarios.
No incluir secretos en las anotaciones.
Auditar las políticas.
Retirar contactos no utilizados.
Probar en laboratorio antes de producción.

Evidencias recomendadas¶

Conservar:

01-consulta-metrica.png
02-regla-cpu.png
03-regla-disponibilidad.png
04-anotacion-manual.png
05-contacto-notificacion.png
06-prueba-correo.png
07-politica-severidad.png
08-alerta-pending.png
09-alerta-firing.png
10-alerta-resuelta.png
11-silencio-activo.png
12-dashboard-final.png

Guardar también las consultas:

mkdir -p ~/laboratorio-grafana/evidencias/anotaciones-alertas

cat > ~/laboratorio-grafana/evidencias/anotaciones-alertas/consultas.txt <<'EOF'
Disponibilidad:
up

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

Memoria:
100 * (
  1 -
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

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

Crear un registro de reglas:

cat > ~/laboratorio-grafana/evidencias/anotaciones-alertas/reglas.txt <<'EOF'
Regla:

Objetivo:

Consulta:

Condición:

Duración:

Etiquetas:

Anotaciones:

Contacto:

Política:

Prueba realizada:

Resultado:
EOF

Práctica integradora¶

Objetivo¶

Crear y probar un sistema completo de alertas para un servidor Linux.

Requisitos¶

Grafana funcionando.
Prometheus configurado.
Node Exporter disponible.
Permisos para crear reglas.
Contacto de notificación de laboratorio.
Entorno autorizado para detener servicios y generar carga.

Tareas¶

1. Crear la regla de disponibilidad¶

Consulta:

up{job="node_exporter"}

Condición:

Igual a 0

Duración:

1 minuto

2. Crear la regla de CPU¶

Consulta:

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

Condición:

Mayor que 90

Duración:

5 minutos

3. Añadir etiquetas¶

team = systems
environment = laboratory
severity = warning

4. Añadir anotaciones¶

summary = Problema detectado en {{ $labels.instance }}

description = La métrica ha superado el umbral configurado.

environment = laboratory

5. Crear el contacto¶

Utilizar un destinatario de laboratorio.

6. Crear la política¶

Configurar el enrutamiento para las alertas:

team = systems

7. Probar la alerta de disponibilidad¶

sudo systemctl stop node_exporter

Esperar la activación y registrar el resultado.

Iniciar de nuevo:

sudo systemctl start node_exporter

8. Probar la alerta de CPU¶

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

Observar:

Estado Pending.
Estado Alerting.
Notificación.
Resolución.

9. Crear una anotación¶

Registrar:

Inicio de prueba de carga

y:

Fin de prueba de carga

10. Crear un silencio¶

Silenciar temporalmente la alerta durante una nueva prueba controlada.

11. Documentar¶

Registrar:

Regla.
Consulta.
Umbral.
Duración.
Etiquetas.
Contacto.
Política.
Resultado.
Evidencias.
Problemas encontrados.

Tabla de resultados¶

Comprobación	Resultado	Observaciones
Métrica identificada
Consulta validada
Regla de disponibilidad creada
Regla de CPU creada
Umbrales configurados
Duraciones configuradas
Etiquetas añadidas
Anotaciones añadidas
Contacto creado
Notificación probada
Política creada
Alerta `Pending` observada
Alerta `Alerting` observada
Alerta resuelta
Anotación manual creada
Silencio creado
Silencio revisado
Evidencias guardadas
Informe completado

Preguntas de comprobación¶

¿Qué diferencia existe entre una métrica y una alerta?
¿Qué diferencia existe entre una alerta y una notificación?
¿Qué finalidad tiene una anotación?
¿Qué elementos forman una regla de alerta?
¿Qué significa el estado Pending?
¿Qué diferencia existe entre Alerting y Normal?
¿Qué puede provocar un estado No data?
¿Qué función cumplen las etiquetas?
¿Qué función cumplen las anotaciones de una regla?
¿Por qué es importante configurar una duración?
¿Qué ventajas tiene utilizar etiquetas de severidad?
¿Qué es un contacto de notificación?
¿Qué función cumple una política de notificación?
¿Cómo se puede enrutar una alerta por equipo?
¿Qué es un silenciamiento?
¿Por qué un silencio debe tener una fecha de finalización?
¿Cómo probarías una alerta de disponibilidad?
¿Cómo probarías una alerta de CPU?
¿Qué revisarías si una alerta no se activa?
¿Qué revisarías si la notificación no llega?
¿Qué revisarías si aparece No data?
¿Qué información debe incluir un runbook?
¿Qué información nunca debe incluirse en una notificación?
¿Qué evidencias guardarías en el laboratorio?
¿Qué características debe tener una alerta accionable?

Resultado esperado¶

Al finalizar este bloque, el alumno debe ser capaz de construir un flujo completo de detección y respuesta:

Identificar una métrica
        |
        v
Validar una consulta
        |
        v
Definir una condición
        |
        v
Crear una regla
        |
        v
Añadir etiquetas y anotaciones
        |
        v
Configurar un contacto
        |
        v
Crear una política
        |
        v
Probar la activación
        |
        v
Recibir la notificación
        |
        v
Registrar el evento
        |
        v
Aplicar un silencio controlado
        |
        v
Comprobar la recuperación
        |
        v
Documentar el resultado

El resultado final debe ser un sistema de alertas que genere avisos útiles, comprensibles y accionables, evitando tanto la ausencia de señales como el exceso de notificaciones irrelevantes.