Zabbix 8.0 LTS: la monitorización de siempre se asoma a la observabilidad

Un retraso confesado en público

El 8 y el 9 de octubre de 2026, en Riga, Zabbix celebró su Summit de producto. Alexei Vladishev, fundador y CEO, dijo desde el escenario dos cosas que, puestas una junto a otra, tienen su gracia: que la versión 8.0 es un salto gigantesco, casi el lanzamiento de un producto nuevo, y que él mismo esperaba haberla publicado antes. Se fueron añadiendo tantas cosas por el camino (IA, rendimiento, OpenTelemetry) que la fecha se fue corriendo. Para que no vuelva a pasar, desde la 8.2 Zabbix cambia de método: en lugar de publicar cuando está lista, fija el calendario de antemano, con una versión mayor cada marzo y otra cada septiembre.

Que una herramienta nacida para vigilar servidores y redes llegue con retraso al mundo de la observabilidad (ese en el que ya conviven desde hace años Prometheus, Grafana, Jaeger o las plataformas comerciales) es una frase fácil de escribir. Yo mismo la he pensado. Pero también conviene preguntarse qué trae realmente esta versión, cuánto de eso está ya sólido y a quién le puede resultar interesante. De eso va este artículo, con una advertencia por delante: de momento no la he podido probar en laboratorio. Todo lo que sigue viene de la documentación oficial, de lo que se contó en el Summit y de las pocas pruebas públicas que he encontrado. Cuando haya más datos de otros usuarios sobre cómo se comporta y qué estabilidad tiene, montaré mi propia prueba y lo contaré.

Dónde está el producto hoy

La 8.0 todavía no es la versión final. A mediados de octubre estaba disponible la primera release candidate (RC1, «candidata a versión final»: un paquete que, si no aparecen fallos graves, se convierte en la definitiva) y, según el blog oficial, la LTS se esperaba para principios de noviembre, tras una RC2 y posiblemente una RC3. LTS significa long term support: una versión que recibe correcciones durante años y sobre la que las empresas suelen estandarizar. Un artículo técnico publicado el 24 de octubre ya probaba paquetes de la RC2, así que el proceso avanza. Eso sí, la documentación de la 8.0 sigue marcada como versión en desarrollo, y la propia Zabbix avisa de que el detalle del nuevo motor de correlación de eventos llegará cuando salga la versión estable.

La propuesta: una sola plataforma

El mensaje de Zabbix es sencillo: una plataforma integrada, open source, que recoge datos, los visualiza, detecta anomalías, alerta y almacena, sin obligarte a ensamblar una pila con piezas de distintos fabricantes. Según su CEO, hace cerca de veinte años el foco estaba en sistemas operativos y redes; hoy cubre desde el hardware hasta Kubernetes y los recursos en la nube. A eso suman un argumento comercial que conviene atribuir tal cual a quien lo dice: precio fijo, sin costes ligados al número de dispositivos, hosts o usuarios.

En lo que ya es monitorización de infraestructura, la 8.0 trae plantillas nuevas (Hyper-V, Proxmox con una supervisión más profunda, Podman, un panel multinube para AWS, Azure y GCP, y hasta el seguimiento del gasto en proveedores de IA como OpenAI o Anthropic), un tipo de dato JSON nativo y un rendimiento que Zabbix presume de muy superior al de la 7.4. La cifra que se mostró en el Summit fue de 1,4 millones de métricas por segundo sostenidas en un portátil. Es una demostración del fabricante, no una prueba independiente: tómala como indicio, no como garantía.

APM con OpenTelemetry: la pieza gorda

Lo que de verdad cambia el perfil del producto es el APM (application performance monitoring, vigilar cómo se comporta una aplicación por dentro) basado en OpenTelemetry, el estándar abierto para que las aplicaciones emitan su telemetría. La idea que hay detrás es la de las trazas: cuando alguien navega por tu web, esa petición atraviesa varias capas (el servidor web, la lógica de negocio, la base de datos), y una traza (trace) es el recorrido completo, igual que el número de seguimiento de un paquete que pasa por varios almacenes. Cada escaneo en un almacén es un span: una operación concreta con su inicio y su duración. Con las trazas, en vez de saber solo que «el paquete tarda», ves en qué almacén se queda parado.

Como en Zabbix varias piezas tienen nombres que se prestan a confusión, un repaso rápido de quién es quién. El agente es el programa que se instala en cada máquina vigilada y mide el sistema por dentro (procesador, disco, procesos). El servidor es el cerebro: guarda la configuración y el historial en una base de datos, evalúa las condiciones de alerta (los triggers) y sirve la interfaz web. El proxy no es un agente, sino un intermediario: recoge datos en nombre del servidor y se los reenvía, algo que se usa sobre todo en sedes remotas o para repartir carga, como una oficina de correos local que agrupa los envíos antes de mandarlos a la central. Lo nuevo es que, en la 8.0, el proxy también hace de receptor de la telemetría de las aplicaciones.

En Zabbix el recorrido es este: la aplicación (o un OpenTelemetry Collector delante de ella) envía los datos al proxy de Zabbix mediante OTLP, el protocolo de OpenTelemetry, sobre gRPC (un protocolo de llamadas remotas de uso muy extendido), por defecto en el puerto 4317. El proxy los guarda en ClickHouse, una base de datos pensada para ingerir y consultar enormes volúmenes de datos. El frontend los muestra en un menú nuevo, APM, con tres vistas (trazas, métricas y logs), y el servidor los lee con un tipo de ítem también nuevo, Telemetry query, para convertirlos en valores que pueden alimentar triggers, gráficos y alertas como cualquier otro.

Tres aclaraciones que la propia documentación y los partners de Zabbix subrayan y que se pasan por alto fácilmente. Primera: Zabbix no instrumenta tu aplicación. Si no hay un SDK de OpenTelemetry (o un colector) emitiendo datos, instalar Zabbix no crea trazas. Segunda: el servidor no tiene colector propio; el receptor integrado vive en el proxy, de modo que incluso quien nunca ha usado proxies necesita uno para esta función. Puede ir en la misma máquina que el servidor, eso sí, con dos cuidados: el proxy no puede compartir base de datos con el servidor (lo más sencillo es darle una SQLite propia) y ambos escuchan por defecto en el puerto 10051, así que habría que cambiar uno. Tercera: el colector no arranca solo. Los paquetes oficiales del proxy ya se compilan con la opción --with-apm, pero el parámetro StartAPMCollectors vale 0 por defecto y hay que ponerlo a 1, además de indicar dónde está ClickHouse con TelemetryProvider.

ClickHouse: la base de datos que no es la de siempre

Zabbix guarda desde siempre su configuración y su historial en una base de datos relacional clásica: MySQL, MariaDB o PostgreSQL. Esas bases almacenan los datos por filas, como un archivador con una ficha por registro, y son ideales para leer o modificar un registro completo («dame todo sobre el host 42»). ClickHouse es una base de datos columnar: guarda cada columna por separado. Imagina una hoja de cálculo enorme y que solo quieres la media de la columna «duración». Con el archivador de fichas hay que sacar todas las fichas enteras; con el almacenamiento por columnas se lee únicamente esa columna, y además se comprime muy bien porque los valores de una misma columna se parecen entre sí.

Eso encaja con la telemetría, donde llegan millones de registros que casi nunca se modifican y que se consultan sobre todo de forma agregada («el p95 de la duración de todos los spans de la última hora»). Es la razón por la que ClickHouse se usa tanto en analítica y observabilidad.

Qué implica en Zabbix. No sustituye a la base de datos principal: la configuración sigue en MySQL, MariaDB o PostgreSQL. ClickHouse es un destino adicional con dos usos: fuente de la telemetría (imprescindible para el APM) y, de forma opcional, almacén del historial de los ítems de siempre (hay scripts para migrar el historial existente). Se declara con el parámetro TelemetryProvider en el servidor y en el proxy (con la URL, la base de datos y las credenciales; en la documentación el ejemplo usa el puerto HTTP 8123) y en la sección Administration > Data source de la interfaz. Lo escribe el proxy y lo leen el servidor y el frontend, así que los tres deben poder alcanzarlo.

La guía de instalación de ClickHouse de la documentación añade algunas precisiones. Trata sobre todo del historial de ítems, que se configura con otro parámetro distinto (HistoryProvider, no el de telemetría): un script, history_all.sh, crea las tablas, y la retención por defecto es de 31 días. El housekeeper de Zabbix (el proceso que borra datos antiguos) no limpia ClickHouse, así que la retención se ajusta en el propio ClickHouse, y no se calculan tendencias (trends). Para el APM la guía remite a la sección Data source, y ahí me queda una duda: no he visto descrito cómo se crean las tablas de trazas, logs y métricas de OpenTelemetry (en el laboratorio público que cité solo existía la de trazas). Será de lo primero que quiera aclarar en mi prueba. Los ejemplos de la documentación usan ClickHouse 26.4.

Del dato a la alerta (y sus trampas)

El puente entre la telemetría y el Zabbix clásico es el ítem Telemetry query. En una demostración publicada por initMAX (partner de Zabbix, con datos sintéticos declarados como tales) se calcula el percentil 95 del tiempo de preparación de un pedido. El percentil 95, o p95, es el valor por debajo del cual queda el 95 % de las peticiones: sirve para ver cómo les va a los usuarios con peor suerte, algo que la media esconde. Sobre ese valor se pone un trigger, por ejemplo «avisa si pasa de 800 ms».

Ahí aparecen detalles que un ingeniero con experiencia agradecerá conocer. Las duraciones llegan en nanosegundos, así que hay que convertirlas con un paso de preprocesado. Un simple conteo sobre trazas cuenta spans, no pedidos: si un servicio genera tres spans por operación, contarás el triple, y hay que filtrar por el nombre de la operación concreta. Y la ventana de agregación (granularidad y desplazamiento temporal) tiene que ajustarse al retraso real con que llegan los datos, porque si no calculas percentiles sobre intervalos a medio llenar. Otra limitación práctica: un problema detectado por un trigger no se enlaza automáticamente con una traza concreta; hay que buscarla en APM por hora, servicio o identificador de traza.

Las tres señales, con lupa

Aquí está, para mí, el centro de la cuestión: la monitorización de infraestructura Zabbix ya la hace bien desde hace mucho; lo que está por demostrar es la calidad de la observabilidad. Sobre el papel, las tres señales están. De las trazas se ve el árbol de spans y un diagrama en cascada con los tiempos, con filtros por servicio, duración, estado y atributos. Los logs se muestran de forma estructurada (hora, severidad, atributos) y se cruzan con la traza mediante su identificador. Las métricas admiten los tipos habituales de OpenTelemetry: gauge (un valor que sube y baja), sum, histogram y exponential histogram.

Lo que no he podido comprobar, y por eso lo dejo como pregunta y no como afirmación, es qué ocurre cuando el volumen aprieta. El colector del proxy permite fijar un máximo de mensajes por segundo y rechaza lo que lo supere; que esos datos se reintenten o se pierdan depende del exportador. Tampoco he visto en la documentación nada sobre muestreo inteligente de trazas (quedarse con las más interesantes en vez de con las primeras que llegan), algo que en observabilidad marca la diferencia cuando de verdad hay tráfico. Un laboratorio con carga real aclarará esto mejor que cualquier lectura de manuales.

Correlación de eventos: separar la causa del síntoma

La otra novedad gorda es el CEP (complex event processing, procesamiento complejo de eventos). Cuando se cae algo importante, el panel de problemas se llena de decenas de alertas, y solo una o dos son la causa; el resto son consecuencias. Es como un triaje en urgencias: la fiebre es el síntoma, la infección es la causa, y lo que importa es no tratar cada síntoma como si fuera una enfermedad distinta.

El motor trabaja con ventanas de tiempo deslizantes: durante, por ejemplo, diez minutos, los eventos que entran forman un único contexto. Sobre ellos se definen reglas que pueden agrupar eventos, marcar el primero como causa y los siguientes como síntomas, subir o bajar la severidad, añadir etiquetas o suprimir alertas. Para los casos que no caben en una regla sencilla hay un modo de coincidencia de patrones que se escribe en JavaScript. Conviene ser claros con lo que es: un sistema determinista de reglas que escribes tú, no una inteligencia que descubre la causa por sí sola. Útil, pero distinto. Las reglas de correlación globales anteriores siguen existiendo y no se convierten solas.

IA: MCP sí, LLM dentro de Zabbix, no

Sobre inteligencia artificial hay que separar lo que existe de lo que se anuncia. Lo que existe es un servidor MCP (Model Context Protocol, un estándar para que un asistente de IA hable con otras herramientas) que se interpone entre la API de Zabbix y el agente que prefieras. Según la documentación, no guarda estado entre peticiones, el agente usa un token de API y por tanto solo ve y hace lo que el dueño del token puede, los cambios quedan en el registro de auditoría bajo ese usuario, y se pueden permitir o denegar herramientas concretas. Detalle importante: la documentación indica que no incluye limitación de peticiones. Y, según initMAX, los roles de usuario nuevos nacen en la 8.0 con el acceso a la API desactivado, así que habrá que habilitarlo expresamente. Existe además un servidor MCP de terceros, del propio initMAX, con muchas más herramientas.

Lo que no existe es un modelo de lenguaje dentro de Zabbix. Su CEO fue claro: incorporar un LLM al producto, «muy probablemente no». Lo que sí llegará, sin fecha concreta, son asistentes dentro del producto que usen modelos externos, públicos o privados; por ejemplo, describir un dispositivo y pedir que genere la plantilla. Lo digo porque en algunos resúmenes que circulan se da a entender que Zabbix ya incorpora inteligencia propia para diseñar triggers, y eso no es lo que dijo el fabricante.

Lo que cuesta adoptarlo

Para el APM hay que añadir ClickHouse a la ecuación, con todo lo que implica: más disco, más mantenimiento y diseñar su alta disponibilidad si el APM es crítico (según initMAX, tener dos nodos no es alta disponibilidad: hacen falta tablas replicadas y un servicio de coordinación). La documentación añade un detalle práctico: el servidor y el frontend solo admiten una URL de ClickHouse, de modo que con un clúster recomienda poner un balanceador delante. ClickHouse no es obligatorio para toda instalación; lo es para esta función, y de forma opcional también para el historial de métricas.

Un detalle de cara a laboratorios en Docker: la documentación dice que los paquetes oficiales del proxy se compilan con soporte APM, pero el autor de un laboratorio público con RC1 cuenta que las imágenes oficiales de Docker no traían el colector y tuvo que compilar el proxy él mismo. Habrá que comprobar si eso cambia con la versión final. La página de actualización de contenedores de la documentación solo habla de la imagen zabbix-proxy-sqlite3 y no menciona APM, así que con contenedores sigue siendo una duda; con paquetes no lo es, y por eso mi consejo para un laboratorio es instalar con paquetes.

Instrumentar: la diferencia con OneAgent y los costes que no salen en la factura

Hay una diferencia de fondo con plataformas como Dynatrace. «Instrumentar» una aplicación es ponerle sensores para que cuente qué hace por dentro, como colocar contadores en las tuberías de un edificio: sin ellos, el fontanero solo ve si sale agua o no. En Dynatrace, el OneAgent se instala en la máquina y, para las tecnologías que soporta, inyecta esa instrumentación él mismo sin tocar el código, aunque también acepta OpenTelemetry. En Zabbix, el agente sigue siendo el de infraestructura y no genera trazas: el camino es OpenTelemetry, y alguien tiene que ponerlo en cada aplicación. La distancia es menor de lo que parece, porque OpenTelemetry ofrece instrumentación automática («sin código») para lenguajes como Java, Python, Node.js o .NET, que se activa al arrancar la aplicación sin cambiarla. Pero alguien tiene que activarla, versionarla y mantenerla. No he comparado cómo lo hacen Datadog o New Relic, que tienen sus propios agentes y bibliotecas, y prefiero no afirmar más de lo que sé.

Aquí entran los costes ocultos. En licencia no hay comparación posible: Zabbix no cobra por dispositivo, host ni usuario. Pero una factura no es solo licencia. Hay que sumar el tiempo del equipo para instrumentar cada aplicación y mantenerlo cuando cambian los lenguajes y las bibliotecas, la operación del proxy y de un colector, ClickHouse con su disco, su retención, sus copias y su alta disponibilidad (la documentación indica 31 días por defecto para las tablas de historial; para las de telemetría no lo he visto), el conocimiento nuevo (casi nadie en un equipo de Zabbix sabe ClickHouse de serie) y las decisiones sobre cuánto muestrear y qué guardar para que el volumen no se dispare. No digo que salga caro: digo que el coste se desplaza de la licencia al tiempo de las personas, y conviene ponerlo en la cuenta antes de comparar.

Migrar de la 7 a la 8: servidor, proxies y agentes

Esta es la pregunta que más dudas me genera, y la respuesta es más tranquilizadora de lo que sugieren algunos vídeos. Según la tabla de compatibilidad de la documentación oficial 8.0, los agentes sobreviven: el agente clásico tiene que ser como mínimo de la 1.6 y no más nuevo que la 8.0, y el agente 2 vale desde la 4.4. Es decir, tus agentes de la 7 funcionan con un servidor 8.0, y actualizarlos solo es necesario si quieres aprovechar las novedades. Lo que sí desaparece es el soporte de los agentes anteriores a la 1.6, que usan un protocolo antiguo en texto plano y XML.

Con los proxies la situación es más delicada, aunque no tan drástica como a veces se cuenta. Un proxy 7.0, 7.2 o 7.4 contra un servidor 8.0 se considera «desactualizado»: sigue enviando datos y ejecutando comandos remotos, pero deja de recibir actualizaciones de configuración, de modo que un ítem nuevo no le llegará. Los anteriores a la 7.0 ya no son compatibles. La recomendación de la documentación, reflejada también en las pruebas públicas, es actualizar primero el servidor y después los proxies uno tras otro. Un aviso heredado de la documentación de la 7.0 y que conviene revisar en la de la 8.0: los proxies con SQLite recrean su base de datos tras actualizarse, así que lo pendiente de enviar se pierde.

Lo más valioso que he encontrado sobre cómo va la migración real es una prueba publicada el 24 de octubre que actualiza dos servidores 7.0 a la 8.0 RC2 (Ubuntu 26.04 y Rocky Linux 10). Es una prueba pequeña, con bases de datos casi vacías, y su autor es el primero en advertirlo, pero deja varias lecciones. El cambio de esquema de la base de datos tardó unos 9 segundos con MariaDB y unos 28 con PostgreSQL, un dato que no sirve para extrapolar a una base de cientos de gigas. Lo que más tropiezos dio no fue la base de datos sino los requisitos y un cambio ya antiguo: la 8.0 exige PHP 8.2 o superior y sube los mínimos de base de datos (MySQL 8.4, MariaDB 10.11, PostgreSQL 15, TimescaleDB 2.20), de modo que un servidor de los de «instalado hace años y nadie lo toca» puede quedarse sin arrancar. El servidor se niega a iniciarse con una versión no soportada, aunque eso sí, se detiene antes de modificar el esquema. Oracle como base de datos ya no está soportado desde la 7.2. Y quien edite a mano la configuración del servidor web puede encontrarse una página de «intervención manual» porque, desde la 7.2, el frontend vive en una ruta nueva (/usr/share/zabbix/ui).

La regla de oro es la de siempre, y por eso la dejo clara: el servidor reescribe el esquema al arrancar por primera vez y nada lo deshace, así que la copia de seguridad de la base de datos (y, si es una máquina virtual, una instantánea) es el único camino de vuelta. Además, las plantillas y los tipos de medio no se actualizan solos; en la 8.0 las basadas en HTTP verifican los certificados TLS por defecto y eso solo se obtiene importando las nuevas. Si vienes de versiones muy anteriores a la 6.0, un vídeo de Custos Monitoring avisa de una migración de las tablas de histórico a claves primarias que no se hace automáticamente por el tiempo que lleva; la documentación oficial le dedica un apéndice, y es de lo primero que leería. Para producción, todos los guías coinciden en esperar a que los paquetes salgan del repositorio de versiones estables y no del de pruebas.

¿Llegan tarde?

Mi tesis inicial era que sí, y creo que a medias se sostiene. Hay argumentos a favor: el APM exige añadir ClickHouse, el enlace de un problema con su traza es manual, la topología (saber qué depende de qué) como tipo de dato propio es algo que Alexei situó como futuro y no como parte de la 8.0, y herramientas nativas de OpenTelemetry llevan años perfeccionando precisamente la parte de investigar trazas. Si lo que buscas es lo mejor en análisis de trazas, esta primera versión no parte de ahí.

Pero esa no es toda la cuestión. Zabbix no compite por ser la mejor herramienta de trazas, sino por ser la herramienta de quien ya la usa para infraestructura, redes y servidores, y que ahora puede añadir APM, correlación de eventos y acceso para agentes de IA sin cambiar de plataforma ni de modelo de coste. Para una organización con un Zabbix bien implantado, poder decir «las trazas de esta aplicación crítica también entran aquí» puede valer más que la mejor cascada del mercado. Y que la IA se conecte por MCP, y no atada a un único proveedor, es una decisión coherente con una herramienta abierta.

Hay una consecuencia práctica, y aquí hablo de intuición, no de datos: creo que la adopción de la 8.0 será gradual. Migrar un Zabbix en producción es una decisión delicada (mínimos nuevos de PHP y de base de datos, proxies que hay que actualizar, un esquema que no se deshace), y quien solo monitoriza infraestructura y está contento con lo que tiene no tiene prisa: lo razonable es esperar a las primeras versiones menores y ver cómo se portan. Quien sí tendrá motivo para dar el paso antes es quien necesite el APM o el servidor MCP. Para la parte de infraestructura, ya veremos.

Lo que decidirá si esto es una buena noticia o un parche es la calidad de las tres señales cuando hay tráfico real, y eso nadie puede afirmarlo todavía.

Lo que sé y lo que no sé

Para ser honesto con quien lea esto: no he encontrado ningún caso en producción ni reseñas independientes de la 8.0. Lo que hay son pruebas sintéticas: un laboratorio público con Docker que envió trazas de prueba durante treinta segundos y las vio aparecer en el menú APM (en su montaje solo existía la tabla de trazas, por lo que los ítems de logs y métricas no funcionaban), una demostración de un partner con datos simulados y la prueba de actualización que comentaba antes. Todo ello sobre candidatas a versión final. Por eso mi plan es esperar a que haya más experiencias de otros usuarios (sobre todo de estabilidad) y entonces montar un pequeño laboratorio con una aplicación web que genere trazas, para comprobar lo que aquí he dejado como preguntas: si la cascada muestra los spans de base de datos, cómo se porta el límite de mensajes bajo carga, cuánto tarda en saltar un trigger sobre un p95 y cuánto consume ClickHouse. La idea es un montaje sencillo y barato: un servidor 8.0 limpio en un portátil, apuntando a él los agentes que ya tengo en Linux y Windows (los de la 7 valen), y en la máquina de la aplicación un proxy con su colector APM, con ClickHouse en otro equipo del laboratorio. Si funciona como promete, Zabbix habrá llegado tarde pero llegará bien. Y eso, en un terreno donde llegar el primero no ha sido nunca lo que ha decidido quién se queda, no es poca cosa.

Fuentes:

• Zabbix 8.0 LTS: las novedades presentadas en el Zabbix Summit 2026 (blog oficial de Zabbix)
• Documentación oficial de Zabbix 8.0: compatibilidad de versiones y parámetros del proxy (más las notas «What’s new» de la 8.0)
• The new Zabbix 8.0 LTS is here! (initMAX)
• Upgrade Zabbix 7.0 to 8.0 LTS on Ubuntu 26.04 and Rocky Linux 10 (ComputingForGeeks)