Otras formas de notificación¶

Además del correo electrónico, Grafana puede enviar alertas mediante distintos canales de comunicación e integración.

Estos canales permiten adaptar la respuesta al tipo de alerta:

Un canal colaborativo para avisos de severidad media.
Un sistema de guardia para incidentes críticos.
Un webhook para automatizaciones.
Un sistema de gestión de incidencias.
Una aplicación de mensajería.
Un servicio externo de escalado.
Una plataforma interna de operaciones.

La disponibilidad exacta de las integraciones depende de la versión de Grafana, la edición utilizada, los complementos instalados y los servicios autorizados por la organización.

El flujo general es:

Regla de alerta
      |
      v
Etiquetas
      |
      v
Política de notificación
      |
      v
Contacto de notificación
      |
      v
Integración externa
      |
      v
Mensaje, incidencia o automatización

Una integración no debe seleccionarse únicamente porque sea técnicamente posible. También deben evaluarse:

La urgencia de la alerta.
La responsabilidad del destinatario.
La privacidad de los datos.
La disponibilidad del canal.
La trazabilidad.
El coste operativo.
La posibilidad de automatizar una respuesta.
El riesgo de generar ruido.

Objetivos¶

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

Explicar por qué existen varios canales de notificación.
Diferenciar un correo de un webhook y de un sistema de guardia.
Identificar integraciones habituales de Grafana.
Crear un contacto de tipo webhook.
Crear un contacto para un canal colaborativo.
Comprender el funcionamiento de una integración con un sistema de incidencias.
Relacionar una severidad con un canal de notificación.
Configurar una política para alertas críticas.
Probar una integración externa en un entorno de laboratorio.
Interpretar respuestas HTTP de un webhook.
Diagnosticar errores de autenticación.
Diagnosticar errores de conectividad.
Proteger tokens, claves y URLs privadas.
Evitar enviar información sensible a canales inadecuados.
Comprobar la recepción de una notificación.
Comprobar la creación de una incidencia.
Revisar el comportamiento de una alerta recuperada.
Documentar una integración.
Elegir el canal más adecuado para cada tipo de alerta.

Introducción¶

No todas las alertas deben enviarse por el mismo canal.

Una alerta informativa puede aparecer en un canal colaborativo sin interrumpir al equipo de guardia.

Una alerta crítica de disponibilidad puede necesitar un sistema de escalado que avise a la persona de guardia.

Una alerta destinada a generar una tarea puede enviarse mediante un webhook a una plataforma de incidencias.

Ejemplo¶

severity=info
    → canal de observabilidad

severity=warning
    → canal del equipo de sistemas

severity=critical
    → sistema de guardia y gestión de incidencias

La clasificación debe definirse mediante etiquetas.

severity = critical
team = systems
service = payments
environment = production

La política de notificación utiliza esas etiquetas para seleccionar el contacto adecuado.

Tipos de notificación¶

Webhook¶

Un webhook envía una petición HTTP a una URL.

Grafana
   |
   | POST HTTPS
   v
Endpoint externo

Puede utilizarse para:

Crear incidencias.
Ejecutar automatizaciones.
Publicar mensajes.
Registrar eventos.
Activar procesos internos.
Integrar herramientas propias.

Canales colaborativos¶

Algunas organizaciones utilizan herramientas colaborativas para comunicar alertas a equipos.

Ejemplos:

Slack.
Microsoft Teams.
Mattermost.
Google Chat.
Discord, cuando esté autorizado.

Son adecuados para:

Alertas de laboratorio.
Avisos de severidad media.
Coordinación durante una incidencia.
Comunicación entre equipos.
Seguimiento de problemas no urgentes.

Sistemas de guardia¶

Las plataformas de guardia permiten avisar a personas según turnos y reglas de escalado.

Ejemplos:

PagerDuty.
Opsgenie.
Servicios equivalentes.

Son adecuados para:

Incidentes críticos.
Servicios disponibles continuamente.
Alertas que requieren respuesta inmediata.
Escalado si la primera persona no responde.

Sistemas de gestión de incidencias¶

Permiten crear, actualizar y cerrar incidencias.

Ejemplos:

Jira Service Management.
ServiceNow.
Sistemas internos.
Plataformas ITSM compatibles.

Son adecuados para:

Registrar el incidente.
Asignar responsables.
Mantener trazabilidad.
Gestionar acuerdos de nivel de servicio.
Documentar acciones y resolución.

Integraciones personalizadas¶

Una organización puede disponer de un receptor propio.

Ejemplos:

https://automation.example.com/hooks/grafana
https://incidents.example.com/api/alerts
https://operations.example.com/events

La integración debe estar documentada y protegida.

Diferencia entre los canales¶

Canal	Uso principal	Ventaja	Riesgo
Correo	Avisos y resúmenes	Sencillo y universal	Puede retrasarse o ignorarse
Webhook	Automatización	Flexible	Requiere desarrollo y seguridad
Chat	Coordinación	Visible para el equipo	Puede generar ruido
Guardia	Incidentes críticos	Escalado y turnos	Puede provocar fatiga
ITSM	Gestión formal	Trazabilidad	Configuración más compleja
Integración propia	Procesos internos	Adaptación total	Mantenimiento interno

La elección correcta depende del contexto operativo y no solo de las funciones disponibles.

Webhooks¶

Qué es un webhook¶

Un webhook es un mecanismo mediante el cual Grafana envía información a una aplicación externa cuando una alerta cumple una condición.

Normalmente se utiliza una petición HTTP POST.

POST /hooks/grafana HTTP/1.1
Host: automation.example.com
Content-Type: application/json
Authorization: Bearer TOKEN

El contenido suele enviarse en formato JSON.

Flujo de un webhook¶

Alerta activa
      |
      v
Política coincidente
      |
      v
Contacto webhook
      |
      v
Petición HTTPS
      |
      v
Servidor externo
      |
      v
Respuesta HTTP

Respuestas habituales¶

Código	Interpretación
`200`	Petición procesada correctamente
`201`	Recurso creado
`202`	Petición aceptada para procesamiento posterior
`400`	Datos incorrectos
`401`	Autenticación ausente o incorrecta
`403`	Acceso no permitido
`404`	Endpoint inexistente
`409`	Conflicto con un recurso existente
`429`	Límite de peticiones superado
`500`	Error interno del receptor
`503`	Servicio no disponible

El significado exacto depende del sistema receptor.

Payload de un webhook¶

Un payload es el contenido que Grafana envía al receptor.

El formato puede variar según la integración.

Ejemplo conceptual¶

{
  "status": "firing",
  "alerts": [
    {
      "status": "firing",
      "labels": {
        "alertname": "HighCPUUsage",
        "severity": "warning",
        "team": "systems",
        "instance": "server-01:9100"
      },
      "annotations": {
        "summary": "CPU elevada en server-01:9100",
        "description": "La CPU supera el 90 % durante cinco minutos."
      },
      "startsAt": "2026-09-24T18:00:00Z",
      "endsAt": "0001-01-01T00:00:00Z"
    }
  ],
  "externalURL": "https://grafana.example.com"
}

El payload real puede tener más campos.

Información útil¶

Un receptor suele necesitar:

Estado.
Nombre de la alerta.
Etiquetas.
Anotaciones.
Hora de inicio.
Hora de finalización.
Instancia afectada.
Enlace a Grafana.
Enlace al runbook.
Identificador de la alerta.

Seguridad de los webhooks¶

Los webhooks deben considerarse interfaces externas.

Riesgos¶

URL expuesta.
Token robado.
Endpoint sin autenticación.
Comunicación sin cifrado.
Repetición de peticiones.
Datos sensibles en el payload.
Receptor vulnerable.
Falta de validación del origen.
Permisos excesivos.

Buenas prácticas¶

Utilizar HTTPS.
Autenticar las peticiones.
Validar el contenido recibido.
Limitar el acceso por red cuando sea posible.
Utilizar tokens con permisos mínimos.
Rotar las credenciales.
Evitar credenciales dentro de la URL.
Registrar los eventos sin guardar secretos.
Controlar el tamaño del payload.
Proteger el endpoint frente a abusos.

Ejemplo incorrecto¶

https://example.com/hooks/grafana?token=secreto-real

Ejemplo preferible¶

https://example.com/hooks/grafana

La credencial debe configurarse mediante cabeceras o un mecanismo seguro.

Probar un webhook¶

Objetivo¶

Comprobar que Grafana puede comunicarse con un receptor autorizado.

Pasos¶

Crear un endpoint de laboratorio.
Crear el contacto webhook.
Configurar la URL.
Configurar la autenticación.
Guardar el contacto.
Ejecutar la prueba.
Revisar la respuesta HTTP.
Revisar los logs del receptor.
Comprobar el payload.
Activar una alerta de laboratorio.
Confirmar la recepción.
Registrar el resultado.

Registro¶

Nombre del contacto:

Endpoint:

Método:

Autenticación:

Fecha:

Código HTTP:

Payload recibido:

Resultado:

Problemas encontrados:

Corrección:

No guardar tokens ni cabeceras sensibles en el registro.

Canales colaborativos¶

Los canales colaborativos permiten que un equipo vea las alertas en una conversación compartida.

Ejemplo conceptual¶

Canal:
#operaciones-laboratorio

Mensaje:
[FIRING] HighCPUUsage
server-01:9100 supera el 90 % de CPU.

Ventajas¶

Visibilidad compartida.
Respuesta rápida del equipo.
Contexto en la conversación.
Posibilidad de añadir comentarios.
Integración con herramientas de trabajo.

Riesgos¶

Exceso de mensajes.
Alertas importantes mezcladas con avisos menores.
Falta de seguimiento formal.
Información sensible expuesta.
Dependencia de una plataforma externa.

Recomendaciones¶

Crear canales separados por equipo o entorno.
No enviar todas las alertas al mismo canal.
Utilizar severidades coherentes.
Incluir enlaces a dashboards y runbooks.
Mantener el canal moderado.
No utilizar un canal de chat como sustituto de un sistema de incidencias cuando se requiere trazabilidad.

Microsoft Teams, Slack y herramientas similares¶

La configuración concreta depende de la integración disponible.

Procedimiento general¶

Crear un canal de destino.
Obtener el mecanismo de integración autorizado.
Crear el contacto en Grafana.
Configurar la URL o los parámetros requeridos.
Guardar el contacto.
Ejecutar una prueba.
Comprobar el mensaje.
Activar una alerta de laboratorio.
Revisar el formato.
Documentar el resultado.

Información que debe aparecer¶

Estado:
FIRING o RESOLVED

Alerta:
HighCPUUsage

Severidad:
warning

Instancia:
server-01:9100

Descripción:
CPU superior al 90 %

Enlaces:
Dashboard y runbook

Los nombres de los campos y el aspecto visual dependen de la plataforma.

Sistemas de guardia¶

Qué es un sistema de guardia¶

Un sistema de guardia administra turnos, escalados y confirmaciones.

El flujo puede ser:

Alerta crítica
      |
      v
Persona de guardia
      |
      v
Sin confirmación
      |
      v
Segundo nivel
      |
      v
Equipo responsable

Cuándo utilizarlo¶

Caídas de servicios críticos.
Pérdida de disponibilidad.
Incidentes de seguridad.
Problemas con impacto económico.
Incumplimiento de un SLA.
Alertas que requieren respuesta fuera del horario laboral.

Cuándo no utilizarlo¶

Métricas informativas.
Picos breves.
Alertas sin acción definida.
Alertas de laboratorio.
Problemas que pueden revisarse durante el horario normal.

Fatiga de alertas¶

Si el sistema de guardia recibe demasiadas alertas, las personas pueden:

Ignorar avisos.
Confirmar sin investigar.
Desactivar notificaciones.
Perder alertas importantes.
Sufrir interrupciones innecesarias.

Por eso, solo deben llegar al sistema de guardia las alertas que requieran una respuesta urgente.

Integraciones con sistemas de incidencias¶

Una integración con un sistema ITSM puede:

Crear una incidencia.
Añadir comentarios.
Asignar un equipo.
Actualizar una incidencia existente.
Cambiar su estado.
Cerrar la incidencia al recuperarse la alerta.

Flujo de ejemplo¶

Alerta activa
      |
      v
Crear incidencia INC-1042
      |
      v
Asignar a systems
      |
      v
Investigar
      |
      v
Alerta recuperada
      |
      v
Añadir comentario de recuperación
      |
      v
Cerrar o resolver INC-1042

Precaución: duplicados¶

Si Grafana reenvía una alerta o la integración no reconoce el identificador, pueden crearse varias incidencias para el mismo problema.

El receptor debe utilizar un identificador estable cuando sea posible.

Ejemplo conceptual:

alertname + instance + service

Integraciones con sistemas de guardia e incidencias¶

Una alerta puede enviarse a varios destinos.

Ejemplo¶

severity=critical
    → sistema de guardia
    → sistema ITSM

severity=warning
    → canal de sistemas

severity=info
    → dashboard o resumen

No es necesario enviar cada alerta a todos los canales.

La política debe evitar duplicar mensajes innecesariamente.

Ejemplo de rutas¶

Condición	Destino
`severity=info`	Canal de observabilidad
`severity=warning`	Canal del equipo
`severity=critical`	Guardia e ITSM
`environment=laboratory`	Contacto de formación

Etiquetas para enrutar notificaciones¶

Las etiquetas deben representar información útil para seleccionar el canal.

Ejemplo¶

severity = critical
team = platform
service = payments
environment = production
notification = oncall

Una política podría buscar:

severity = critical
environment = production

y enviar la alerta al sistema de guardia.

Etiquetas recomendadas¶

severity
team
service
environment
region
notification
urgency

No utilizar etiquetas ambiguas¶

Evitar:

important = yes
send = true
route = maybe

Es mejor utilizar valores claros:

severity = critical
notification = oncall

Notificaciones según la severidad¶

Información¶

severity = info

Canales adecuados:

Dashboard.
Canal de observabilidad.
Resumen por correo.
Registro interno.

Advertencia¶

severity = warning

Canales adecuados:

Canal del equipo.
Correo.
Sistema de seguimiento.
Incidencia no urgente.

Crítica¶

severity = critical

Canales adecuados:

Sistema de guardia.
Incidencia prioritaria.
Canal de operaciones.
Correo de escalado.

La severidad debe corresponder a una acción concreta.

Plantillas de mensajes¶

Un mensaje consistente facilita la lectura en cualquier canal.

Plantilla conceptual¶

Estado: {{ estado }}
Alerta: {{ nombre }}
Severidad: {{ severity }}
Equipo: {{ team }}
Servicio: {{ service }}
Entorno: {{ environment }}
Instancia: {{ instance }}

Resumen:
{{ summary }}

Descripción:
{{ description }}

Inicio:
{{ startsAt }}

Dashboard:
{{ dashboardURL }}

Runbook:
{{ runbookURL }}

La sintaxis real de las variables depende de Grafana y del tipo de integración.

Mensaje breve para chat¶

[FIRING] HighCPUUsage
server-01:9100 supera el 90 % de CPU.
Equipo: systems
Severidad: warning
Runbook: https://example.com/runbooks/high-cpu

Mensaje para una incidencia¶

Título:
[critical] NodeExporterDown en server-01:9100

Descripción:
El objetivo no responde a Prometheus.

Equipo:
systems

Entorno:
production

Inicio:
2026-09-24 18:10

Acción:
Consultar el runbook de disponibilidad.

Agrupación y repetición¶

Cuando se activan varias alertas, Grafana puede agruparlas.

Ejemplo¶

HighCPUUsage:
- server-01
- server-02
- server-03

Ventajas¶

Reduce mensajes.
Facilita identificar un incidente común.
Evita saturar los canales.

Riesgos¶

Puede ocultar una alerta concreta.
Puede retrasar la entrega.
Puede dificultar la correlación.
Puede crear una incidencia demasiado amplia.

Pruebas necesarias¶

Comprobar:

¿Las alertas se agrupan por servicio?

¿Se agrupan por instancia?

¿Se agrupan por severidad?

¿Se envían repetidamente?

¿La recuperación se incluye en el grupo?

Recuperaciones¶

Una integración puede recibir tanto activaciones como recuperaciones.

Activación¶

[FIRING] HighApplicationLatency

Recuperación¶

[RESOLVED] HighApplicationLatency

Sistemas de incidencias¶

La recuperación puede:

Añadir un comentario.
Cambiar la prioridad.
Resolver la incidencia.
Cerrar automáticamente el ticket.
Dejar la incidencia abierta para revisión.

La acción debe definirse con cuidado. No siempre es adecuado cerrar automáticamente una incidencia crítica.

Automatizaciones mediante webhook¶

Un webhook puede activar una automatización.

Ejemplos¶

Crear una incidencia.
Publicar un mensaje.
Añadir una entrada en un sistema de cambios.
Ejecutar un flujo de aprobación.
Actualizar una CMDB.
Registrar un evento.
Activar una función interna.

Precaución¶

Una alerta no debería ejecutar automáticamente acciones destructivas sin controles.

Ejemplo peligroso:

Alerta de disco lleno
    |
    v
Borrar archivos automáticamente

Antes de automatizar una acción se deben considerar:

Falsos positivos.
Permisos.
Reversibilidad.
Auditoría.
Aprobación.
Impacto del error.
Condiciones de seguridad.

Ejemplo de sesión 1: crear un webhook de laboratorio¶

Objetivo¶

Enviar una alerta a un receptor HTTP controlado.

Requisitos¶

Endpoint de laboratorio.
URL HTTPS.
Método de autenticación.
Acceso al receptor.
Permisos para crear contactos.

Pasos¶

Preparar el endpoint.
Crear un contacto de tipo webhook.
Introducir la URL.
Configurar la autenticación.
Guardar.
Ejecutar la prueba.
Revisar el código HTTP.
Revisar el payload.
Activar una alerta de laboratorio.
Confirmar la recepción.
Documentar el resultado.

Registro¶

Nombre del contacto:

Endpoint:

Tipo de autenticación:

Código de la prueba:

Nombre de la alerta:

Payload recibido:

Resultado:

Observaciones:

No guardar el token.

Ejemplo de sesión 2: diagnosticar un webhook con error `401`¶

Objetivo¶

Investigar un error de autenticación.

Situación¶

La prueba del webhook devuelve HTTP 401.

Pasos¶

Confirmar la URL.
Revisar el mecanismo de autenticación.
Comprobar el nombre de la cabecera.
Revisar la credencial mediante el almacén seguro.
Comprobar la fecha de caducidad.
Revisar los permisos del token.
Probar de nuevo.
Revisar los logs del receptor.
Rotar la credencial si se ha expuesto.
Documentar la corrección.

Registro¶

Código inicial:

Mecanismo de autenticación:

Causa:

Corrección:

Código posterior:

Credencial rotada:

Resultado:

Ejemplo de sesión 3: diagnosticar un webhook con error `404`¶

Objetivo¶

Corregir una URL de endpoint incorrecta.

Situación¶

La prueba devuelve HTTP 404.

Posibles causas¶

Ruta incorrecta.
Nombre del servicio incorrecto.
Entorno equivocado.
Endpoint eliminado.
Versión incorrecta de la API.

Pasos¶

Revisar el host.
Revisar la ruta.
Confirmar el entorno.
Consultar la documentación del receptor.
Probar la URL desde un cliente autorizado.
Corregir el contacto.
Ejecutar una nueva prueba.
Registrar el resultado.

Ejemplo de sesión 4: enviar alertas a un canal colaborativo¶

Objetivo¶

Publicar una alerta de laboratorio en un canal compartido.

Configuración conceptual¶

Canal:
#laboratorio-observabilidad

Contacto:
laboratory-chat

Regla:
HighCPUUsage

Etiquetas:
environment = laboratory
team = systems
severity = warning

Pasos¶

Crear el canal.
Obtener el mecanismo de integración autorizado.
Crear el contacto.
Probar el contacto.
Crear o revisar la política.
Activar la alerta.
Revisar el mensaje.
Comprobar que el entorno aparece claramente.
Resolver la alerta.
Revisar el mensaje de recuperación.

Preguntas de análisis¶

¿El mensaje se entiende sin abrir Grafana?

¿Aparecen la instancia y la severidad?

¿Existe un enlace al runbook?

¿El canal recibe demasiados mensajes?

¿La recuperación se distingue de la activación?

Ejemplo de sesión 5: enrutar por severidad¶

Objetivo¶

Enviar cada severidad a un canal distinto.

Contactos¶

laboratory-info-channel
laboratory-warning-channel
laboratory-critical-channel

Políticas¶

severity=info
    → laboratory-info-channel

severity=warning
    → laboratory-warning-channel

severity=critical
    → laboratory-critical-channel

Pasos¶

Crear los contactos.
Probar cada contacto.
Crear las políticas.
Crear una regla de prueba con severidad info.
Comprobar el canal.
Cambiar a warning.
Comprobar el canal.
Cambiar a critical.
Comprobar el canal.
Documentar el resultado.

Tabla¶

Severidad	Contacto esperado	Contacto recibido	Resultado
`info`
`warning`
`critical`

Ejemplo de sesión 6: crear una incidencia mediante webhook¶

Objetivo¶

Enviar una alerta a un sistema de gestión de incidencias de laboratorio.

Escenario¶

Alerta:
NodeExporterDown

Severidad:
critical

Acción esperada:
Crear una incidencia

Pasos¶

Preparar un proyecto de laboratorio.
Crear un contacto webhook.
Configurar el endpoint de creación.
Probar la integración.
Crear una política para severity=critical.
Activar la alerta.
Comprobar que se crea la incidencia.
Revisar el título.
Revisar la descripción.
Resolver la alerta.
Comprobar si se añade un comentario o se actualiza el ticket.
Documentar el resultado.

Registro¶

Identificador de la incidencia:

Título:

Equipo asignado:

Prioridad:

Hora de creación:

Hora de recuperación:

Acción al recuperarse:

Resultado:

Ejemplo de sesión 7: evitar incidencias duplicadas¶

Objetivo¶

Comprobar que una misma alerta no crea varias incidencias innecesarias.

Escenario¶

La alerta permanece activa y se envían varias notificaciones de repetición.

Actividades¶

Activar una alerta de laboratorio.
Observar el primer evento.
Esperar una repetición.
Revisar si se crea una nueva incidencia.
Comprobar el identificador utilizado.
Revisar la lógica del receptor.
Proponer un mecanismo de deduplicación.

Claves posibles¶

alertname + instance + service

o:

fingerprint de la instancia de alerta

Resultado esperado¶

Las repeticiones deben actualizar la incidencia existente o ignorarse de forma controlada, no crear una incidencia nueva para el mismo problema.

Ejemplo de sesión 8: probar una alerta crítica en un sistema de guardia¶

Objetivo¶

Comprobar el camino de una alerta crítica.

Configuración conceptual¶

Regla:
NodeExporterDown

Severidad:
critical

Entorno:
laboratory

Contacto:
laboratory-oncall

Pasos¶

Crear el contacto de laboratorio.
Configurar la política de severidad crítica.
Confirmar el turno de prueba.
Activar la alerta.
Comprobar que llega al primer destinatario.
Confirmar la alerta, si la plataforma lo permite.
Verificar que no se activa un escalado innecesario.
Recuperar el servicio.
Comprobar el evento de resolución.
Documentar la prueba.

No realizar pruebas de escalado en producción sin autorización.

Ejemplo de sesión 9: revisar una automatización peligrosa¶

Objetivo¶

Identificar riesgos en una integración que ejecuta acciones automáticas.

Situación¶

Alerta de espacio insuficiente
    |
    v
Webhook
    |
    v
Borrado automático de archivos

Preguntas¶

¿Qué ocurre si la métrica es incorrecta?

¿Qué ocurre si el webhook se repite?

¿La acción es reversible?

¿Existe una aprobación?

¿Se registra lo que se ha borrado?

¿La alerta puede activarse por un falso positivo?

¿La automatización tiene permisos excesivos?

Conclusión¶

Las acciones automáticas deben diseñarse con:

Permisos mínimos.
Límites.
Confirmaciones.
Registro.
Pruebas.
Mecanismos de recuperación.
Revisión humana cuando el impacto sea alto.

Ejemplo de sesión 10: comparar canales¶

Objetivo¶

Elegir el canal más adecuado para diferentes situaciones.

Situaciones¶

1. CPU al 75 % durante dos minutos.
2. Servidor de pagos no disponible.
3. Error puntual en un entorno de laboratorio.
4. Incidencia crítica fuera del horario laboral.
5. Informe diario de alertas resueltas.
6. Creación automática de un ticket.

Actividad¶

Asignar un canal:

Situación	Canal recomendado	Justificación
CPU al 75 % durante dos minutos
Servidor de pagos no disponible
Error puntual en laboratorio
Incidencia crítica fuera de horario
Informe diario
Creación automática de ticket

Resultado esperado¶

El alumno debe justificar la elección según:

Urgencia.
Audiencia.
Necesidad de escalado.
Trazabilidad.
Automatización.
Riesgo de ruido.

Diagnóstico general¶

La integración no recibe nada¶

Comprobar:

La regla está activa.
La política coincide.
El contacto es correcto.
No existe un silencio.
La integración está habilitada.
El endpoint es accesible.
La configuración se guardó.

El canal recibe demasiados mensajes¶

Comprobar:

Umbral.
Duración.
Agrupación.
Repetición.
Número de instancias.
Severidad.
Reglas duplicadas.

El mensaje no tiene contexto¶

Comprobar:

Anotaciones.
Etiquetas.
Plantillas.
Variables.
Enlaces.
Nombre de la instancia.

El sistema externo crea duplicados¶

Comprobar:

Identificador de la alerta.
Deduplificación.
Repeticiones.
Agrupación.
Reintentos.
Comportamiento del receptor.

El canal rechaza la petición¶

Comprobar:

Código HTTP.
Autenticación.
Permisos.
Formato del payload.
URL.
Restricciones de red.
Estado del servicio receptor.

La alerta crítica llega a un canal incorrecto¶

Comprobar:

Etiqueta severity.
Etiqueta team.
Etiqueta environment.
Orden de las políticas.
Política predeterminada.
Contacto seleccionado.

Seguridad y privacidad¶

Las notificaciones pueden contener información operativa sensible.

Datos que deben revisarse¶

Nombres de servidores.
Direcciones IP.
URLs internas.
Nombres de usuarios.
Mensajes de error.
Información de clientes.
Datos de aplicaciones.
Rutas internas.
Identificadores de incidencias.

Recomendaciones¶

Enviar solo la información necesaria.
Utilizar canales aprobados.
No publicar secretos.
No incluir tokens en URLs.
Evitar datos personales innecesarios.
Separar canales públicos e internos.
Revisar quién puede leer el canal.
Aplicar cifrado en tránsito.
Auditar integraciones.
Rotar credenciales.

No incluir en una alerta¶

Contraseñas
Tokens
Claves privadas
Cookies
Credenciales de bases de datos
Contenido completo de solicitudes
Datos personales no necesarios

Gestión de credenciales¶

Las integraciones pueden utilizar:

Tokens.
Claves API.
Usuarios y contraseñas.
Firmas.
Certificados.
Secretos compartidos.

Buenas prácticas¶

Utilizar un almacén de secretos.
Aplicar permisos mínimos.
Establecer caducidad.
Rotar credenciales.
Revocar credenciales antiguas.
No reutilizar tokens entre entornos.
Registrar la fecha de rotación.
Auditar el uso.

Documentación segura¶

Correcto:

Contacto:
production-oncall-webhook

Credencial:
Gestionada por el almacén de secretos de producción

Última rotación:
2026-09-01

Propietario:
Equipo de operaciones

Incorrecto:

Token:
abc123-token-real

Evidencias de la práctica¶

Crear el directorio:

mkdir -p ~/laboratorio-grafana/evidencias/otras-notificaciones

Crear una plantilla general:

cat > ~/laboratorio-grafana/evidencias/otras-notificaciones/integracion.txt <<'EOF'
Nombre de la integración:

Tipo:

Entorno:

Propietario:

Equipo destinatario:

Finalidad:

Regla asociada:

Etiquetas utilizadas:

Política asociada:

Fecha de la prueba:

Resultado:

Código HTTP, si procede:

Problemas encontrados:

Corrección:

Fecha de revisión:
EOF

Crear una plantilla de webhook:

cat > ~/laboratorio-grafana/evidencias/otras-notificaciones/webhook.txt <<'EOF'
Nombre del contacto:

Endpoint, sin credenciales:

Método:

Tipo de autenticación:

Código de respuesta:

Nombre de la alerta:

Estado:

Payload recibido, sin secretos:

Resultado:

Observaciones:
EOF

Crear una plantilla de rutas:

cat > ~/laboratorio-grafana/evidencias/otras-notificaciones/rutas.txt <<'EOF'
Severidad:

Equipo:

Entorno:

Contacto esperado:

Contacto utilizado:

Canal recibido:

Resultado:

Explicación:
EOF

Capturas recomendadas:

01-contacto-webhook.png
02-prueba-webhook.png
03-respuesta-http.png
04-canal-colaborativo.png
05-politica-por-severidad.png
06-alerta-critical.png
07-incidencia-creada.png
08-incidencia-actualizada.png
09-alerta-resolved.png
10-rutas-documentadas.png

Antes de guardar capturas, ocultar:

Tokens
Claves API
Contraseñas
URLs privadas
Cabeceras de autenticación
Datos personales innecesarios

Práctica integradora¶

Objetivo¶

Configurar varias rutas de notificación y comprobar que cada alerta utiliza el canal adecuado.

Requisitos¶

Grafana funcionando.
Prometheus configurado.
Una regla de disponibilidad.
Una regla de CPU.
Un receptor webhook de laboratorio o canal colaborativo autorizado.
Permisos para crear contactos y políticas.
Entorno controlado.

Tarea 1: crear contactos¶

Crear tres contactos:

laboratory-info-channel
laboratory-warning-channel
laboratory-critical-webhook

Asignar:

info:
Canal colaborativo de laboratorio

warning:
Canal del equipo de sistemas

critical:
Webhook de gestión de incidencias

Tarea 2: crear políticas¶

Configurar las rutas:

severity=info
    → laboratory-info-channel

severity=warning
    → laboratory-warning-channel

severity=critical
    → laboratory-critical-webhook

Añadir el entorno:

environment = laboratory

Tarea 3: preparar las reglas¶

Regla de CPU¶

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

Etiquetas:

severity = warning
team = systems
environment = laboratory
resource = cpu

Regla de disponibilidad¶

up{job="node_exporter"}

Condición:

Igual a 0

Etiquetas:

severity = critical
team = systems
environment = laboratory
resource = availability

Tarea 4: probar la alerta de CPU¶

Confirmar la regla.
Activar una carga controlada.
Esperar el estado Alerting.
Comprobar el canal de advertencias.
Revisar el contenido.
Resolver la alerta.
Comprobar el evento de recuperación.

Tarea 5: probar la alerta crítica¶

Confirmar que Node Exporter está funcionando.
Detener el servicio:

sudo systemctl stop node_exporter

Esperar el estado Alerting.
Comprobar el webhook o sistema de incidencias.
Registrar el identificador generado.
Iniciar el servicio:

sudo systemctl start node_exporter

Comprobar la actualización o resolución.
Documentar el resultado.

Tarea 6: revisar las rutas¶

Para cada alerta, verificar:

Regla:

Severidad:

Equipo:

Entorno:

Política coincidente:

Contacto seleccionado:

Canal recibido:

Resultado:

Acción de recuperación:

Tabla de resultados¶

Comprobación	Resultado	Observaciones
Contacto informativo creado
Contacto de advertencia creado
Contacto crítico creado
Prueba del canal informativo
Prueba del canal de advertencia
Prueba del webhook crítico
Política `info` creada
Política `warning` creada
Política `critical` creada
Regla de CPU activada
Alerta de CPU llegó al canal correcto
Recuperación de CPU observada
Regla de disponibilidad activada
Incidencia creada
Incidencia actualizada o resuelta
Etiquetas verificadas
Rutas documentadas
Credenciales protegidas
Evidencias guardadas

Buenas prácticas¶

Elegir el canal según la urgencia¶

No todas las alertas necesitan interrumpir a una persona de guardia.

Mantener las rutas simples¶

Una ruta clara es más fácil de entender y diagnosticar.

Evitar duplicados¶

No enviar la misma alerta a demasiados canales sin una razón operativa.

Utilizar etiquetas consistentes¶

Las políticas dependen de las etiquetas.

Probar los contactos individualmente¶

Antes de investigar una regla, comprobar que el contacto funciona.

Probar el flujo completo¶

Una prueba de contacto no sustituye una prueba de regla, política y canal.

Incluir contexto¶

El receptor debe saber:

Qué ocurre.
Dónde ocurre.
Cuándo comenzó.
Qué severidad tiene.
Qué debe revisar.

Utilizar runbooks¶

Un enlace a un procedimiento reduce el tiempo de respuesta.

Configurar recuperaciones¶

La resolución permite confirmar que la situación ha mejorado.

Controlar la agrupación¶

Agrupar reduce el ruido, pero no debe ocultar recursos afectados.

Proteger los secretos¶

Nunca incluir tokens ni claves en capturas o documentos.

Revisar integraciones externas¶

Los servicios cambian sus APIs, permisos y formatos.

Documentar propietarios¶

Cada integración debe tener una persona o equipo responsable.

Revisar contactos obsoletos¶

Eliminar endpoints retirados y rotar credenciales antiguas.

No automatizar acciones destructivas sin control¶

Toda automatización debe ser reversible, auditable y limitada.

Errores frecuentes¶

La alerta no llega al canal esperado¶

Comprobar:

Etiquetas.
Política.
Orden de las políticas.
Contacto.
Entorno.
Silenciamientos.
Agrupación.

El webhook devuelve `401`¶

Comprobar:

Token.
Cabecera.
Permisos.
Caducidad.
Método de autenticación.

El webhook devuelve `404`¶

Comprobar:

URL.
Ruta.
Entorno.
Servicio receptor.
Versión de la API.

El webhook devuelve `429`¶

Comprobar:

Límite de peticiones.
Repeticiones.
Número de alertas.
Agrupación.
Capacidad del receptor.

El webhook devuelve `500`¶

Comprobar:

Logs del receptor.
Formato del payload.
Campos obligatorios.
Dependencias externas.
Estado del servicio.

Se crean incidencias duplicadas¶

Comprobar:

Identificador de deduplicación.
Reintentos.
Repeticiones.
Agrupación.
Lógica del receptor.

El mensaje contiene datos sensibles¶

Comprobar:

Anotaciones.
Plantillas.
Etiquetas.
Logs.
Datos incluidos por defecto.
Permisos del canal.

El sistema de guardia genera demasiado ruido¶

Comprobar:

Severidades.
Duraciones.
Umbrales.
Alertas duplicadas.
Reglas no accionables.
Agrupación.

La incidencia no se actualiza al recuperarse¶

Comprobar:

Identificador de la alerta.
Estado resolved.
Permisos de actualización.
Endpoint de recuperación.
Lógica del sistema ITSM.

Puntos clave¶

Grafana puede enviar alertas mediante canales distintos del correo.
Los webhooks permiten integrar Grafana con aplicaciones externas.
Los canales colaborativos facilitan la comunicación del equipo.
Los sistemas de guardia están destinados principalmente a incidentes urgentes.
Los sistemas ITSM proporcionan trazabilidad y gestión formal.
La política de notificación decide qué contacto se utiliza.
Las etiquetas son fundamentales para enrutar alertas.
Un webhook debe utilizar HTTPS y autenticación.
Las credenciales deben almacenarse de forma segura.
Los códigos HTTP ayudan a diagnosticar fallos de integración.
Un 401 suele indicar un problema de autenticación.
Un 404 suele indicar una URL o ruta incorrecta.
Un 429 suele indicar demasiadas peticiones.
Un 5xx suele indicar un problema en el receptor.
Los sistemas de incidencias deben evitar duplicados.
Las notificaciones de recuperación permiten actualizar el estado del incidente.
Las alertas críticas no deben mezclarse con avisos informativos.
El sistema de guardia no debe recibir alertas que no requieran intervención urgente.
Los canales colaborativos pueden generar ruido si no se controlan.
Las integraciones automáticas deben limitar sus permisos.
Las acciones destructivas requieren controles adicionales.
El payload debe incluir información útil, pero no secretos.
Los contactos de laboratorio y producción deben estar separados.
Toda integración debe probarse, documentarse y revisarse periódicamente.
La elección del canal debe basarse en la acción que se espera del destinatario.

Preguntas de comprobación¶

¿Por qué puede ser necesario utilizar varios canales de notificación?
¿Qué es un webhook?
¿Qué diferencia existe entre un webhook y un correo electrónico?
¿Cuándo utilizarías un canal colaborativo?
¿Cuándo utilizarías un sistema de guardia?
¿Cuándo utilizarías un sistema de gestión de incidencias?
¿Qué significa una respuesta HTTP 401?
¿Qué significa una respuesta HTTP 404?
¿Qué significa una respuesta HTTP 429?
¿Qué puede indicar un error HTTP 500?
¿Cómo evitarías crear incidencias duplicadas?
¿Qué etiquetas utilizarías para enrutar alertas por severidad?
¿Qué diferencia existe entre una alerta activa y una incidencia creada?
¿Qué información debería incluir un payload?
¿Qué información no debe incluirse en un payload?
¿Por qué es importante utilizar HTTPS?
¿Qué revisarías si una alerta llega a un canal incorrecto?
¿Qué ventajas tiene una notificación de recuperación?
¿Qué riesgos tiene enviar demasiadas alertas a un sistema de guardia?
¿Cómo probarías un webhook?
¿Cómo comprobarías que un sistema ITSM actualiza una incidencia?
¿Qué controles aplicarías antes de automatizar una acción?
¿Por qué deben separarse los contactos de laboratorio y producción?
¿Qué evidencias guardarías durante la práctica?
¿Qué características debe tener una integración de notificación segura y mantenible?

Resultado esperado¶

Al finalizar esta sección, el alumno debe ser capaz de seleccionar, configurar y probar diferentes canales de notificación.

El flujo final será:

Clasificar la alerta
      |
      v
Asignar etiquetas
      |
      v
Seleccionar la política
      |
      v
Elegir el contacto
      |
      v
Probar la integración
      |
      v
Activar una alerta de laboratorio
      |
      v
Comprobar la entrega
      |
      v
Comprobar la recuperación
      |
      v
Revisar errores y duplicados
      |
      v
Documentar el resultado

Una integración está correctamente configurada cuando:

Utiliza el canal adecuado para la severidad.
La política coincide con las etiquetas.
El contacto puede entregar mensajes.
El receptor autentica correctamente la petición.
El payload contiene información suficiente.
No se exponen secretos.
Las alertas se deduplican correctamente.
Las recuperaciones se procesan de forma adecuada.
Las incidencias se actualizan cuando corresponde.
Las acciones automáticas tienen controles.
El propietario y el procedimiento están documentados.

La mejor integración no es la que envía más mensajes. Es la que entrega la información adecuada, al equipo adecuado, por el canal adecuado y en el momento en que puede convertirse en una acción útil.

Otras formas de notificación¶

Objetivos¶

Introducción¶

Ejemplo¶

Tipos de notificación¶

Webhook¶

Canales colaborativos¶

Sistemas de guardia¶

Sistemas de gestión de incidencias¶

Integraciones personalizadas¶

Diferencia entre los canales¶

Webhooks¶

Qué es un webhook¶

Flujo de un webhook¶

Respuestas habituales¶

Payload de un webhook¶

Ejemplo conceptual¶

Información útil¶

Seguridad de los webhooks¶

Riesgos¶

Buenas prácticas¶

Ejemplo incorrecto¶

Ejemplo preferible¶

Probar un webhook¶

Objetivo¶

Pasos¶

Registro¶

Canales colaborativos¶

Ejemplo conceptual¶

Ventajas¶

Riesgos¶

Recomendaciones¶

Microsoft Teams, Slack y herramientas similares¶

Procedimiento general¶

Información que debe aparecer¶

Sistemas de guardia¶

Qué es un sistema de guardia¶

Cuándo utilizarlo¶

Cuándo no utilizarlo¶

Fatiga de alertas¶

Integraciones con sistemas de incidencias¶

Flujo de ejemplo¶

Precaución: duplicados¶

Integraciones con sistemas de guardia e incidencias¶

Ejemplo¶

Ejemplo de rutas¶

Etiquetas para enrutar notificaciones¶

Ejemplo¶

Etiquetas recomendadas¶

No utilizar etiquetas ambiguas¶

Notificaciones según la severidad¶

Información¶

Advertencia¶

Crítica¶

Plantillas de mensajes¶

Plantilla conceptual¶

Mensaje breve para chat¶

Mensaje para una incidencia¶

Agrupación y repetición¶

Ejemplo¶

Ventajas¶

Riesgos¶

Pruebas necesarias¶

Recuperaciones¶

Activación¶

Recuperación¶

Sistemas de incidencias¶

Automatizaciones mediante webhook¶

Ejemplos¶

Precaución¶

Ejemplo de sesión 1: crear un webhook de laboratorio¶

Objetivo¶

Requisitos¶

Pasos¶

Registro¶

Ejemplo de sesión 2: diagnosticar un webhook con error 401¶

Objetivo¶

Situación¶

Pasos¶

Registro¶

Ejemplo de sesión 2: diagnosticar un webhook con error `401`¶

Ejemplo de sesión 3: diagnosticar un webhook con error `404`¶