Zabbix: qué es, cómo funciona y cómo se configura

Zabbix es el sistema de monitoreo libre más extendido en salas de servidores de empresa, y también uno de los que más se configuran mal. Esta guía explica qué hace, cómo está construido, cómo se instala, cómo se vigila el primer equipo y, sobre todo, cómo se dimensiona antes de que la base de datos crezca sin control. Todo con un caso numérico que se puede reutilizar para calcular su propia instalación.

Además, está escrita en dos niveles. Si usted decide el presupuesto y no toca la consola, los primeros apartados y las tablas de comparación le bastan. En cambio, si administra la plataforma, encontrará los archivos de configuración, las expresiones de los disparadores y las cuentas que hay que hacer antes de comprar disco.

Qué es Zabbix y qué problema resuelve

Zabbix es una plataforma de monitoreo que recoge métricas de servidores, equipos de red, bases de datos, servicios web y aplicaciones, las guarda con su historia, las compara con umbrales y avisa cuando algo se sale de lo previsto. Es decir, sustituye la pregunta «¿va bien todo?» por una respuesta medida y con fecha.

El proyecto nació en 2001 y hoy es software libre. Desde la versión 7.0 se distribuye bajo la licencia AGPLv3; hasta la 6.4 fue GPLv2. Por lo tanto, no hay coste de licencia por equipo vigilado: el gasto está en el servidor que lo ejecuta, en el disco que guarda la historia y en el tiempo de quien lo configura. Y ese último punto es, sobre todo, el que casi siempre se subestima.

Conviene también decir qué no es. No es un sistema de inventario, aunque recoja datos de inventario; no es un gestor de tickets, aunque sepa abrirlos por API; y no sustituye a una política de copias, como recuerda la guía sobre los tipos de backup. Vigilar que el respaldo terminó no es lo mismo que poder restaurarlo.

Los componentes de Zabbix y sus puertos

Antes de instalar nada conviene entender las piezas, porque la mitad de los problemas de un despliegue son en realidad un cortafuegos cerrado. Una instalación mínima necesita tres componentes; las demás se añaden cuando hacen falta.

Así pues, los dos números que hay que memorizar son 10050 y 10051. El primero es el que escucha el agente y por el que entra el servidor a pedirle datos. El segundo es el que escucha el servidor, y por él entran tanto los agentes en modo activo como los proxies. Confundirlos es el error de primer día más repetido.

Servidor, base de datos y frontal

Los tres pueden convivir en una sola máquina y, en instalaciones pequeñas, así se hace. Sin embargo, la base de datos es la que primero sufre: es quien escribe cada valor recogido. Por eso, en cuanto la instalación crece, lo primero que se separa es el motor de base de datos, no el frontal.

La documentación oficial de requisitos admite MySQL 8.0.30 o superior, MariaDB desde la 10.5, PostgreSQL desde la 13 y, sobre este último, la extensión TimescaleDB desde la 2.13. El frontal necesita PHP entre 8.0 y 8.5. Esa lista cambia con cada versión, así que conviene consultarla antes de elegir el sistema operativo base.

Agente, proxy y pasarela

En concreto, el agente es un servicio ligero que se instala en el equipo vigilado y responde preguntas sobre él: carga de CPU, memoria libre, espacio en disco, estado de un servicio, contenido de un archivo de registro. Existen dos generaciones; sin embargo, hoy la recomendada es el agente 2, escrito en Go, con arquitectura de complementos y capacidad de recolección paralela.

El proxy, por su parte, es un intermediario que recoge en nombre del servidor y le entrega los datos ya reunidos. Resulta imprescindible cuando hay sedes remotas, redes detrás de NAT o enlaces poco fiables, porque el proxy guarda en su propia base de datos local mientras el enlace está caído y descarga todo cuando vuelve.

Las formas de recoger datos que admite Zabbix

Una confusión habitual es creer que Zabbix necesita agente en todo. No es así: la lista oficial de tipos de elemento incluye diecisiete métodos distintos, y buena parte funciona sin instalar nada en el destino. Estos son los que aparecen en casi cualquier instalación.

Los dos últimos merecen atención, porque son los que ahorran carga. Un elemento dependiente toma una única respuesta —por ejemplo, un JSON de veinte campos— y la reparte en veinte métricas sin veinte consultas. Un elemento calculado, en cambio, deriva un valor nuevo de los que ya existen, como el porcentaje de uso a partir del espacio libre y el total.

Agente pasivo y agente activo

Esta distinción decide qué reglas de cortafuegos hacen falta, así que conviene tenerla clara. En una comprobación pasiva manda el servidor: abre una conexión hacia el puerto 10050 del agente y le pide un dato concreto. En una comprobación activa manda el agente: se conecta al puerto 10051 del servidor, pide la lista de lo que debe medir y después le envía los resultados por su cuenta.

Por eso, cuando el equipo vigilado está detrás de NAT o en una red a la que el servidor no llega, la respuesta es el modo activo. Según la documentación de comprobaciones activas y pasivas, basta con rellenar el parámetro ServerActive en el agente; el ritmo con que pide su lista lo fija RefreshActiveChecks.

El vocabulario de Zabbix, en una tabla

La curva de aprendizaje de esta herramienta no está en la instalación, sino en sus nombres. En resumen, quien entiende estos siete términos entiende la consola entera.

De estos, la plantilla es la que cambia el resultado del proyecto. Configurar un servidor a mano lleva una hora; aplicarle una plantilla lleva diez segundos y deja los mismos elementos, los mismos umbrales y las mismas gráficas en los cien servidores siguientes. El catálogo oficial de integraciones reúne plantillas mantenidas por fabricante, de Cisco y MikroTik a Dell o Zyxel, así que rara vez hay que empezar de cero.

Qué versión de Zabbix elegir

Además, el proyecto mantiene dos ritmos a la vez, y elegir mal cuesta una migración a destiempo. Las versiones estándar salen cada seis meses y se mantienen doce; las LTS salen cada año y medio y se mantienen cinco años. Estos son los datos publicados en la política de ciclo de vida.

Por lo tanto, la regla práctica es sencilla. Para producción, una LTS: hoy la 7.0, y la 8.0 cuando esté publicada y haya pasado un par de versiones de corrección. Las estándar como la 7.4 tienen sentido cuando se necesita una función concreta que acaba de llegar, siempre asumiendo que habrá que actualizar dentro de un año.

Instalar Zabbix en Ubuntu paso a paso

En primer lugar, el camino corto es el repositorio oficial. Primero se añade, después se instalan los paquetes del servidor, el frontal y el agente 2. Cada combinación de versión y distribución tiene su propio paquete, así que la URL exacta la genera el asistente de descarga del proyecto; la que sigue corresponde a la 7.4 sobre Ubuntu 24.04.

# 1. Repositorio oficial
wget https://repo.zabbix.com/zabbix/7.4/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.4+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_latest_7.4+ubuntu24.04_all.deb
sudo apt update

# 2. Servidor, frontal, scripts de base de datos y agente
sudo apt install -y zabbix-server-mysql zabbix-frontend-php \
                    zabbix-apache-conf zabbix-sql-scripts zabbix-agent2

Cargar el esquema y arrancar

Después toca la base de datos. El esquema se carga una sola vez y tarda unos minutos, porque crea varios centenares de tablas.

sudo mysql -uroot -p
  create database zabbix character set utf8mb4 collate utf8mb4_bin;
  create user zabbix@localhost identified by 'una-clave-larga-y-unica';
  grant all privileges on zabbix.* to zabbix@localhost;
  set global log_bin_trust_function_creators = 1;
  quit;

zcat /usr/share/zabbix/sql-scripts/mysql/server.sql.gz \
  | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix

# Se devuelve el permiso temporal a su valor original
sudo mysql -uroot -p -e "set global log_bin_trust_function_creators = 0;"

Ese log_bin_trust_function_creators hace falta solo durante la carga del esquema, porque crea funciones almacenadas. Dejarlo activado después es un riesgo innecesario, así que el último comando lo devuelve a cero. Por último, se escribe la contraseña en /etc/zabbix/zabbix_server.conf y se arrancan los servicios.

sudo sed -i 's/^# DBPassword=.*/DBPassword=una-clave-larga-y-unica/' \
     /etc/zabbix/zabbix_server.conf
sudo systemctl restart zabbix-server zabbix-agent2 apache2
sudo systemctl enable  zabbix-server zabbix-agent2 apache2

A partir de ahí, el frontal responde en http://servidor/zabbix y pide completar un asistente de cuatro pasos. El usuario inicial es Admin con contraseña zabbix, y cambiarla es literalmente lo primero que hay que hacer, antes de dar de alta ningún equipo.

Una prueba rápida con contenedores

Si lo que quiere es probar antes de decidir, el proyecto publica imágenes oficiales y el montaje entero cabe en un archivo. Quien no haya trabajado con esta forma de desplegar encontrará el contexto en la guía de Docker Compose.

services:
  db:
    image: mysql:8.4
    environment:
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: clave-de-prueba
      MYSQL_ROOT_PASSWORD: clave-de-prueba-root
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_bin

  server:
    image: zabbix/zabbix-server-mysql:alpine-7.4-latest
    environment:
      DB_SERVER_HOST: db
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: clave-de-prueba
    ports: ["10051:10051"]
    depends_on: [db]

  web:
    image: zabbix/zabbix-web-nginx-mysql:alpine-7.4-latest
    environment:
      ZBX_SERVER_HOST: server
      DB_SERVER_HOST: db
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: clave-de-prueba
      PHP_TZ: America/Bogota
    ports: ["8080:8080"]
    depends_on: [server]

En cualquier caso, eso sirve para evaluar, no para producir. Una instalación real necesita volúmenes persistentes para la base de datos, copias de esa base y una política de actualización; sin ellos, la primera recreación del contenedor se lleva toda la historia por delante.

El primer equipo vigilado con Zabbix

A continuación, con el servidor en pie, toca dar de alta un servidor Linux. Se instala el agente 2, se le dice a quién responder y se cifra la conversación con una clave precompartida, que es el mecanismo más sencillo de los que admite el cifrado de comunicaciones.

# En el equipo que se va a vigilar
sudo apt install -y zabbix-agent2
openssl rand -hex 32 | sudo tee /etc/zabbix/agent.psk
sudo chown zabbix:zabbix /etc/zabbix/agent.psk
sudo chmod 600 /etc/zabbix/agent.psk

Los permisos importan: el archivo lo lee el propio servicio del agente, que corre como el usuario zabbix, de modo que 600 con ese propietario es correcto y cualquier otro usuario del sistema queda fuera. A continuación se edita /etc/zabbix/zabbix_agent2.conf.

Server=10.20.0.10
ServerActive=10.20.0.10
Hostname=srv-app-01
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=PSK-srv-app-01
TLSPSKFile=/etc/zabbix/agent.psk

Después, en la consola, se crea el host con ese mismo nombre —debe coincidir exactamente con Hostname—, se le asigna la interfaz del agente, se pega la misma clave en la pestaña de cifrado y se le aplica la plantilla Linux by Zabbix agent. En cuestión de un minuto aparecen las primeras gráficas, con unos cuarenta elementos ya configurados.

Disparadores: avisar sin volverse ruido

Aquí se decide si el sistema será útil o si acabará silenciado. Un disparador es una expresión que devuelve verdadero o falso, y su calidad depende de una cosa: que mire una ventana de tiempo, no un instante.

# Mal: salta con un pico de un segundo
last(/srv-app-01/vfs.fs.size[/,pfree])<10

# Bien: exige cinco minutos por debajo del umbral
min(/srv-app-01/vfs.fs.size[/,pfree],5m)<10

# Carga sostenida durante diez minutos
min(/srv-app-01/system.cpu.load[all,avg5],10m)>4

# El servicio dejó de responder en las tres últimas consultas
nodata(/srv-app-01/agent.ping,3m)=1

Las funciones min(), max() y avg() sobre una ventana evitan la mayor parte de los avisos falsos. Además, cada disparador lleva una severidad, y esa severidad es la que después decide a quién se avisa y a qué hora.

Por último, están las dependencias, que son el remedio contra la tormenta de avisos. Si el enlace de una sede cae, sus treinta equipos dejan de responder a la vez. Declarando que el disparador de cada equipo depende del disparador del router, el sistema envía un aviso en lugar de treinta y uno.

Alertas que alguien lee

Un aviso solo sirve si llega a una persona que puede actuar. En concreto, el recorrido tiene tres piezas: el tipo de medio define el canal, el usuario define el destinatario y su horario, y la acción une condición y destinatario. Zabbix trae integraciones listas para correo, Telegram, Slack, Teams, Jira y webhooks genéricos.

Sin embargo, la pieza que más se olvida es el escalado. Una acción puede enviar el primer aviso al técnico de turno, repetirlo a los quince minutos si nadie lo reconoce y avisar al coordinador a la media hora. Esa es exactamente la lógica de una mesa de servicio con niveles, y por eso el monitoreo y el soporte de TI se diseñan juntos y no por separado.

Cuándo hace falta un proxy de Zabbix

Un proxy es, en definitiva, un servidor intermedio con su propia base de datos que recoge por delegación. Aunque parezca una complicación, en tres situaciones resuelve más de lo que cuesta.

El proxy funciona en dos modos, igual que el agente. En modo activo es él quien se conecta al servidor, lo que evita abrir puertos entrantes en la sede remota; en modo pasivo es el servidor quien va a buscarlo. En una red bien segmentada, como la que describe la guía de red de área local, el modo activo es casi siempre la elección correcta.

Dimensionar Zabbix: el cálculo que evita sorpresas

Ahora bien, esta es la parte que casi nadie hace y la que explica la mayoría de las instalaciones que se vuelven lentas a los seis meses. Concretamente, la unidad de medida es el NVPS, valores nuevos por segundo, y se calcula dividiendo el número de elementos entre su intervalo de consulta. Nada más.

El caso de 120 equipos, paso a paso

Así pues, tomemos un caso concreto y reutilizable: una empresa con 120 equipos repartidos así.

Ese valor de 145 NVPS significa 12.528.000 valores al día y, con un mes de historia detallada, unos 388 millones de filas vivas en la tabla de históricos. Es decir, la cuenta es directa: 145 × 86.400 segundos, por 31 días.

Ahora viene lo interesante. Si alguien decide bajar el intervalo de los servidores de 60 a 30 segundos «para verlo mejor», el total pasa a 225 NVPS: un 55 % más de escritura a cambio de media docena de métricas que nadie mira dos veces al día. Ese es el momento exacto en que conviene preguntarse qué se gana.

Las cifras de hardware de la columna final son las que publica el propio proyecto en sus requisitos. Y conviene añadir dos medidas que ahorran mucho disco: reducir la retención del histórico —siete o catorce días suelen bastar, porque las tendencias horarias se guardan aparte durante meses— y activar el particionado con TimescaleDB, que borra por partición en lugar de fila a fila.

Zabbix frente a otras herramientas

La comparación honesta no busca un ganador, sino el encaje. Cada una de estas herramientas nació para un problema distinto, y mezclarlas es más habitual que elegir una sola.

El malentendido más común es oponer Grafana a Zabbix, cuando en realidad se complementan: Grafana es una capa de paneles que se conecta a orígenes de datos, y Zabbix puede ser uno de ellos. De hecho, muchas instalaciones usan la consola nativa para operar y Grafana para el tablero que mira la dirección.

Ocho errores frecuentes al montar Zabbix

Además, el cuarto conecta con un tema que merece capítulo propio y que ya está tratado en la guía de monitoreo de servidores, donde se explica el protocolo SNMP con sus tres versiones y los comandos para probarlo antes de configurarlo.

Preguntas frecuentes sobre Zabbix

¿Es realmente gratuito?

Por un lado, el programa sí: no hay licencia por equipo ni por métrica. Sin embargo, la empresa que lo desarrolla vende soporte por niveles, formación y servicios de integración. Es decir, el modelo es el clásico del software libre empresarial, y el coste real de una instalación está en el hardware y en las horas de quien la mantiene.

¿Cuántos equipos aguanta un solo servidor?

La pregunta correcta no es cuántos equipos, sino cuántos NVPS, porque cien switches con diez métricas pesan menos que diez servidores con trescientas. Con la tabla de dimensionamiento de arriba, una máquina de cuatro núcleos y 16 GiB cubre con holgura el caso de 120 equipos y 8.700 elementos.

¿Hay que instalar agente en todo?

No hace falta. Por ejemplo, los equipos de red se vigilan por SNMP, las webs por peticiones HTTP y el hardware por IPMI, sin instalar nada. El agente aporta el detalle interno del sistema operativo, así que se reserva para servidores y para los puestos que lo justifiquen.

¿Sirve para entornos virtualizados y en la nube?

Sí, y por dos vías a la vez. Por un lado, existen plantillas para consultar directamente al hipervisor, incluido el clúster descrito en la guía de Proxmox; por otro, cada máquina virtual se vigila como cualquier servidor. Lo recomendable es combinar ambas, porque el hipervisor ve el consumo real y el invitado ve lo que le falta.

Qué hacer con esta guía

Si va a montarlo por su cuenta, el orden que funciona es este: una LTS sobre una máquina dedicada, el esquema en base de datos separada desde el principio, tres servidores con plantilla oficial antes de dar de alta el cuarto, y disparadores con ventana de tiempo desde el primer día. Después, la cuenta de NVPS antes de ampliar, siempre.

Y si lo que necesita es que alguien lo opere, con guardias, umbrales revisados y reportes de disponibilidad, esa es exactamente la conversación de nuestro servicio de monitoreo. La herramienta es la parte fácil; sostener la operación todos los días es la difícil.