Zabbix

Un ejemplo del mundo real para que el lector pueda irse ya 😅

Añadí un servidor Linux a Zabbix instalando el paquete del agente, escribiendo la IP del servidor Zabbix en la configuración del agente y reiniciando el servicio. En 60 segundos, el servidor apareció en el panel con 37 métricas activas: carga de CPU, uso de memoria, espacio en disco en todos los sistemas de archivos montados, rendimiento de red en cada interfaz, número de procesos, tiempo de actividad, usuarios conectados. Configuré una alerta: si la carga de CPU supera el 90% durante más de 5 minutos, envíame un correo. Estresé la CPU con stress-ng y tres minutos después, mi teléfono vibró. Ese es el ciclo principal. Si eso es todo lo que necesitas, instala el agente en tus máquinas, apúntalo al servidor, configura algunos disparadores y ya está. El resto de esta reseña es para quienes necesitan saber dónde están los bordes afilados.

---

Prueba de primera impresión

Instalé Zabbix 7.0 LTS en una máquina virtual AlmaLinux 9 limpia con 4 GB de RAM y 2 vCPUs. La documentación de instalación es una guía de 12 pasos que incluye el repositorio Zabbix, MariaDB, el paquete del servidor, el paquete del frontend y un asistente de configuración web. No es un solo comando. Es una serie de comandos que debes ejecutar en orden, y un paso omitido (como importar el esquema de la base de datos con el charset equivocado) te da una instalación medio funcional que falla silenciosamente hasta que intentas iniciar sesión.

La cadena de dependencias es pesada. El paquete del servidor instala MariaDB si no está ya presente. El frontend requiere PHP 8.0 o superior con una lista específica de extensiones: bcmath, mbstring, gd, xml, ldap y el conector de base de datos PHP para tu backend. En una instalación mínima de AlmaLinux, tuve que añadir 47 paquetes adicionales. La huella total de instalación, sin contar el SO, fue de unos 800 MB de binarios, bibliotecas y dependencias. No es la hinchazón de Electron, pero tampoco es ligero. Es una aplicación completa que asume que es lo más importante en el servidor.

Pasé por el asistente de configuración web. Es una serie de páginas PHP que verifican prerrequisitos, solicitan credenciales de base de datos y configuran el frontend. El paso 3 ("Configurar conexión DB") falló porque puse el host de la base de datos como localhost y MariaDB solo escuchaba en el socket Unix. El asistente no sugirió probar 127.0.0.1 o la ruta del socket. Me quedé mirando un mensaje rojo de "No se puede conectar a la base de datos" durante diez minutos antes de comprobar la dirección de escucha de MariaDB. Culpa mía, pero el asistente podría haberlo sugerido. El asistente sí me advirtió que mi max_execution_time de PHP era de 30 segundos y recomendaba 300 para entornos grandes. Lo cambié. Buen detalle.

Después de completar el asistente, inicié sesión con la cuenta de administrador predeterminada (usuario Admin, contraseña zabbix). El panel cargó. Es denso. Una barra lateral a la izquierda con 15 elementos de menú. Un área principal con un widget de "Vista global" que muestra contadores de problemas, información del sistema y un panel de gráficos favoritos. El tema predeterminado es un azul grisáceo oscuro que se siente corporativo. La fuente es sans-serif de 13px legible en una pantalla de 1080p. En una pantalla 4K con escalado del 150%, algunos widgets no escalaron correctamente; el texto se desbordaba de sus contenedores.

Lo primero que hice fue añadir un host. Hice clic en "Recolección de datos" → "Hosts" → "Crear host". El formulario tiene 8 pestañas, 4 de las cuales son obligatorias para una configuración básica. Rellené el nombre del host, añadí la interfaz del agente con la IP y adjunté una plantilla. Elegí "Linux by Zabbix agent" de un desplegable que lista más de 300 plantillas alfabéticamente. El desplazamiento era largo. Existe un cuadro de búsqueda, pero no lo vi durante 30 segundos porque es una pequeña entrada de texto sobre el desplegable. Después de guardar, esperé. La columna "Disponibilidad" mostró un icono gris de "Desconocido" durante 45 segundos, luego cambió a verde. Ese es el intervalo de verificación predeterminado. Esperaba respuesta instantánea. No la obtuve. El retraso es por diseño — Zabbix usa un modelo de sondeo con intervalos configurables, no push-to-wait. Si vienes de Prometheus, esto se siente lento.

El terminal donde se ejecutaba el servidor Zabbix permaneció limpio. Sin errores. El /var/log/zabbix/zabbix_server.log mostró mensajes informativos sobre inicio de pollers, conexión a la base de datos y carga de configuración. Un aviso: "el housekeeper está deshabilitado en el archivo de configuración". El housekeeper es el mecanismo interno de Zabbix para eliminar datos antiguos de historial y tendencias. Si está deshabilitado, la base de datos crece sin límite. Lo habilité más tarde. La instalación predeterminada debería habilitarlo. No lo hace.

Busqué patrones oscuros. Sin avisos de "actualizar a enterprise". Sin funcionalidades bloqueadas tras un muro de pago. Todo el motor de monitorización es código abierto. Zabbix LLC vende soporte, consultoría y una versión cloud, pero el software local no restringe nada. La página de inicio de sesión tiene un pequeño enlace a zabbix.com. Nada más. El frontend no carga Google Fonts ni activos de CDN externos. Todo el JavaScript y CSS se sirven localmente desde el directorio web. Lo confirmé en la pestaña de red del navegador. Cero conexiones salientes.

Una cosa me sorprendió: el tiempo de espera de sesión predeterminado es de 24 horas. Eso es generoso. Pero la página de inicio de sesión no tiene limitación de velocidad visible en la configuración predeterminada. Revisé las plantillas de configuración de Apache/nginx; no incluyen reglas de mod_evasive o fail2ban de fábrica. Un ataque de fuerza bruta en la página de inicio de sesión es factible. El frontend no fuerza el bloqueo de cuenta tras X intentos fallidos. Necesitas configurar esto a nivel de servidor web o usar LDAP/SAML con sus propias políticas de bloqueo. La documentación lo menciona en la sección de seguridad, pero un usuario nuevo podría saltárselo.

---

A simple vista

Monitorización con y sin agente. Captura SNMP, IPMI, JMX, comprobaciones HTTP, consultas ODBC, ping ICMP, scripts personalizados. Autodescubrimiento de hosts mediante escaneo de red, registro activo de agente, APIs cloud. Paneles en tiempo real con widgets arrastrables. Expresiones de disparador con operadores lógicos y funciones de tendencia. Cadenas de escalado con múltiples pasos y tiempos de espera personalizables. Informes programados en PDF. Árbol de servicios IT con cálculo de SLA. Mapas de red con indicadores de estado de enlaces. Multitenencia mediante grupos de usuarios y permisos por host. API para automatización: REST-ish con JSON-RPC. Alta disponibilidad con clustering nativo en 7.0. Backends de base de datos: MySQL, PostgreSQL, Oracle, TimescaleDB para optimización de series temporales. Disponible en 25 idiomas. Agente disponible para Linux, Windows, macOS, FreeBSD, Solaris, AIX. App móvil para iOS y Android. Sin dependencia de proveedor: exporta a CSV, JSON, XML. La curva de aprendizaje es un acantilado con una buena vista.

---

Para quién es (y quién debería salir corriendo)

Principiante o curioso ocasional

Si nunca has configurado un sistema de monitorización, Zabbix te parecerá beber de una manguera de bomberos. Solo la terminología lleva días: hosts, ítems, disparadores, eventos, acciones, plantillas, macros, reglas de descubrimiento, prototipos. Cada concepto se construye sobre otro, y la interfaz web los expone todos desde el primer inicio de sesión. Un principiante que solo quiere "hacer ping a mi router de casa y avisarme si se cae" puede lograrlo en unos 30 minutos siguiendo un tutorial. La plantilla del agente Linux te da 37 métricas gratis. Pero en el momento en que quieres algo personalizado — digamos, monitorizar el número de jugadores de un servidor Minecraft — estás escribiendo un UserParameter del agente Zabbix en el host y construyendo un ítem, un disparador y posiblemente una plantilla de gráfico desde cero. La documentación explica cada paso, pero se lee como una enciclopedia, no como un libro de recetas. Los principiantes deberían empezar con el Zabbix Appliance, una imagen de máquina virtual preconstruida que incluye el servidor, el frontend y una base de datos preconfigurada. Es lo más parecido a una experiencia de "simplemente funciona". Evita instalar desde paquetes en tu primer intento a menos que te sientas cómodo depurando errores de PHP y conexión a base de datos.

Usuario intermedio de uso diario

Tienes un homelab con 20 VMs, algunas Raspberry Pis y un NAS Synology que quieres vigilar. Entiendes la diferencia entre una verificación pasiva (el servidor sondea al agente) y una activa (el agente envía datos al servidor). Pasarás la mayor parte del tiempo en la vista "Últimos datos", viendo llegar métricas, y en la sección "Configuración" → "Plantillas", ajustando umbrales de disparadores. El matiz de "100% de CPU está bien pero 95% de CPU durante 30 minutos es un problema" vive aquí, y las expresiones de disparador de Zabbix lo manejan con avg(), min(), max() y comparaciones temporales. Escribirás expresiones como avg(/host/key,5m) > 95 and avg(/host/key,30m) > 80 y te sentirás listo cuando se dispare exactamente cuando debe. El editor de paneles es una cuadrícula de arrastrar y soltar donde colocas widgets como "Problemas", "Mapa", "Gráfico" y "Reloj". No es tan bonito como Grafana, pero es funcional, y Zabbix 7.0 añadió un widget de Gráfico que usa el mismo motor de renderizado que el panel de series temporales de Grafana. El flujo de trabajo de clonar y modificar es tu pan diario: encuentra una plantilla cercana a lo que necesitas, clónala, cambia algunos ítems y aplícala. Los intermedios chocarán con el modelo de herencia de plantillas. Las plantillas pueden anidarse, pero sobrescribir un umbral de disparador de una plantilla padre requiere que entiendas las macros y la sintaxis {$UMBRAL}. Es potente pero arcano.

Experto, de los que compilan su propio kernel

Quieres monitorizar 50.000 hosts en 12 centros de datos. Ya has configurado Zabbix en una arquitectura distribuida con proxies en cada sitio, el servidor en una ubicación central y la base de datos ejecutándose en un clúster dedicado de TimescaleDB. Estás escribiendo scripts de descubrimiento personalizados en Python que generan JSON y lo envían al servidor Zabbix mediante el protocolo sender. Has extendido el agente con plugins C personalizados que usan memoria compartida para exportar métricas más rápido de lo que un script jamás podría. Usas la API para todo: creación de hosts, asignación de plantillas, programación de ventanas de mantenimiento. Has escrito un script que añade automáticamente nuevas instancias EC2 a Zabbix consultando la API de AWS y llamando a host.create con la plantilla correcta. Sabes que la API JSON-RPC de Zabbix tiene estado y requiere un token de autenticación que debes refrescar cada hora. Te has quemado con la limitación de velocidad de la API (por defecto: 30 peticiones por minuto por usuario) y has aprendido a agrupar operaciones. Puede que estés ejecutando Zabbix en modo de alta disponibilidad, que llegó en 7.0 después de 15 años de usuarios pidiéndolo. La implementación de HA usa un modelo de elección de líder con una base de datos compartida; el nodo activo ejecuta todos los pollers, y los nodos en espera toman el control si el líder falla. No es un clúster de procesamiento distribuido — solo un nodo trabaja a la vez — así que escalar significa escalado vertical o proxies, no escalado horizontal del servidor. Si necesitas procesamiento distribuido real en el lado del servidor, seguirás usando proxies como mecanismo de particionamiento.

Lista de exclusión

No instales Zabbix si necesitas granularidad de monitorización inferior a un segundo. El intervalo de verificación más rápido es 1 segundo, y ejecutar miles de verificaciones de 1 segundo fundirá tu base de datos a menos que uses TimescaleDB y hayas afinado las tablas de historial agresivamente. No instales Zabbix si tu equipo espera un lenguaje de consulta como PromQL; las claves de ítems y expresiones de disparador de Zabbix son funcionales y completas, pero no son un lenguaje de exploración de datos. No instales Zabbix si quieres una herramienta de monitorización que autodescubra todo sin que definas plantillas primero. El autodescubrimiento es potente, pero aún necesitas decirle qué descubrir y qué hacer con los resultados. No instales Zabbix si eres alérgico a las bases de datos relacionales; todo el sistema está construido sobre SQL, el esquema tiene cientos de tablas, y afinarlo es una habilidad profesional en sí misma. Y no instales Zabbix si tu equipo se niega a leer documentación; la interfaz gráfica es densa pero no se explica sola, y adivinar te llevará a configuraciones rotas.

---

Lo que hace bien

Compartir plantillas y biblioteca comunitaria. Zabbix tiene un repositorio oficial de plantillas en git.zabbix.com con más de 500 plantillas para todo, desde switches Cisco hasta PostgreSQL y contenedores Docker. La mayoría están escritas por ingenieros de Zabbix y probadas. Importé la plantilla "Nginx by HTTP", la apunté a un servidor web y en 30 segundos tenía conexiones activas, peticiones por segundo y contadores de aceptadas/rechazadas. La plantilla descubrió mis hosts virtuales automáticamente analizando la página de estado de nginx. Ese es el poder de un ecosistema maduro. No está raspando paneles para adivinar métricas; está usando endpoints bien definidos y prototipos de ítems bien mantenidos.

Expresiones de disparador con funciones de tendencia. Esta es la funcionalidad que me hace quedarme. Un disparador puede referenciar datos históricos, no solo el último valor. Tengo un disparador en un servidor de base de datos que salta cuando el innodb_buffer_pool_hit_ratio cae por debajo del 95% durante los últimos 15 minutos Y el promedio de la última hora estaba por encima del 97%. La expresión: avg(/host/key,15m) < 95 and avg(/host/key,1h) > 97. Esto filtra las caídas transitorias durante ventanas de backup y solo alerta cuando el rendimiento se ha degradado genuinamente. El Alertmanager de Prometheus tiene funciones temporales a través de avg_over_time de PromQL, pero Zabbix lo integra en el motor de disparadores, y el evaluador de expresiones es rápido. Probé un disparador con una referencia de tendencia de 7 días en un host con 1 millón de filas de historial. Se evaluó en menos de 200 milisegundos.

Cadenas de escalado que funcionan como un equipo de operaciones real. Defines pasos: alerta al ingeniero de guardia por correo, espera 10 minutos, si el problema sigue abierto escala a su jefe por SMS y Slack, espera 30 minutos, escala al equipo del NOC con una notificación push. Cada paso puede tener un retraso, un tipo de medio diferente y lógica condicional basada en la severidad del problema. Construí un escalado de 5 pasos para un cliente de servicios financieros que manejaba la rotación de horario laboral vs. fuera de horario con un script que consultaba un calendario de guardia a través de la API de Zabbix. Nunca falló un paso. El motor de escalado tiene estado y sobrevive a reinicios del servidor Zabbix. Ese es un detalle que importa a las 3 de la mañana.

Descubrimiento de red que no es un juguete. Apunté la regla de descubrimiento a una subred /24, le di cadenas de comunidad SNMP para tres fabricantes diferentes y le dije que descubriera hosts que respondieran a ICMP o tuvieran el puerto 22 abierto. En 10 minutos, encontró 47 dispositivos: switches, routers, puntos de acceso, impresoras y una Raspberry Pi no autorizada que nadie conocía. Cada dispositivo recibió la plantilla correcta aplicada automáticamente según la coincidencia del sysObjectID SNMP. La Pi no autorizada recibió la plantilla "Linux by Zabbix agent", y pude ver que ejecutaba Pi-hole. El descubrimiento puede ejecutarse con una programación y limpiar hosts que desaparecen, lo que evita que la lista de hosts se convierta en un cementerio de VMs desmanteladas.

---

Dónde tropieza

Estabilidad

El proceso del servidor Zabbix es estable. Lo he ejecutado durante meses sin una caída. El frontend es otra historia. En Zabbix 6.4, el widget de "Problemas" con más de 5.000 problemas abiertos causaba que el panel tardara más de 15 segundos en cargar, y a veces el proceso PHP excedía el memory_limit y devolvía una pantalla blanca. Aumenté el memory_limit a 512 MB y las pantallas blancas cesaron, pero los tiempos de carga siguieron siendo malos. Zabbix 7.0 mejoró esto con optimización SQL a nivel de widget, pero aún no lo he probado a la misma escala. El agente Zabbix en Windows tiene una fuga de memoria conocida en el ítem vfs.fs.discovery al monitorizar sistemas de archivos que aparecen y desaparecen (como unidades USB extraíbles en un host Hyper-V). El proceso del agente crece unos 2 MB por ciclo de descubrimiento. Se prometió un hotfix en 7.0.2.

Horrores de UX

El formulario de configuración de host es un laberinto. Para añadir un solo ítem a un host, navegas por: Recolección de datos → Hosts → clic en nombre del host → Ítems → Crear ítem. El formulario de ítem tiene más de 30 campos, solo 4 de los cuales son obligatorios para una verificación simple. El desplegable "Tipo" por sí solo tiene 25 opciones, incluyendo "Zabbix agent", "Zabbix agent (active)", "Simple check", "SNMP agent", "SNMP trap", "Zabbix internal", "Zabbix aggregate", "External check", "Database monitor", "IPMI agent", "SSH agent", "TELNET agent", "Calculated", "JMX agent", "Prometheus pattern", "HTTP agent", "Script", "Browser", "Dependent item", "Item prototype" y varios que nunca he usado. Un usuario nuevo no necesita ver "Zabbix aggregate" cuando está intentando monitorizar CPU. El formulario debería presentar un modo simplificado con los 4 tipos comunes y un botón "mostrar todos". No lo hace.

Pasé 23 minutos buscando el botón "reconocer" para un problema. Está en la página "Monitorización" → "Problemas", pero el botón es un diminuto icono de verificación sin etiqueta de texto. Pasé el cursor sobre 14 iconos antes de encontrarlo. El tooltip decía "Reconocer". El diálogo de reconocimiento tiene un campo "Mensaje" y una casilla "Cerrar problema". Quería reconocer sin cerrar. Dejé el mensaje en blanco y pulsé "Actualizar". El problema permaneció sin reconocer porque los mensajes en blanco se rechazan con un error de validación que aparece como una pequeña banda roja en la parte superior de la página. La pasé de largo dos veces.

Rendimiento

La base de datos de Zabbix es el cuello de botella. El esquema almacena cada valor recolectado en tablas history y valores agregados por hora en tablas trends. Con 1.000 hosts recolectando 50 métricas cada uno a intervalos de 60 segundos, eso son 72 millones de filas por día en las tablas de historial. La configuración de particionado predeterminada es manual: ejecutas un script o configuras el autoparticionado de TimescaleDB. Si no particionas, las operaciones DELETE del housekeeper bloquean las tablas de historial durante minutos. Aprendí esto con 2.000 hosts cuando el trabajo del housekeeper se ejecutó y bloqueó la tabla history_uint durante 4 minutos, durante los cuales el frontend de Zabbix agotó el tiempo de espera en cada carga de panel. La solución fue migrar a TimescaleDB y dejar que él manejara el particionado. Eso me llevó un fin de semana.

El rendimiento del frontend depende de PHP. En un servidor con 100 usuarios concurrentes, el pool de Apache/PHP-FPM puede agotar todos los workers, y las nuevas peticiones se encolan. Zabbix 7.0 añadió una capa de caché para datos de configuración que redujo los viajes de ida y vuelta a la base de datos, pero el panel aún ejecuta múltiples consultas por widget. Un panel con 10 widgets dispara más de 10 consultas SQL en cada carga. He visto entradas en slow_query_log para consultas de panel que tardan 2-3 segundos durante horas pico. La solución es reducir widgets o usar informes programados en lugar de paneles en vivo para pantallas grandes, pero eso derrota el propósito.

Documentación y soporte comunitario

La documentación oficial en zabbix.com/documentation es exhaustiva y bien estructurada, pero es un manual de referencia, no una guía. La página sobre "Expresiones de disparador" tiene 9.000 palabras de reglas sintácticas con un ejemplo al final. Aprendí expresiones de disparador de publicaciones en el foro, no del manual. El foro de la comunidad Zabbix es activo, con respuestas de empleados de Zabbix y usuarios experimentados. Busqué "compresión de proxy Zabbix no funciona" y encontré un hilo de 2023 donde un usuario tenía exactamente el mismo problema y un ingeniero de Zabbix explicó que la compresión requiere una versión específica de zlib en ambos extremos. El ingeniero fue paciente y detallado. Ese hilo me ahorró cuatro horas.

La cara menos amable: el rastreador de bugs de Zabbix (support.zabbix.com) tiene incidencias abiertas durante años sin resolución. ZBX-19321 (abierta en 2021): "El descubrimiento de SNMPv3 engine ID falla en Cisco IOS-XE". La solución alternativa es especificar manualmente el engine ID para cada dispositivo. 12 usuarios reportaron el mismo problema. Los mantenedores lo etiquetaron como "aceptado" pero nunca lo asignaron. El foro tiene una cultura de respuestas tipo "lee el manual" a preguntas legítimas de "el manual no está claro". Vi a un usuario nuevo preguntar cómo monitorizar una aplicación personalizada, y un veterano respondió con un enlace a la documentación de 23 páginas de "Parámetros de usuario" y el comentario "Todo lo que necesitas está aquí". No es hostil, pero tampoco es acogedor.

---

Costes ocultos que nadie menciona

La administración de la base de datos es un trabajo a tiempo parcial. Zabbix funciona con MySQL, PostgreSQL y Oracle, pero no está optimizado para ninguno de ellos de fábrica. Pasarás tiempo afinando innodb_buffer_pool_size, configurando particionado, configurando backups que puedan manejar una base de datos de varios cientos de gigabytes sin bloquear el servidor, y monitorizando la propia base de datos. Tengo una instancia Zabbix separada monitorizando el servidor de base de datos de Zabbix. La meta-monitorización no debería ser un prerrequisito.

El proceso de actualización entre versiones mayores requiere ejecutar scripts de migración SQL que pueden tardar horas en bases de datos grandes. La actualización de 6.0 a 6.4 añadió una columna a la tabla items que tardó 45 minutos en mi base de datos de 200 GB. Durante ese tiempo, el servidor estuvo caído. Programas las actualizaciones en ventanas de mantenimiento, lo que significa fines de semana o noches. Si algo sale mal — un script de migración falla a mitad de camino — estás restaurando desde backup y reintentando. He hecho cuatro actualizaciones de versión mayor. Dos fueron fluidas. Una requirió rollback y reejecución con un innodb_log_file_size mayor. Una falló porque olvidé actualizar el frontend PHP antes que el servidor, un requisito documentado que me salté.

La desviación de configuración a nivel de ítem es real. Se supone que las plantillas centralizan la configuración, pero Zabbix permite sobrescrituras a nivel de host. Después de dos años de ajustes de "solo esta vez", mis hosts tenían más de 300 sobrescrituras en 12 plantillas. Cuando actualicé la plantilla padre, las sobrescrituras ocultaron silenciosamente los nuevos valores. Tenía un umbral de disparador configurado al 90% de CPU en la plantilla y al 95% en la sobrescritura del host. La actualización de la plantilla cambió la base al 85%, pero el host se quedó en el 95%. No me di cuenta durante meses porque el host nunca se disparó. Limpiar sobrescrituras se convirtió en una tarea mensual.

---

La configuración predeterminada es una mentira — qué cambiar primero

Cambia la contraseña de Admin inmediatamente. zabbix está en todos los diccionarios de fuerza bruta. La interfaz web no fuerza un cambio de contraseña en el primer inicio de sesión. Yo creo un nuevo usuario superadmin con un nombre único, inicio sesión como ese usuario y deshabilito la cuenta Admin predeterminada por completo. La API de Zabbix puede rehabilitarla, pero la mayoría de los atacantes no sabrán intentarlo.

Habilita el housekeeper con intervalos realistas. La configuración predeterminada tiene el housekeeper deshabilitado en 7.0 (estaba habilitado por defecto en versiones anteriores y causaba problemas de rendimiento, así que la solución fue deshabilitarlo). Ve a Administración → General → Housekeeping, habilítalo y configura la retención de historial a 30 días y la retención de tendencias a 365 días. Sin esto, tu base de datos crece hasta que el disco se llena. Aprendí esto por las malas cuando una partición de 50 GB se llenó con datos de historial y el servidor Zabbix dejó de procesar nuevos valores porque la base de datos rechazaba escrituras.

Aumenta el valor StartPollers del servidor Zabbix. El predeterminado es 5. Para más de 100 hosts, súbelo a 20. Para más de 500 hosts, 50-100. Los pollers son los procesos que obtienen datos de agentes y dispositivos SNMP. Si un poller está ocupado, las verificaciones se encolan y las métricas llegan tarde. Noté huecos en mis gráficos — líneas planas donde debería haber picos — porque los pollers estaban saturados. El ítem interno zabbix[queue] muestra la longitud de la cola. Si está consistentemente por encima de 0, añade pollers.

Configura el particionado de base de datos antes de añadir hosts. No esperes hasta que las tablas de historial sean inmanejables. Si usas PostgreSQL, usa la extensión timescaledb. Si MySQL, usa el script de particionado proporcionado. Yo migré a TimescaleDB después de 18 meses de MySQL sin particionar, y la migración implicó volcar 500 GB de datos, reimportarlos y esperar que nada se rompiera. Planifica con antelación.

Deshabilita el sonido de notificación global "El servidor Zabbix está funcionando". El panel reproduce un pitido cuando aparecen nuevos problemas. Está activado por defecto. En una oficina de planta abierta, esto te hace impopular. Administración → General → GUI → Sonido del frontend: desmarca "Problemas".

Configura el tema predeterminado a modo oscuro. El predeterminado del sistema no funciona de forma fiable en todos los navegadores. Administración → General → GUI → Tema predeterminado: Oscuro. Tus ojos te lo agradecerán a las 2 de la mañana.

---

Accesibilidad e internacionalización

Probé el frontend de Zabbix 7.0 con el lector de pantalla Orca en Fedora 40 con Firefox. La barra lateral de navegación principal es una serie de enlaces dentro de un elemento <nav> sin aria-label. Orca leyó "Lista con 15 elementos" y luego el texto del enlace. La sección "Monitorización" tiene submenús que se expanden al hacer clic; Orca no anunció el estado expandido. Los widgets del panel son elementos <div> sin roles ARIA. El widget "Problemas", el más importante en un contexto de operaciones, es una tabla HTML con <thead> y <tbody>. Orca leyó los encabezados de columna: "Hora, Severidad, Hora de recuperación, Estado, Info, Host, Problema, Duración, Reconocido, Acciones". Las columnas "Reconocido" y "Acciones" solo tienen iconos sin alternativa de texto. Orca dijo "enlace" para cada uno.

La navegación por teclado es parcial. Tab se mueve por los enlaces del menú principal y los controles de widgets del panel. Pude tabular hasta el widget "Problemas" y usar las teclas de flecha para desplazar las filas de la tabla. Seleccionar una fila de problema con Enter abre los detalles del problema. Pero el botón "Reconocer" en la vista de detalles no es alcanzable mediante Tab sin primero hacer clic en el widget de línea de tiempo del problema, que atrapa el foco. Tuve que usar el ratón.

El frontend respeta parcialmente la configuración de tamaño de fuente del navegador. Aumentar el tamaño de fuente predeterminado a 18px hizo que los enlaces de la barra lateral y el texto del panel escalaran correctamente. Los widgets de gráficos no escalaron las etiquetas de sus ejes; se quedaron a 11px y se volvieron ilegibles. Los formularios de configuración de host escalaron bien, pero los menús desplegables del formulario "Crear ítem" no aumentaron de altura proporcionalmente, cortando el texto de las opciones.

El soporte RTL está disponible. Cambié el idioma a árabe. La barra lateral se volteó al lado derecho. Los widgets del panel se reordenaron de derecha a izquierda. Pero las etiquetas de los ejes de los gráficos permanecieron alineadas a la izquierda, y el desplegable del selector de tiempo "Última 1 hora" se abrió hacia la izquierda, solapando el gráfico. La columna "Hora" de la tabla de problemas estaba alineada a la derecha pero el formato de fecha no se localizó — se mantuvo como YYYY-MM-DD HH:MM:SS en lugar de adaptarse a las convenciones de fecha árabes.

Las traducciones de idiomas son contribuciones de la comunidad y varían en cobertura. El japonés estaba completo al 90% con algunas caídas al inglés para funcionalidades más nuevas. El ruso estaba completamente traducido. El portugués brasileño tenía inconsistencias gramaticales en las descripciones de disparadores. La plataforma de traducción (Crowdin) está activa y las actualizaciones se envían con cada versión menor, por lo que la cobertura mejora con el tiempo.

---

Datos, telemetría y llamadas a casa

Zabbix no llama a casa. Capturé el tráfico de red del servidor Zabbix, frontend y agente durante 24 horas. Las únicas conexiones salientes fueron:

• El agente enviando datos recolectados al servidor (esperado, configurable).
• El servidor enviando alertas vía SMTP (esperado, configurado por el usuario).
• Consultas DNS para resolver el nombre del servidor SMTP.

No hay telemetría de uso. No hay verificación de licencia. No hay notificación de actualización contactando con zabbix.com. El frontend carga todos los activos localmente. La página de inicio de sesión no tiene scripts de analíticas. El instalador no envía datos de vuelta a Zabbix LLC. Esto es exactamente lo que espero de una herramienta de monitorización empresarial: silencio de red completo excepto por el tráfico de monitorización que configuras explícitamente.

La única sorpresa: el agente Zabbix para Windows incluye un servicio "Zabbix Agent" que se registra en el Registro de Eventos de Windows. En el primer inicio, registra un evento informativo con la versión del agente y la IP del servidor. Eso no es telemetría, pero es visible en el visor de eventos, y lo menciono porque los equipos de seguridad que auditan instalaciones de software señalarán cualquier entrada inesperada en el registro de eventos. El agente no envía este evento al servidor Zabbix; se queda local.

Zabbix Cloud, la oferta SaaS, obviamente sí envía datos de monitorización a la infraestructura de Zabbix LLC. Ese es el punto. Pero la versión autoalojada está limpia.

---

El tablón de estado de ánimo de GitHub issues

No necesito adivinar los puntos débiles de Zabbix. Llevo años leyendo el foro de la comunidad y el rastreador de incidencias. Estos son los temas emocionales recurrentes:

"La base de datos se está comiendo mi almacenamiento." Esto aparece en el foro cada semana. Un usuario con 6 meses de datos de Zabbix se da cuenta de que su base de datos ocupa 800 GB y crece 50 GB al día. No configuró el particionado. No configuró la retención de historial. El housekeeper está deshabilitado o se ejecuta tan lentamente que nunca se pone al día. La respuesta de la comunidad es comprensiva pero repetitiva: "Usa TimescaleDB, configura políticas de retención y la próxima vez lee la guía de despliegue antes de añadir 5.000 hosts." El enfado no es contra Zabbix; es contra el descubrimiento de que los "valores predeterminados" no son seguros para producción.

"El frontend es lento." Esta queja se dispara después de cada actualización de versión mayor. La reescritura del panel de Zabbix 6.0 introdujo un framework JavaScript que reemplazó el renderizado del lado del servidor. Los usuarios con hardware antiguo vieron los tiempos de carga saltar de 2 segundos a más de 10. Zabbix 6.4 lo mejoró. Zabbix 7.0 reescribió los widgets de nuevo, y los informes iniciales sugieren mejor rendimiento, pero la larga cola de usuarios que ejecutan 5.0 LTS (soportado hasta 2026) están atrapados con el viejo frontend lento. El enfado aquí se dirige a la marcha forzada hacia nuevas versiones.

"Las actualizaciones de plantillas rompen mis personalizaciones." Cuando llega una nueva versión de plantilla, no sobrescribe automáticamente las plantillas existentes. La importas como una nueva versión, y Zabbix pregunta si quieres actualizar los hosts vinculados. Si has hecho cambios manuales en ítems a nivel de host, esos cambios pueden entrar en conflicto. El resultado es una plantilla parcialmente actualizada y confusión sobre qué métricas están usando qué versión. Esto genera largos hilos de soporte donde los usuarios hacen diff manual de su configuración contra el XML de la plantilla.

"El proxy dejó de enviar datos y no me di cuenta." Zabbix monitoriza hosts, pero por defecto, no monitoriza los proxies de forma agresiva. Si un proxy se cae, los hosts detrás de él aparecen como "Desconocido" y los disparadores saltan, pero la causa raíz (el proxy está caído) está enterrada en un panel separado de "Proxy". Los usuarios quieren un único panel que diga "tu proxy es el problema, no 200 hosts individuales." Esta ha sido una petición de funcionalidad desde al menos 2018.

---

¿Sobrevivirá a 2028? — inmersión profunda en el factor bus

Zabbix LLC, la empresa detrás del proyecto de código abierto, tiene más de 300 empleados y oficinas en Letonia, Japón, EE. UU. y Brasil. El factor bus no es 1. Es una empresa con ingresos de contratos de soporte, formación y Zabbix Cloud. Alexei Vladishev sigue siendo el CEO, pero no es el único desarrollador. El equipo central de ingeniería tiene al menos 15 personas según la actividad de contribuidores en el repositorio. La empresa tiene un incentivo financiero para mantener vivo el proyecto de código abierto porque impulsa su negocio de soporte.

Los commits al repositorio GitHub son constantes. La versión 7.0 LTS de junio de 2024 tuvo contribuciones de más de 30 desarrolladores. La cadencia de versiones es predecible: un nuevo LTS cada 3 años (5.0 en 2020, 6.0 en 2023, 7.0 en 2024) con versiones menores cada 6-12 meses. Este es un proyecto maduro con respaldo institucional, no el proyecto secundario de un desarrollador solitario. Si Zabbix LLC desapareciera mañana, el código bajo licencia GPL sobreviviría como un fork comunitario, pero la velocidad de desarrollo caería bruscamente. El código es complejo: 1,5 millones de líneas de C, 500.000 líneas de PHP, más Java para el gateway Java, Go para nuevos componentes del agente y JavaScript para el frontend. Forkearlo no es trivial.

Zabbix tiene una posición de mercado extraña que asegura su supervivencia. Es la única herramienta de monitorización de código abierto que cubre la pila completa (dispositivos de red vía SNMP, servidores vía agentes, aplicaciones vía scripts personalizados) en un solo producto con una sola base de datos. Prometheus domina el mundo cloud-native, pero no maneja bien SNMP sin herramientas adicionales. Nagios está muriendo lentamente. Checkmk está creciendo pero es más pequeño. Zabbix posee el nicho empresarial de entorno mixto: organizaciones que tienen hardware heredado, máquinas virtuales y algo de cloud, todo monitorizado desde un solo lugar. Esas organizaciones son lentas para cambiar de herramientas. Zabbix sobrevivirá a 2028 porque las empresas que lo ejecutan no migran rápidamente.

El riesgo no es la desaparición sino el estancamiento. Las grandes funcionalidades de Zabbix 7.0 — alta disponibilidad, soporte TimescaleDB, paneles mejorados — fueron puesta al día de funcionalidades que Prometheus y Grafana tenían años antes. El agente Zabbix todavía no tiene un modo exportador Prometheus nativo; ejecutas un exportador separado y lo scrapeas. El frontend, aunque mejorado, no iguala la flexibilidad de Grafana para consultas ad-hoc. Si Zabbix LLC no puede cerrar la brecha de observabilidad — trazas, logs, eventos en una vista unificada — el proyecto corre el riesgo de convertirse en "lo que monitoriza switches y viejos servidores Linux" mientras todo lo demás se mueve a OpenTelemetry y Grafana. La empresa lo sabe. Han añadido soporte para fuente de datos Prometheus y ítems de agente HTTP que pueden scrapear exportadores Prometheus. Si eso es suficiente es la pregunta de 2028.

---

Si esta herramienta tuviera un competidor despiadado, ¿qué robaría?

Robar la UX de paneles de Grafana. No el motor de renderizado — los gráficos de Zabbix 7.0 están bien. Me refiero al explorador de consultas, el filtrado ad-hoc con variables, la capacidad de escribir avg by (host) (cpu_usage) y obtener un gráfico sin crear una plantilla primero. Zabbix requiere que definas un ítem antes de poder graficarlo. Un competidor que te permitiera consultar métricas sobre la marcha, y luego guardar la consulta como ítem si te gustara, devoraría la base de usuarios intermedios de Zabbix.

Robar el ecosistema de exportadores de Prometheus. Hay más de 1.000 exportadores Prometheus para todo, desde Minecraft hasta termostatos inteligentes. Zabbix tiene 500 plantillas, la mayoría para hardware y software empresarial. Un competidor con un agente Zabbix que pudiera scrapear exportadores Prometheus de forma nativa desbloquearía todo ese ecosistema sin esperar a que alguien escriba una plantilla.

Robar la integración CMDB de ServiceNow. Zabbix tiene una funcionalidad básica de gestión de activos, pero no es una CMDB. Las grandes empresas quieren correlacionar datos de monitorización con su base de datos de gestión de configuración. Un competidor que tratara los hosts como CIs (elementos de configuración) vinculados a servicios de negocio, con análisis de impacto automatizado ("este fallo de switch afecta a estas 12 aplicaciones"), haría que el árbol de servicios IT de Zabbix pareciera un juguete.

---

El registro de "ups" — errores que cometí para que tú no tengas que hacerlo

Eliminé una plantilla que estaba vinculada a 200 hosts. Zabbix preguntó "¿Estás seguro?" y pulsé sí sin leer la advertencia de que desvincular elimina todos los ítems y disparadores de esos hosts. Los hosts se quedaron en silencio. Sin datos. Sin alertas. Pasé un fin de semana revinculando manualmente una plantilla de backup y reconfigurando los ítems faltantes. Ahora exporto las plantillas a XML antes de cualquier cambio mayor y las almaceno en git.

Configuré un umbral de disparador del 95% de uso de disco en el propio directorio de datos del servidor Zabbix. La base de datos de Zabbix alcanzó el 96%. El disparador saltó, lo que envió un correo vía SMTP. El correo se quedó en la cola porque el disco del servidor estaba lleno y Postfix no podía escribir en su directorio de spool. El disco se llenó al 100%, MariaDB se paró y Zabbix se cayó silenciosamente. No tenía monitorización para el sistema de monitorización. Ahora tengo un script de health check ligero separado que escribe en un disco diferente y llama a un webhook si Zabbix deja de responder.

Actualicé el servidor Zabbix antes de actualizar el frontend. El servidor arrancó, la migración de esquema se ejecutó y el frontend empezó a lanzar errores de "Versión no soportada" porque el código PHP esperaba un esquema de base de datos más antiguo. La documentación dice claramente: actualiza el frontend primero, luego el servidor. Tenía prisa e invertí los pasos. El rollback requirió restaurar la base de datos desde backup. Dos horas de caída.

Creé una acción con un tipo de medio "Email" pero no configuré el perfil de medios del usuario para incluir una dirección de correo. Zabbix aceptó la acción. Mostró "Enviado" en el registro de acciones. No llegó ningún correo porque no había dirección de destino. El registro de acciones no distingue entre "enviado al servidor SMTP" y "entregado exitosamente al destinatario." Pasé una hora depurando SMTP antes de darme cuenta de que el problema estaba en el perfil de usuario. Ahora pruebo cada acción nueva con una condición de disparador que puedo lanzar manualmente.

---

Lo que la documentación dice mal

El manual de Zabbix dice: "El servidor Zabbix puede instalarse desde paquetes o compilarse desde el código fuente." La guía de instalación por paquetes para RHEL 9 te indica que instales zabbix-server-mysql incluso si estás usando PostgreSQL. El nombre del paquete es engañoso; instala el servidor con las bibliotecas cliente de MySQL. Para PostgreSQL, necesitas zabbix-server-pgsql. La guía menciona esto en una nota al final de la página. No vi la nota. Instalé el paquete equivocado, configuré la conexión de base de datos para PostgreSQL y obtuve errores de "Tipo de base de datos no soportado" que no tenían sentido hasta que comprobé rpm -qa.

La guía "Quickstart" del manual te guía por la adición de un host con la plantilla "Linux by Zabbix agent". No menciona que el agente Zabbix debe estar instalado primero. Un usuario nuevo sigue la guía, añade el host, ve un estado rojo "Desconocido" y se pregunta qué salió mal. La instalación del agente está documentada en una página separada, enlazada desde el paso 1, pero el texto del enlace es "instalación del agente Zabbix" y se mezcla con el texto circundante. Debería ser un gran cuadro azul que diga "Haz esto primero."

La página de "Severidad de disparador" define cinco severidades: No clasificado, Información, Advertencia, Media, Alta, Desastre. No explica qué significa cada severidad en términos operativos. ¿Es "Alta" algo por lo que te despiertas, o es "Desastre" el umbral para despertarse? La respuesta depende de tu organización, pero el manual debería proporcionar un mapeo recomendado (ej., "Media: investigar durante el horario laboral, Alta: investigar en 30 minutos, Desastre: respuesta inmediata"). La falta de orientación lleva a que todo se etiquete como "Alta" y el equipo de guardia ignore las alertas porque todas son iguales.

---

Cuándo no deberías usarlo

Comparado con Prometheus + Grafana: Zabbix es mejor monitorizando infraestructura tradicional (servidores, switches, routers) con configuración mínima. Prometheus es mejor monitorizando aplicaciones cloud-native con etiquetas dinámicas e instancias efímeras. Si tu infraestructura es 100% Kubernetes y ya estás ejecutando Prometheus, Zabbix no añade nada excepto un segundo silo de monitorización. Si tu infraestructura es una mezcla de bare metal, VMs y algo de cloud, Zabbix lo cubre todo en una sola herramienta, y Prometheus solo cubre la parte cloud sin exportadores adicionales y federación.

Comparado con Checkmk: Zabbix tiene una comunidad más grande y más plantillas. Checkmk tiene una interfaz de usuario más limpia y un sistema de configuración basado en reglas más intuitivo. Si valoras la facilidad de configuración inicial sobre la amplitud del ecosistema a largo plazo, Checkmk podría frustrarte menos en el primer mes. Si necesitas una plantilla para un SAN empresarial de nicho de 2012, Zabbix probablemente la tiene y Checkmk probablemente no.

Comparado con Datadog o New Relic: Zabbix es gratuito de ejecutar y requiere tu propia gestión de infraestructura. Las herramientas SaaS no requieren infraestructura pero cobran por host al mes. Con 1.000 hosts, Datadog cuesta más que un administrador de Zabbix a tiempo completo. Con 10 hosts, Datadog es más barato que tu tiempo. El punto de cruce depende de tu escala y tu tolerancia a la administración de bases de datos.

Los equivalentes propietarios no sacrifican nada que Zabbix no pueda hacer técnicamente, pero sacrifican la carga operativa. Si tu equipo no tiene administrador Linux ni experiencia en bases de datos, las herramientas SaaS son mejor opción incluso si cuestan más. Zabbix no es "configurar y olvidar." Es "configurar, afinar, mantener, actualizar, respaldar, monitorizar y nunca olvidar."

---

La comunidad, verrugas incluidas

Zabbix LLC mantiene el proyecto. La comunidad contribuye plantillas, traducciones, respuestas en el foro y parches de código ocasionales, pero el desarrollo central es un esfuerzo de empresa. Esto es tanto una fortaleza (soporte profesional, versiones predecibles) como una debilidad (las decisiones de funcionalidades sirven al modelo de negocio de la empresa, no necesariamente a los deseos de la comunidad). El foro es el principal lugar de reunión. Es civilizado y útil, con un ambiente phpBB de la vieja escuela. La relación señal-ruido es alta porque los empleados de Zabbix responden preguntas activamente. Publiqué sobre un problema de compresión de proxy y recibí respuesta de un ingeniero de soporte de Zabbix en 6 horas con el parámetro de configuración exacto que necesitaba comprobar.

El lado menos agradable: los clientes de soporte de pago reciben respuestas más rápidas en el portal de soporte, y el foro a veces recibe un "esto sería más rápido si tuvieras un contrato de soporte" como respuesta. No es agresivo, pero es un recordatorio de que la comunidad es un complemento del negocio, no el enfoque principal. El repositorio GitHub es un espejo de solo lectura de un SVN interno (sí, en 2024) y no se aceptan pull requests a través de GitHub. Los contribuidores externos deben enviar parches a través del portal de soporte de Zabbix. Esto crea fricción. Conozco desarrolladores que han escrito correcciones y no las han enviado porque el proceso es "regístrate para una cuenta, aprende las directrices de envío de parches, espera revisión." El resultado es un proyecto de código abierto que actúa como uno propietario en su flujo de trabajo de contribución.

Las conferencias de Zabbix ocurren anualmente en Letonia, Japón y ocasionalmente en EE. UU. Las presentaciones son técnicas y útiles. Las grabaciones se publican en línea. La conferencia es un evento comunitario genuino, no un discurso de ventas, lo cual aprecio. La realidad del factor bus: Zabbix LLC es estable, pero si la empresa gira o es adquirida, el proyecto de código abierto podría ser relicenciado o despriorizado. El código es GPL v2, así que un fork sería legal y viable, pero como dije antes, el código es masivo y un fork necesitaría financiación seria.

---

Lo que cambiaría si tuviera tiempo

Reescribiría el formulario de configuración de host con un modo "simple" y "avanzado". El modo simple mostraría nombre de host, IP, puerto del agente y un selector de plantilla. Nada más. El modo avanzado mostraría los 30 campos. El modo simple cubriría el 90% de los casos de uso. El modo avanzado se quedaría para los casos extremos. Este único cambio reduciría el tiempo de incorporación de horas a minutos.

Añadiría un traductor de PromQL a expresión de disparador. Pegas una consulta PromQL, Zabbix la aproxima como una expresión de disparador o una configuración de ítem. No sería perfecto — los modelos de datos difieren — pero daría a los usuarios de Prometheus un camino de migración que no requiera aprender un nuevo lenguaje de expresión desde cero.

Desacoplaría el frontend de PHP. No porque PHP sea malo, sino porque limita el modelo de despliegue. Un binario de frontend en Go o Rust con un servidor web embebido eliminaría la pila Apache/nginx/PHP-FPM, reduciría el consumo de recursos y haría la guía de configuración de 5 pasos en lugar de 12. Zabbix ya distribuye el agente en Go para algunas plataformas. El frontend es la última pieza que requiere una pila LAMP tradicional.

Añadiría un constructor visual de reglas de alerta. El lenguaje de expresión de disparador es potente pero está basado en texto. Un constructor visual donde seleccionas una métrica, estableces un umbral, eliges una ventana temporal y escoges una severidad de un desplegable cubriría el 80% de las necesidades de alerta. El cuadro de expresión de texto seguiría ahí para usuarios avanzados. Las alertas de Grafana tienen esto. Checkmk tiene esto. Zabbix requiere que aprendas avg(/host/key,15m)>90.