Monitorización: Parte 4 — Zabbix

Zabbix — sistema de monitorización “todo en uno”: recolección de datos, almacenamiento, disparadores, alertas, paneles y gestión de acceso reunidos en un mismo producto. Se elige cuando hay que vigilar servidores, equipo de red, bases de datos y sitios desde una única interfaz, sin montar el sistema a partir de componentes separados.

Versiones y licencia

• Zabbix 7.0 LTS (junio de 2024) — rama con soporte a largo plazo: soporte completo hasta el 30 de junio de 2027, correcciones de seguridad hasta el 30 de junio de 2029. Para sistemas en producción conviene elegirla.
• Zabbix 7.4 (junio de 2025) — lanzamiento estándar actual con nuevas funciones y soporte de corta duración.
• Zabbix 6.0 LTS recibe solo correcciones de seguridad hasta febrero de 2027 — es hora de planificar la actualización.

Desde la versión 7.0 Zabbix se distribuye bajo la licencia AGPLv3; antes, desde 2001 se usaba GPLv2. Para una empresa que usa Zabbix internamente no hay diferencia. Las condiciones de AGPL son importantes si modifica el código y ofrece Zabbix como servicio a terceros.

De qué consta Zabbix

• Zabbix Server — proceso central: recibe datos, evalúa disparadores, ejecuta acciones y envía alertas.
• Base de datos — almacena la configuración y el historial. Zabbix 7.4 soporta MySQL y Percona (8.0.30 y posteriores), MariaDB (10.5 y posteriores), PostgreSQL (13 y posteriores) y la extensión TimescaleDB para PostgreSQL. Oracle ya no está soportado; SQLite solo se admite para proxies.
• Interfaz web en PHP — configuración, paneles, informes.
• Agentes en los nodos monitorizados.
• Proxy — recopiladores intermedios para ubicaciones remotas.

Zabbix agent 2

Hay dos agentes. El clásico está escrito en C. Zabbix agent 2 — agente de nueva generación en Go, que va reemplazando al primero:

• todas las comprobaciones se ejecutan mediante plugins, y las comprobaciones de distintos plugins se realizan en paralelo;
• plugins listos para PostgreSQL, MySQL, Redis, MongoDB, Docker y otros sistemas no requieren scripts adicionales;
• el búfer persistente (EnablePersistentBuffer) conserva los datos de comprobaciones activas al reiniciar y ante pérdida de conexión.

Configuración mínima en /etc/zabbix/zabbix_agent2.conf:

Server=192.0.2.10
ServerActive=192.0.2.10
Hostname=web01.example.ru

Server — direcciones desde las que se permiten comprobaciones pasivas (el servidor interroga al agente). ServerActive — a dónde envía el agente los datos en modo activo. Hostname debe coincidir con el nombre del nodo en la interfaz web. Los paquetes del agente, del servidor y de la interfaz web se instalan desde el repositorio oficial siguiendo las instrucciones en zabbix.com/download: allí los comandos se ajustan a la versión de Zabbix, la distribución y la SGBD.

Plantillas

Una plantilla es un conjunto listo de elementos de datos, disparadores, gráficos y reglas de descubrimiento. Por ejemplo, se asocia al nodo la plantilla “Linux by Zabbix agent” y éste obtiene de inmediato decenas de métricas y disparadores razonables: poco espacio en disco, alta carga, reinicio, indisponibilidad del agente.

Las reglas de descubrimiento de bajo nivel (LLD) encuentran automáticamente sistemas de archivos, interfaces de red, servicios y crean sus métricas para cada uno. Existen plantillas oficiales para sistemas operativos, SGBD, servidores web, equipo de red vía SNMP y servicios en la nube.

Conviene construir plantillas propias sobre las estándar y almacenarlas en exportaciones (YAML) para trasladarlas entre instalaciones.

Proxies

Zabbix Proxy recopila datos en lugar del servidor y los transmite en bloques. Es necesario cuando:

• los nodos están en otra oficina o centro de datos y la conexión con el servidor es inestable: el proxy acumula datos y los envía tras recuperarse el canal;
• hay miles de nodos monitorizados y hay que distribuir la carga;
• los nodos están en una red aislada a la que el servidor no puede conectarse directamente.

En la versión 7.0 aparecieron grupos de proxy con balanceo y tolerancia a fallos: los nodos se asignan a un grupo y, ante la caída de un proxy, los demás asumen su carga.

Otras funcionalidades

• Recolección de datos por distintos métodos: agente, SNMP, IPMI, consultas HTTP, SSH, ODBC, JMX para aplicaciones Java.
• Descubrimiento de red y autoregistro: nuevos dispositivos y agentes se añaden automáticamente según reglas.
• Escenarios web y comprobaciones de navegador: en 7.0 se introdujo el monitoreo sintético mediante navegador con capturas de pantalla.
• Escalaciones: si el problema no se resuelve en el tiempo establecido, la alerta pasa al siguiente nivel.
• Autenticación de dos factores en la interfaz web (TOTP y Duo) desde la versión 7.0.

Ventajas

• Todo en un mismo producto, con una interfaz única y gestión de permisos centralizada.
• Cientos de plantillas listas, incluidas para equipo de red.
• Dependencias entre disparadores: si cae un switch no se reciben alertas de todos los servidores conectados a él.
• Documentación madura y una gran comunidad.

Desventajas

• Carga en la base de datos. En instalaciones grandes el historial ocupa la mayor parte del espacio y de la carga. Ayudan TimescaleDB, plazos de retención razonables y, para datos poco frecuentes, aumentar el intervalo de recolección.
• Complejidad en la configuración inicial. Hay que entender nodos, elementos de datos, disparadores y acciones.
• Menos flexibilidad para el trabajo con datos que PromQL: un análisis complejo por etiquetas resulta más cómodo con Prometheus y Grafana. Grafana, a su vez, puede conectar Zabbix como fuente de datos mediante un plugin.

Errores típicos

• Un nodo — un conjunto de comprobaciones configuradas manualmente. Las comprobaciones se configuran en cada nodo en lugar de usar una plantilla; al cabo de seis meses la configuración difiere.
• El historial se guarda para siempre. El tamaño de la base de datos crece hasta cientos de gigabytes. Mantenga historial detallado por una semana y use tendencias para periodos largos.
• Todos los disparadores con el mismo nivel de severidad. El responsable recibe un flujo de “catástrofes” y deja de reaccionar.
• Actualizar sin comprobar. El salto entre versiones mayores cambia el esquema de la base de datos; antes de actualizar se necesita copia de seguridad y probar en una réplica de prueba.