7. Canal de datos - host → agente → proxy → server → base de datos

Objetivo técnico-pedagógico

Comprender en profundidad el recorrido completo de un dato monitoreado, desde que se genera en un host hasta que se almacena en la base de datos de Zabbix.

El operador debe poder:

  • Trazar cada paso y componente involucrado

  • Detectar posibles puntos de falla o pérdida

  • Entender la implicación técnica de cada eslabón en términos de latencia, buffering, confiabilidad y rendimiento

🧭 Introducción conceptual

En Zabbix, una alerta no nace sola.

Antes de que algo aparezca en la GUI, ese valor tuvo que atravesar una cadena de componentes perfectamente sincronizados.

Entender el canal de datos no solo permite resolver problemas.

Permite prevenirlos.

Ruta técnica del dato en Zabbix


┌────────────┐     ┌────────────┐     ┌──────────────┐     ┌──────────────┐     ┌─────────────────┐

│   HOST     │ --> │  AGENTE    │ --> │   PROXY (op) │ --> │   SERVER     │ --> │   BASE DE DATOS  │

└────────────┘     └────────────┘     └──────────────┘     └──────────────┘     └─────────────────┘

🧩 Detalle de cada componente:

1. HOST (origen físico o virtual del dato)

  • Puede ser una máquina física, una VM, un contenedor, un switch, una app en cloud, etc.

  • Aquí ocurre el evento real: sube la CPU, se llena el disco, falla un proceso.

🧠 No todos los hosts tienen agente. Algunos se monitorean vía SNMP, ping, HTTP, etc.

2. ZABBIX AGENT (si está presente)

  • Instancia instalada localmente que recoge datos del sistema operativo.

  • Responde a consultas pasivas (zabbix_get) o empuja datos en modo activo.

  • Ejecuta comandos internos (system.cpu.util, vfs.fs.size, net.tcp.listen, etc.)

  • Preprocesa datos si es necesario (unit conversion, regex, etc.)

    Si no hay agente, la recolección se hace por otros métodos (SNMP, SSH, ICMP, JMX, etc.)

3. ZABBIX PROXY (opcional pero común en producción)

  • Recibe datos del agente si el host fue asignado al proxy.

  • Puede actuar como poller local (modo pasivo) o recibir push (modo activo).

  • Almacena temporalmente los datos en base local (SQLite o MySQL).

  • Envía lotes de datos al Server cada X segundos.

  • Si pierde conexión con el Server, retiene los datos en buffer hasta que pueda reenviar.

    Un proxy puede almacenar días enteros de información si está correctamente configurado.

4. ZABBIX SERVER (núcleo lógico del sistema)

  • Procesa los datos entrantes.

  • Evalúa triggers, genera eventos si es necesario.

  • Ejecuta acciones si un evento lo requiere.

  • Inserta los datos en la base de datos:

  * history_uint → enteros (uso de CPU, RAM libre, etc.)

  * history_float → decimales (temperaturas, carga promedio, etc.)

  * history_str → cadenas cortas (estado de servicio, outputs de comandos)

  * history_text → textos largos (logs, descripciones)

  * history_log → datos de tipo log con timestamps

Cada ítem tiene un tipo de valor que determina dónde se almacena y cómo se visualiza.

5. BASE DE DATOS (PostgreSQL + TimescaleDB, o MySQL, etc.)

  • Es el repositorio central de todo lo que ha ocurrido en Zabbix.

  • Aquí se guardan:

  * Valores recolectados (history)

  * Promedios por hora (trends)

  * Eventos, triggers, usuarios, configuraciones, dashboards, mapas, etc.

🧠 La base de datos es el corazón de la persistencia: si se corrompe o satura, Zabbix se degrada o se vuelve inoperante.

Trayectoria de un dato en contexto real

Ejemplo práctico

El servidor app01 tiene su CPU al 97% desde hace 3 minutos.

  1. El dato se genera en el host app01:

   Proceso java consume 5 cores → sistema operativo lo registra.

  1. El agente recolecta el valor con:

   system.cpu.util[,user] = 97.2

  1. El ítem está definido como tipo Zabbix agent (active) →

   El agente lo envía al Proxy asignado (ej. proxy-norte-01)

  1. El proxy lo guarda en su base local (ej. /var/lib/zabbix/proxy_history.db)

   Luego, cuando tiene conexión, lo reenvía al Server.

  1. El Server recibe el dato, lo compara contra el trigger:

   last(/app01/system.cpu.util[,user]) > 90

  1. Como se cumple, genera un evento y lanza una acción.

  2. Simultáneamente, el valor crudo se guarda en la base de datos en history_float

  3. Minutos después, se agregará a trends como promedio horario.

Puntos críticos donde un dato puede perderse, retrasarse o corromperse

| Punto de fallo                     | Riesgo                                                   | Solución operativa                              |

| ---------------------------------- | -------------------------------------------------------- | ----------------------------------------------- |

| Agente no responde              | El host parece “activo”, pero no recolecta               | Verificar proceso, logs, firewall               |

| Proxy sin conexión              | Datos retenidos, posibles retrasos o truncamiento        | Monitorear buffer y conexión                    |

| Proxy sin espacio local         | SQLite/MySQL local se satura → se pierden datos antiguos | Aumentar almacenamiento o exportar              |

| Server sobrecargado             | Recibe datos tarde o no ejecuta triggers en tiempo       | Monitorear pollers, history syncer, housekeeper |

| Base de datos saturada          | Las inserciones fallan → se pierden datos o eventos      | Indexar, particionar, usar compresión           |

| Hora del sistema desincronizada | Dato llega con timestamp inválido → fuera de rango       | Sincronizar todos los relojes con NTP           |

🧠 Reflexión operativa

*“Cada alerta que vemos es la punta del iceberg.

Debajo, hay una red de procesos, buffers, conexiones y transformaciones que deben mantenerse sanas.

Una alerta confiable solo es posible si todo el canal de datos funciona sin errores.”*

✅ Resultado esperado

  • El operador puede trazar el recorrido de un dato

  • Identifica qué parte del sistema debe revisarse cuando no llegan valores

  • Comprende la función e interdependencia entre agente, proxy, server y base

  • Sabe que el monitoreo también necesita ser monitoreado