Que el operador sepa identificar si una alerta en Zabbix es válida o no, con base en cuatro condiciones mínimas que deben cumplirse simultáneamente.
Elemento requerido | ¿Por qué es indispensable? | Ejemplo de fallo | |
---|---|---|---|
✅ Ítem activo y actualizado | La alerta se basa en datos reales. Sin datos, no hay evaluación posible. | El ítem dejó de recolectar hace 2 horas | |
✅ Trigger funcional | Sin condición lógica válida, no se puede detectar anomalías. | El trigger tiene un umbral mal definido | |
✅ Acción habilitada | Sin acción, no se ejecuta ninguna notificación o respuesta automática. | Acción deshabilitada por error | |
✅ Media Type configurado | Es el canal para que la alerta llegue al operador. | El bot de Telegram está mal configurado | |
➕ Operador con criterio técnico | Para interpretar correctamente la alerta y actuar en consecuencia | El operador no sabe distinguir falsos |
Caso entregado:
“No llegó la alerta de espacio en disco del servidor
bd-thv01
. El disco se llenó, pero nadie fue notificado.”
Indicaciones:
Elemento | ¿Estaba presente? | ¿Cómo lo verificarías? |
---|---|---|
Ítem vfs.fs.size |
❓ | ¿Última actualización? ¿Intervalo activo? |
Trigger de espacio bajo | ❓ | ¿Existe? ¿Está habilitado? ¿Tiene umbral lógico? |
Acción de disco | ❓ | ¿Está activa? ¿Asociada al grupo correcto? |
Media Type (correo) | ❓ | ¿Está funcionando? ¿Usuario tenía media? |
Operador final | ❓ | ¿Tenía permisos? ¿Estaba en el grupo de acción? |
“Una alerta no es confiable solo porque existe. Es confiable si tiene respaldo técnico y llega a alguien que sabe interpretarla.”
El operador sabe validar una alerta antes de confiar en ella.
Puede revisar paso a paso por qué una alerta no fue generada o enviada.
Empieza a desarrollar criterio técnico operativo.