4. Zabbix Server - funciones, dependencias, procesos internos

Objetivo técnico-pedagógico

Comprender el rol central del Zabbix Server dentro del ecosistema. Identificar qué tareas realiza, cómo se estructura internamente y qué consecuencias tiene su caída parcial o total.

El operador debe saber:

• Qué hace el servidor

• Qué procesos lo componen

• Qué logs consultar si hay fallas

• Qué síntomas indican sobrecarga o mal funcionamiento

🧩 Introducción conceptual

El Zabbix Server no solo "muestra alertas".

Es el núcleo lógico y operativo del sistema: recibe datos, los procesa, decide si son normales o anómalos, genera eventos, ejecuta acciones, registra histórico y mantiene limpio el sistema.

🧠 Sin Zabbix Server, no hay evaluación, no hay triggers, no hay eventos, no hay alertas.

⚙️ ¿Qué es el Zabbix Server?

• Es un servicio centralizado (proceso zabbix_server) que coordina todos los demás componentes del sistema.

• Se comunica con:   * Agentes Zabbix (activo o pasivo)

    * Bases de datos (PostgreSQL, MySQL, TimescaleDB, etc.)

    * Frontend web

    * Zabbix Proxies

    * APIs externas, scripts, notificaciones

• Su archivo de configuración principal es:   /etc/zabbix/zabbix_server.conf

Funciones principales del Zabbix Server

🧬 Estructura interna: procesos del Zabbix Server

Zabbix Server está compuesto por decenas o cientos de procesos hijos, cada uno con una tarea específica. Estos procesos se definen en el archivo zabbix_server.conf mediante parámetros como:

StartPollers=12

StartTrappers=6

StartAlerters=3

...

Procesos críticos que todo operador debe conocer

Ejemplo visual: monitoreo de un servidor de aplicaciones

Servidor "app01"

  ↓

Zabbix Agent (pasivo)

  ↓

Item: system.cpu.util[,user]

  ↓

Poller del Zabbix Server consulta valor cada 60s

  ↓

Trigger: CPU > 90% durante 5 min

  ↓

Si cumple → Evento

  ↓

Escalator lanza acción a grupo "TI"

  ↓

Alerter ejecuta media type → Telegram

  ↓

Operador recibe alerta

¿Qué procesos estuvieron involucrados?

Poller, trigger evaluator, escalator, alerter

¿Dónde ver los procesos?

1. Comando en consola:

ps aux | grep zabbix_server

2. Archivo de log:

tail -f /var/log/zabbix/zabbix_server.log

3. Indicadores comunes de error:

️ Actividad guiada – “¿Qué proceso falta?”

Caso 1:

“Los ítems icmpping de 30 hosts dejaron de actualizarse.”

¿Qué proceso deberías revisar primero?

####### Respuesta

ICMP pinger

Caso 2:

“No llegan notificaciones por correo desde ayer, pero los triggers se disparan correctamente.”

¿Qué proceso deberías validar?

####### Respuesta:

Alerter

Caso 3:

“El historial de métricas de los últimos 2 días está incompleto.”

¿Qué proceso pudo fallar?

####### Respuesta:

History syncer

🧠 Reflexión operativa

“Cuando algo falla en Zabbix, no siempre es culpa del ítem, del host o de la red.

A veces el problema está en el propio corazón del sistema: el servidor y sus procesos.”

El buen operador no espera a que la GUI le diga “No data”: sabe revisar los logs, validar el estado de los procesos y actuar proactivamente.

✅ Resultado esperado

• El operador entiende qué hace realmente el Zabbix Server

• Reconoce los procesos principales que lo componen y sus funciones

• Puede investigar fallos revisando logs y estados de procesos

• Desarrolla criterio técnico proactivo para validar el estado del sistema

Checklist de evaluación del módulo

• [ ] Reconoce el rol del Zabbix Server como núcleo funciona
• [ ] Menciona al menos 3 procesos clave del server y su función
• [ ] Puede identificar un proceso responsable ante una falla específica
• [ ] Entiende el impacto de la caída del Zabbix Server en la operación
• [ ] Sabe cómo consultar el estado y logs del Zabbix Server

🧨 Casos reales de producción causados por fallas internas del Zabbix Server

Propósito pedagógico:

Mostrar al operador que aunque la GUI esté en línea y el host esté encendido, el sistema puede estar fallando desde dentro si los procesos del servidor no están operando correctamente.

Esta sección entrena el pensamiento causa-raíz y prepara al operador para auditar técnicamente el estado interno de Zabbix en situaciones críticas.

Caso 1 – Los triggers no se disparan (fallo silencioso de lógica)

Síntoma observado:

• Los ítems muestran valores anómalos (ej. CPU al 95%, RAM al 92%)

• No se genera ninguna alerta

• El equipo cree que “todo está bien”

• El problema escala cuando un servicio se cae por sobrecarga

Causa:

• El proceso interno de evaluación de triggers (trigger evaluator) dejó de ejecutarse por sobrecarga del sistema o bloqueo en DB

• Zabbix sigue recolectando datos (pollers activos), pero no evalúa las condiciones

🧪 Vlidación:

• El log muestra:

  ```

  slow query: update triggers set ...

  trigger evaluator delayed

  ```

✅ Solución operativa:

• Verificar carga en base de datos (SELECT * FROM pg_stat_activity)

• Verificar si zabbix_server sigue ejecutando el proceso de trigger evaluation

• Reiniciar servicio si está bloqueado y revisar uso de índices en base

  Lección: Ver datos ≠ que el sistema esté funcionando. Si los triggers no evalúan, no hay eventos → no hay alertas.

Caso 2 – Se dejan de recibir alertas (fallo del proceso alerter)

Síntoma observado:

• Triggers se disparan correctamente (se ven en GUI)

• Los eventos aparecen en la pestaña "Problems"

• Pero no se recibe ningún correo ni mensaje en Telegram

Causa:

• El proceso alerter del Zabbix Server se detuvo (por error de red, bug, mal media type, o error de ejecución)

• El frontend sigue funcionando, pero la ejecución de acciones está rota

🧪 Validación:

• En el log:

  ```

  cannot execute media type script: timeout

  alerter process crashed

  ```

• En consola:

  ```bash

  ps aux | grep zabbix_server | grep alerter

  # No aparece ningún proceso activo

  ```

✅ Solución operativa:

• Reiniciar el zabbix_server

• Validar el script o canal de comunicación configurado

• Verificar los logs por errores de permisos, tiempo de espera o comandos mal escritos

  Lección: Los triggers sí se activan, pero sin alerter, el sistema no habla.

Caso 3 – Los ítems dejan de actualizarse (pollers saturados)

Síntoma observado:

• Todos los ítems muestran estado “ZBX” en gris

• La GUI dice “No data”

• El log está creciendo rápidamente

Causa:

• Pollers agotados: hay más ítems que procesos de recolección disponibles

• Configuración de StartPollers=5 para más de 3000 ítems → cuello de botella

• Pollers se van acumulando y se bloquean

🧪 Validación:

• Log muestra:

  ```

  poller got empty result

  poller busy 100%

  cannot assign more items to poller

  ```

• Monitorear con:

  ```bash

  zabbix_get -s 127.0.0.1 -k "zabbix[process,poller,avg,busy]"

  # Resultado cercano o igual a 1.0 = saturado

  ```

✅ Solución operativa:

• Aumentar el valor de StartPollers en zabbix_server.conf

• Dividir ítems en proxies si es viable

• Verificar ítems innecesarios o mal configurados con intervalos excesivos

  Lección: Zabbix puede estar activo, pero si no tiene recursos para recolectar, es como si estuviera ciego.

Caso 4 – GUI lenta o errores 504 (problemas con housekeeping o base de datos)

Síntoma observado:

• La GUI responde muy lento, o muestra errores 504/timeout

• Las consultas a problemas, eventos o históricos tardan minutos

• El equipo cree que es problema del navegador o internet

  Causa:

• El proceso housekeeper está saturado por exceso de datos no eliminados

• También puede ser history syncer escribiendo en disco de forma desordenada

• Base de datos sin compresión o sin políticas de retención (en TimescaleDB)

🧪 Validación:

• Log:

  ```

  housekeeper started cleaning...

  slow delete from history_uint

  disk I/O overload detected

  ```

• Comprobar carga de disco:

  ```bash

  iotop -o

  ```

• Comprobar peso de tablas:

  ```sql

  SELECT relname, pg_size_pretty(pg_total_relation_size(relid))

  FROM pg_catalog.pg_statio_user_tables

  ORDER BY pg_total_relation_size(relid) DESC

  LIMIT 10;

  ```

✅ Solución operativa:

• Activar compresión en TimescaleDB

• Establecer políticas de retención (ej. mantener solo 30 días de histórico)

• Separar disco de logs e histórico si es posible

• Ajustar HousekeepingFrequency, usar DisableHousekeeping + cron externo si es crítico

  Lección: Los datos son valiosos, pero si no se controlan, pueden destruir el rendimiento del sistema.

Caso 5 – Acciones duplicadas o en bucle (escalator descontrolado)

Síntoma observado:

• Se reciben múltiples alertas por un mismo evento

• Acciones como reboot, restart apache se ejecutan varias veces

• La GUI muestra mismo evento con múltiples entradas en el timeline

Causa:

• El proceso escalator mal configurado o ejecutando acciones sin control de condiciones

• El trigger no está cerrado y sigue ejecutando pasos de acción cada cierto tiempo

🧪 Validación:

• Revisar historial de eventos:

  ```

  frontend → Monitoring → Problems → evento → History

  ```

• Revisar log:   ```

  escalator executing step 1

  escalator executing step 2

  ...

  ```

✅ Solución operativa:

• Agregar condiciones adicionales en la acción (ej. solo si not acknowledged)

• Verificar ciclos o loops en las condiciones de triggers y dependencias

• Asegurarse que los problemas se cierran correctamente

  Lección: Automatizar está bien, pero sin condiciones claras, se puede volver una amenaza operativa.

🧠 Cierre del bloque – ¿Qué aprendemos?

*“Zabbix Server puede estar vivo… pero parcialmente paralizado.

Un operador que no conoce sus procesos, actúa como si Zabbix fuera solo una pantalla.

Un operador capacitado entiende que cada alerta es fruto de múltiples engranes funcionando.”*

✅ Resultado esperado adicional

• El operador puede identificar síntomas indirectos de fallas internas

• Sabe relacionar fallas funcionales con procesos internos

• Reconoce que el monitoreo también debe monitorearse