1. Diagrama general del flujo de monitoreo en Zabbix

Objetivo pedagógico

Visualizar el recorrido completo de un dato desde su origen técnico hasta que se convierte en una alerta visible, entendiendo que cada parte del flujo debe estar correctamente configurada para que el sistema funcione.

Introducción conceptual

En monitoreo, nada ocurre por accidente. Cada alerta que vemos pasó por una cadena técnica, desde el host monitoreado hasta la acción automatizada que se ejecuta.

Cuando un operador recibe una alerta, debe entender: ¿Qué dato la generó? ¿Qué regla la disparó? ¿Por qué llegó (o no llegó) a mí?

Diagrama funcional del flujo de monitoreo

![[4.1.1.png]]

Descripción de cada bloque

Componente Rol operativo Errores comunes
Host Dispositivo o sistema a monitorear No está activo o no responde
Zabbix Agent Enlace entre host y Zabbix. Recoge datos del sistema               No instalado, versión incompatible, firewall
Item         Métrica específica (ej. CPU, disco, proceso, ping, log)             Deshabilitado, mal configurado, sin update  
Trigger       Condición lógica que evalúa los datos recolectados                 Fórmula incorrecta, mal umbral              
Evento       Registro de que el trigger cambió de estado (OK → PROBLEMA)         No generado por falta de ítem/trigger        
Problema     Alerta visible en GUI y dashboards                                 No se ve por filtros, severidad oculta      
Acción       Tarea automática ligada al evento (enviar alerta, ejecutar script) No configurada, deshabilitada                
Media Type   Canal de salida (Correo, Telegram, Webhook, SMS, etc.)             Token mal puesto, servidor caído, sin user  
Usuario       Receptor final del evento                                           No vinculado, sin media, permisos mal dados  

️ Actividad – “Rastrea el flujo”

Caso práctico:

Recibiste una alerta de que el CPU del servidor aplicaciones-01 está al 100% desde hace 10 minutos. ¿Qué ruta siguió esa alerta para llegarte? ¿Qué podría haber fallado si no la hubieras recibido?

Indicaciones:

  • Rellena la tabla siguiente con respuestas basadas en el caso:
Etapa ¿Qué componente específico interviene?             ¿Qué verificarías si algo falla?
Item      
Trigger    
Evento    
Acción    
Media Type
Usuario    

️ Actividad – “Rastrea el flujo” - Respuestas ejemplo

Etapa ¿Qué componente específico interviene?             ¿Qué verificarías si algo falla?
Item       system.cpu.util[,user]                           ¿Está habilitado? ¿Reporta datos?                
Trigger     last(/aplicaciones-01/system.cpu.util[,user])>90 ¿Tiene valor reciente? ¿Está activo?              
Evento     Evento generado a las 10:15                         ¿Se disparó? ¿Está ligado al trigger correcto?    
Acción     Enviar alerta a grupo "OPERACIONES"                 ¿Está habilitada? ¿Tiene condiciones válidas?    
Media Type Telegram (bot de alertas)                           ¿Funciona? ¿Token correcto? ¿Zabbix puede enviar?
Usuario     operador.turno1                                   ¿Está en grupo? ¿Tiene el media configurado?      

🧠 Reflexión técnica

“Una alerta confiable no es un accidente, es el resultado de múltiples componentes trabajando en armonía. Si uno falla, la alerta puede no llegar, llegar tarde, o ser incorrecta.”

✅ Resultado esperado

  • El operador puede visualizar y explicar el recorrido completo de una alerta.

  • Es capaz de rastrear un fallo en el flujo, identificando si es problema del ítem, trigger, acción o media.

  • Comprende que ver una alerta ≠ que todo esté bien en el monitoreo.