En Zabbix, la cadena de monitoreo tiene múltiples eslabones: agente, proxy, server, base de datos, red.
Si alguno falla, el operador debe saber exactamente qué se pierde, qué se conserva, y cómo se verifica.
La disponibilidad del monitoreo no es binaria. Puede haber:
Fallo parcial (se pierden ciertos ítems o hosts)
Fallo total (sin visibilidad ni recolección)
Caídas invisibles (aparente normalidad, sin datos confiables)
Este bloque enseña cómo rastrear las consecuencias de una falla, qué partes del sistema tienen buffering, y qué síntomas permiten detectar pérdidas reales.
Solo los componentes con almacenamiento temporal (buffering) pueden mitigar una caída.
| Componente | ¿Tiene buffering? | ¿Cuánto puede almacenar? |
| ------------- | --------------------- | -------------------------------------------- |
| Zabbix Agent | ❌ No | Ninguno |
| Zabbix Proxy | ✅ Sí (SQLite o MySQL) | Días, según configuración y disco disponible |
| Zabbix Server | ❌ No | Si se cae, no hay procesamiento |
| Base de datos | ✅ Sí (por naturaleza) | Persistencia completa, si recibe los datos |
El proceso zabbix_agentd se detiene en el host app01.
No se recolecta CPU, RAM, disco, procesos, logs.
Todos los ítems del host configurados como Zabbix agent, agent (active) o log.
No hay buffering local → datos se pierden permanentemente.
No se disparan triggers dependientes de esos datos.
Gráficas vacías o con huecos.
nodata(600s) devuelve true.
last value de ítems muestra “No data”.
El trigger de "Agente sin respuesta" puede activarse si está definido:
nodata(/app01/system.cpu.util[,user],300)=1
El proxy proxy-norte-01 pierde conexión con el Zabbix Server por 6 horas.
Sigue monitoreando hosts locales, pero no puede reenviar.
Si el proxy tiene espacio suficiente, nada.
Si el disco o buffer local se llena, se pierden los datos más antiguos del lapso.
Gap de 6h en gráficas al revisar por hora.
Eventos generados con delay.
Tiempo de procesamiento de datos más alto (spike en escalator).
Logs del proxy muestran:
cannot send data to server: no route to host
queue is full, dropping oldest values
Triggers locales (si están habilitados en proxy)
Datos almacenados en disco (proxy_history.db, MySQL)
La base del proxy actúa como amortiguador temporal. Su tamaño define cuánto puede resistir.
El proceso zabbix_server se detiene por error en base de datos.
Sigue funcionando el frontend (por Apache/Nginx), pero no se procesan datos.
Si el Server está inactivo, no se evalúan triggers, no se generan eventos, no se ejecutan acciones.
Los datos pueden seguir llegando desde agentes activos o proxies, pero quedan en espera.
Si la pausa es larga y no hay proxy → datos se pierden.
No aparecen nuevos eventos ni problemas.
Los ítems parecen estar actualizados, pero los triggers no se activan.
Acciones (correos, Telegram) no se ejecutan.
Log del Server muestra:
history syncers delayed
cannot connect to database
Datos que lleguen desde proxies siguen almacenándose ahí
Base de datos no se pierde si no hay corrupción
PostgreSQL se cae o queda en estado “read-only”.
El server sigue ejecutando procesos, pero no puede guardar datos.
Todo lo que ocurre mientras la DB está inactiva.
No se guarda: valores, eventos, triggers, acknowledgment, configuraciones.
En GUI: errores de SQL (PG::ConnectionBad)
En log del server:
cannot insert history data: connection lost
database is not accepting writes
Datos ya existentes siguen disponibles
Proxies siguen recolectando (si existen)
| Componente caído | ¿Se pierden datos? | ¿Se pierden eventos? | ¿Se ejecutan acciones? | ¿Se pueden recuperar datos? |
| ----------------- | --------------------- | -------------------- | ---------------------- | ------------------------------------- |
| Agente | ✅ Sí | ✅ Sí | ✅ Sí | ❌ No, no hay buffer local |
| Proxy | ❌ No (si hay espacio) | ⚠️ Parcial (delay) | ⚠️ Parcial | ✅ Sí, si reenvía después |
| Server | ⚠️ Parcial | ✅ Sí | ✅ Sí | ⚠️ Parcial, depende si proxy almacenó |
| Base de datos | ✅ Sí | ✅ Sí | ✅ Sí | ❌ No si no hubo backup ni proxy |
nodata()* Detecta si un ítem no ha recibido datos en X segundos
```zabbix
nodata(/servidorX/vfs.fs.size[/,free],600)=1
```
* Verifica si hay saltos temporales (no interpolados)
* Útil en ítems de tipo Zabbix agent, SNMP, ping
* GUI → Monitoring → Problems → History
* Ver si hay pausas largas sin eventos ni resoluciones
* Identifican si hay queue acumulada o pérdida de conexión
* Administration → Proxies → Última actualización
* Si pasa de 1-2 minutos, está desconectado
*Cada componente de Zabbix tiene un nivel de resiliencia diferente.
El operador que sabe lo que se pierde (y lo que no), puede evaluar si un incidente es grave, leve o invisible.*
El operador puede detectar si se perdieron datos, eventos o acciones
Reconoce cuál fue el componente fallido y su impacto
Sabe cómo usar nodata(), gráficas y logs para verificar la integridad del monitoreo
Desarrolla pensamiento forense: no solo ver qué pasó, sino qué no se vio