El flujo interno de procesamiento de datos en Zabbix es el mecanismo multihilo y concurrente mediante el cual el demonio principal (zabbix_server) gestiona el ciclo de vida de la telemetría, desde la adquisición de métricas en bruto hasta la ejecución de acciones automatizadas. Diseñado en C/C++ para ofrecer alta eficiencia y bajo consumo de recursos, este flujo desacopla la recolección de métricas pasivas y activas mediante subprocesos especializados como poller y trapper, automatiza el aprovisionamiento de componentes a través del proceso discoverer, evalúa los disparadores (triggers) para despachar notificaciones con el daemon alerter, y mantiene la integridad de la base de datos controlando el ciclo de vida del almacenamiento histórico con el módulo housekeeper. Comprender la interacción de estos procesos es fundamental para optimizar entornos de monitoreo de alta densidad (medidos en miles de valores por segundo o NVPS) y prevenir cuellos de botella en la memoria intermedia (IPC shared memory).
Arquitectura General de Subprocesos en Zabbix Server
Zabbix Server opera como un proceso maestro que bifurca (forks) múltiples subprocesos o hilos especializados al arrancar. Cada hilo asume una tarea única dentro de la cadena de procesamiento de telemetría, lo que previene que las operaciones I/O lentas o bloqueantes afecten al resto del ecosistema.
El Modelo de Subprocesos Especializados (Daemon Threading)
En lugar de ejecutar un bucle único para todas las tareas de observabilidad, Zabbix asigna grupos independientes de subprocesos dedicados a funciones específicas. La cantidad de hilos por cada proceso se ajusta directamente en el archivo de configuración principal zabbix_server.conf.
- Subprocesos de Recolección (Data Collectors): Hilos enfocados exclusivamente en la obtención de métricas desde dispositivos finales o agentes (pollers, trappers, unreachable pollers, HTTP pollers).
- Subprocesos de Preprocesamiento (Preprocessing Workers): Módulo multihilo introducido para transformar, filtrar y validar los datos en bruto antes de que ingresen al motor de triggers.
- Subprocesos de Evaluación y Almacenamiento (History Syncers): El núcleo de persistencia encargada de escribir las métricas desde la memoria RAM hacia la base de datos relacional y actualizar el estado de los triggers.
- Subprocesos de Gestión y Mantenimiento: Hilos responsables del ciclo de vida del sistema, tales como la autodetección de red (discoverer), el despacho de alertas (alerter) y la purga de datos antiguos (housekeeper).
Gestión de Memoria Compartida (Shared Memory Cache)
Los diferentes subprocesos de Zabbix se comunican entre sí y comparten estado utilizando segmentos de memoria compartida en RAM. Los dos componentes clave dentro de esta arquitectura son:
- Configuration Cache: Almacena una copia de la base de datos estructural (hosts, ítems, triggers, plantillas y macros). Permite que los pollers y trappers validen la configuración sin realizar consultas SQL continuas a la base de datos.
- History Cache & History Index Cache: Regiones de RAM donde los colectores depositan las métricas recién adquiridas antes de que sean procesadas por los Preprocessing Workers y consolidadas por los History Syncers.
Recolección de Métricas: Poller vs. Trapper
La ingesta de datos en Zabbix se clasifica según el sentido de la comunicación inicial entre el motor de monitoreo y la fuente de telemetría. Los subprocesos Poller y Trapper representan los dos pilares de esta ingesta.
Subproceso Poller: Recolección Pasiva (Pull Model)
El Poller es el proceso encargado del monitoreo pasivo. En este esquema, Zabbix Server o Proxy toma la iniciativa e inicia una conexión TCP/UDP hacia el dispositivo objetivo para solicitar el valor de un ítem determinado.
Variantes de Subprocesos Poller
Zabbix divide la carga de sondeo en diferentes tipos de pollers especializados para evitar que comprobaciones lentas bloquen métricas estándar:
StartPollers: Poller genérico para agentes Zabbix pasivos (puerto 10050), comprobaciones simples (ping, puertos TCP) y consultas de comandos remotos.StartPollersUnreachable: Hilos dedicados a sondear únicamente los dispositivos que han dejado de responder. Esto evita que los pollers principales gasten tiempo de espera (timeouts) intentando conectar con equipos fuera de línea.StartSNMPPollers: Hilos optimizados para el procesamiento de peticiones SNMP v1/v2c/v3 a dispositivos de red.StartHTTPPollers: Hilos asíncronos para ejecutar peticiones Web HTTP/HTTPS y analizar respuestas API REST (JSON/XML).StartJavaPollers: Hilos encargados de comunicarse con el demonio Zabbix Java Gateway para la extracción de JMX en aplicaciones Java.
Subproceso Trapper: Ingesta Activa (Push Model)
El Trapper opera de forma reactiva escuchando peticiones entrantes en el puerto TCP 10051 de Zabbix Server o Proxy. En lugar de ir a buscar la información, el Trapper permanece a la espera de que fuentes externas le envíen métricas directamente.
Fuentes de Ingesta del Trapper
- Zabbix Agent (Modo Activo): El agente instalado en el host remoto recolecta localmente sus métricas y las envía en paquetes JSON estructurados hacia el puerto del Trapper.
- Zabbix Sender: Utilidad de línea de comandos (
zabbix_sender) utilizada para integrar scripts personalizados o pipelines CI/CD que inyectan datos directamente a Zabbix. - Zabbix Proxies: Los nodos intermedios concentran la telemetría de redes remotas y la envían en bloque al hilo Trapper del Zabbix Server central.
- Sender Webhooks / SNMP Traps: Recepción de notificaciones entrantes de sistemas de terceros o traps SNMP procesados mediante scripts como
zabbix_trap_receiver.pl.
Comparativa de Rendimiento entre Poller y Trapper
| Criterio | Poller (Pasivo / Pull) | Trapper (Activo / Push) |
|---|---|---|
| Iniciador de Conexión | Zabbix Server / Proxy | Agente / Dispositivo Remoto / Proxy |
| Puerto de Destino | TCP 10050 (en el Agente) / SNMP UDP 161 | TCP 10051 (en Zabbix Server / Proxy) |
| Impacto en Recursos de Zabbix | Alto (mantiene sockets abiertos esperando respuestas) | Bajo (procesa ráfagas de datos entrantes rápidamente) |
| Soporte para Firewalls / NAT | Complejo (requiere abrir puertos en cada host) | Sencillo (solo requiere salida del cliente al puerto 10051) |
| Escalabilidad Máxima (NVPS) | Limitada a entornos medianos | Altamente recomendado para entornos Enterprise |
Descubrimiento Automatizado: El Subproceso Discoverer
El subproceso Discoverer es el componente responsable del aprovisionamiento automático dentro de Zabbix. Su función es escanear rangos de red IP para identificar hosts, servicios y dispositivos, aplicando reglas de descubrimiento de red (Network Discovery Rules).
Flujo de Trabajo del Módulo Discoverer
El subproceso Discoverer ejecuta un análisis periódico basado en las reglas configuradas por el administrador:
- Sondeo de Red: El hilo Discoverer escanea las subredes indicadas buscando puertos abiertos, respuestas ICMP ping, agentes Zabbix activos o respuestas SNMP.
- Generación de Eventos de Descubrimiento: Si el Discoverer detecta un nuevo dispositivo o nota un cambio en un dispositivo existente (ejemplo: un servicio HTTP levantado), genera un evento del tipo Discovery Event.
- Ejecución de Acciones de Descubrimiento (Discovery Actions): El motor de acciones evalúa los eventos del Discoverer y ejecuta operaciones automáticas como:
- Agregar el host a la base de datos de Zabbix.
- Asignar el host a un grupo específico (ej. Linux Servers).
- Vincular plantillas de monitoreo (Templates) automáticamente.
- Enviar notificaciones al equipo de operaciones sobre la incorporación del nuevo equipo.
Diferencia entre Network Discovery y Low-Level Discovery (LLD)
Es indispensable distinguir el subproceso Discoverer del concepto de LLD (Low-Level Discovery):
- Discoverer (Network Discovery): Es un subproceso a nivel de servidor que descubre Hosts y Dispositivos de red independientes dentro de una infraestructura.
- Low-Level Discovery (LLD): Es una lógica de evaluación dentro del flujo de ítems que descubre entidades internas dentro de un host ya existente (ejemplo: montar automáticamente todos los discos del sistema, interfaces de red o contenedores Docker).
Gestión de Alertas y Notificaciones: El Subproceso Alerter
Una vez que una métrica ingresa al sistema, es preprocesada y evaluada por los History Syncers contra los umbrales de los triggers. Si un trigger cambia su estado a PROBLEM, se genera un evento de problema. Aquí entra en juego el subproceso Alerter.
Componentes y Subtipos del Motor de Alertas
El demonio Alerter se encarga de procesar la cola de acciones y enviar notificaciones hacia los destinatarios correspondientes a través de los Media Types configurados. En Zabbix 7.0+, el motor Alerter está optimizado mediante subprocesos paralelos:
StartAlerters: Subprocesos encargados de formatear y despachar los mensajes de alerta.- Webhooks Manager & Workers: Hilos dedicados a ejecutar scripts de integración en JavaScript (ECMAScript E5.1) para enviar notificaciones asíncronas hacia plataformas como Slack, Microsoft Teams, Telegram, Jira o PagerDuty.
- Email / SMS / Script Execution Workers: Hilos que gestionan el envío tradicional mediante servidores SMTP locales o remotos, modems GSM o scripts en bash/python en el sistema de archivos del servidor.
Ciclo de Vida del Escalado de Alertas (Alert Escalation)
El proceso Alerter interactúa directamente con el subproceso Escalator para implementar esquemas complejos de notificación:
«`text
[ Trigger cambia a PROBLEM ]
│
▼
(Generación de Evento)
│
▼
[ Subproceso Escalator ] ───► Evalúa paso de escalación (Ej: Paso 1)
│
▼
[ Subproceso Alerter ] ───► Envia Webhook a Teams / Correo a Turno Noche
│
¿Problema no resuelto en 30 min?
│
├──► [ Paso 2: Escalator ] ──► Envia SMS al Líder de Operaciones
│
[ Problema Resuelto / Trigger OK ]
│
▼
[ Subproceso Alerter ] ───► Envia mensaje de Recuperación (RECOVERY)
OPTIMIZACIÓN DE SUBPROCESOS EN ZABBIX SERVER (zabbix_server.conf)
- Ajuste de Pollers (Pasivos)
Incrementa el número de hilos para sondeo de agentes y checks simples
StartPollers=80 - Ajuste de Pollers SNMP
Dedicado exclusivamente a dispositivos de red
StartSNMPPollers=50 - Ajuste de Trappers (Activos)
Incrementa los receptores para agentes activos, proxies y zabbix_sender
StartTrappers=30 - Ajuste del Descubridor de Red
Hilos para escaneo de subredes (mantener bajo si no hay reglas activas)
StartDiscoverers=5 - Ajuste del Despachador de Alertas
Hilos para envío de notificaciones y Webhooks
StartAlerters=10 - Gestión del Housekeeper
0 = Desactivado (Recomendado cuando se usa TimescaleDB o Particionamiento MySQL)
1 = Activado (Por defecto)
EnableHousekeeper=0
HousekeepingFrequency=1
