Zabbix 8.0: qué cambia de verdad y qué es todavía una diapositiva

Hay un detalle que resume el estado real de Zabbix 8.0 mejor que cualquier nota de prensa: en el registro oficial de contenedores, la 7.4 tiene las etiquetas alpine-latest y latest, y la 8.0 tiene alpine-trunk. Trunk es la rama de desarrollo. A 30 de julio de 2026, lo último publicado de la 8.0 es la beta 2, del 9 de julio. Y aun así lleva meses circulando como si estuviera instalada en algún sitio.

Monitorizamos infraestructura de clientes con Zabbix: clústers Proxmox con Ceph, red propia, servicios y aplicaciones, con Grafana encima para lo que hay que enseñar a alguien que no entra en la consola. Así que la 8.0 nos interesa por lo que va a cambiar en nuestro turno de guardia, no por el titular. Este post es eso: qué trae de verdad, qué es todavía una diapositiva de roadmap, y dónde está la factura del upgrade —que no está en las features, está en las notas de actualización—.

Dónde está la 8.0 exactamente

La cronología pública, tal como está en las release notes oficiales:

Cuando salga, será LTS: soporte completo hasta el tercer trimestre de 2029 y soporte limitado hasta el tercer trimestre de 2031, según la política oficial de ciclo de vida. Es decir: tres años de soporte completo y cinco hasta que se acabe el limitado. Eso es lo que hace que esta versión importe más que una 7.6 cualquiera: la que instales ahora te va a acompañar hasta bien entrada la década.

Lo que el roadmap promete y todavía no aparece en las notas

El roadmap oficial de Zabbix pone bajo la 8.0 LTS una lista que, si te dedicas a esto, es la razón por la que la esperas:

• Recolección y visualización de datos de OpenTelemetry, observabilidad basada en logs y un motor de almacenamiento optimizado para telemetría.
• Motor de procesamiento complejo de eventos: cambios de etiqueta y severidad, filtrado, deduplicación, detección de patrones y procesamiento con JavaScript propio.
• Permisos para proxies y grupos de proxies, con modelo de visibilidad basado en permisos.
• Aplicación móvil para iOS y Android con notificaciones push, y un servidor MCP para que agentes de IA consulten los datos de monitorización.

Ahora la parte incómoda: nada de esa lista aparece en las release notes de alpha1, alpha2, beta1 ni beta2, ni en la página oficial «What's new in Zabbix 8.0» a fecha de hoy. Ni OpenTelemetry, ni el motor de eventos complejos, ni los permisos de proxy, ni la app.

Conviene decir qué significa eso y qué no. No significa que no vaya a llegar: falta una beta o dos y un release candidate, y las funcionalidades grandes a veces aterrizan tarde en el ciclo. Tampoco es un reproche a Zabbix, que publica su roadmap con nombres y fechas —cosa que no hace todo el mundo— y que hace bien en no soltar un LTS a medias. Significa una cosa concreta y operativa: si tu plan de observabilidad para este año se apoya en el OpenTelemetry de Zabbix, hoy te estás apoyando en un roadmap, no en un binario. Y las dos cosas se planifican distinto.

Y un apunte para leer la letra pequeña: lo que sí está fechado como 8.2 (marzo de 2027) incluye NetFlow, descubrimiento automático de topología y gestión centralizada de logs con syslog. Si alguien te ha vendido que eso viene en la 8.0, te ha vendido el roadmap entero de golpe.

Lo que sí está: menos vistoso, más útil

Lo que hay en la beta no da para un titular, y es justo lo que cambia el día a día de quien opera. Tres cosas de verdad:

1. JSON como tipo de valor nativo

Hasta ahora, una respuesta JSON de una API se recogía en un ítem de texto y se guardaba como cadena, con un límite de 64 KB. En la 8.0 hay un tipo de dato JSON de verdad, con límite de 128 MiB (134.217.728 bytes) y validación: un JSON con claves sin comillas, comas colgando o llaves descuadradas se rechaza en vez de guardarse como basura silenciosa. Está disponible en todos los tipos de ítem y prototipos salvo los calculados, en todas las bases de datos soportadas y en Elasticsearch —con la salvedad, también documentada, de que Elasticsearch no acepta arrays JSON: tiene que ser un objeto o un conjunto de objetos—, y también en la exportación en tiempo real y los conectores.

El matiz honesto, que la documentación dice y los resúmenes se saltan: un ítem JSON no se puede usar en un trigger. Para disparar sobre un campo hay que extraerlo con un ítem dependiente de tipo no-JSON. Es decir: cambia dónde guardas el bulto, no cómo alertas. Aun así, para quien recoge salidas de API de Ceph, de un hipervisor o de un cloud —nosotros— es la diferencia entre trocear a mano en el preprocesado y tener el objeto entero disponible.

2. ClickHouse como backend de histórico

Se puede usar ClickHouse para guardar el histórico de valores de ítems, con versiones soportadas de la 25.8.22 a la 26.4. Y con ello llega un cambio de configuración que no es cosmético: los parámetros HistoryStorageURL, HistoryStorageTypes y HistoryStorageDateIndex del servidor quedan sustituidos por HistoryProviders, y en el frontend $HISTORY pasa a $HISTORY_PROVIDERS. Eso no es un widget nuevo: es que el histórico deja de ser «la base de datos» y pasa a ser un proveedor conectable. Si llevas años peleando el tamaño de la tabla history, esa frase te dice más que toda la sección de novedades de interfaz.

3. c-ares: la mejora que solo aprecias a las tres de la mañana

El servidor, el proxy y el agente pueden usar c-ares para todas las peticiones DNS, con caché de consultas y failover de resolutor. Suena a nota al pie. No lo es: quien tiene miles de hosts definidos por nombre sabe exactamente qué pasa cuando el resolutor tose —una avalancha de «no se puede resolver» que parece una caída de red y no lo es—. Que la resolución tenga caché propia y sepa cambiar de resolutor se lleva por delante una familia entera de falsos positivos. Menos falsos positivos por causas que no son la causa.

Y hay más fontanería en la misma línea: caché y reutilización del engineID en SNMPv3, chequeos asíncronos de SNMPv1 y v2 procesados de forma concurrente, arranque del servidor más rápido gracias a la carga por lotes del histórico, y afinado de la lógica de throttling del proxy para que el servidor aguante mejor mientras recupera la caché de histórico. Nada de esto sale en una diapositiva. Todo esto se nota en un cluster con carga.

La factura del upgrade está en las notas de actualización

Aquí es donde deja de ser una lectura entretenida y pasa a ser trabajo. Los mínimos suben, y suben fuerte:

Traducido a lo que significa un martes por la tarde: si tu Zabbix corre sobre el PostgreSQL que venía con la distribución, actualizar Zabbix es, antes que nada, actualizar el motor de base de datos donde vive tu histórico. Dos versiones mayores de PostgreSQL no se saltan con un apt; y si vas de MySQL, el salto de 8.0 a 8.4 arrastra sus propios cambios. Hay además un aviso explícito para quien creó la base de datos con juego de caracteres utf8mb3: se recomienda encarecidamente convertirla a utf8mb4.

Y luego está lo que se rompe callando. La 8.0 elimina macros deprecadas que llevan una década vivas en acciones de notificación:

Fíjate en dónde suelen vivir esas macros: en el texto del correo o del mensaje de guardia. Lo que se rompe no es un gráfico bonito que alguien nota al día siguiente; es el aviso. Y un aviso roto no se detecta hasta que hace falta, que es exactamente el peor momento. Es el mismo patrón del que hablamos en fatiga de alertas: el problema nunca es el gráfico, es que la alerta llegue y signifique algo.

El resto de la lista de «esto te va a doler» de las notas oficiales:

• API: se retira el método massupdate de host, template, hostgroup y templategroup, y también hostinterface.replacehostinterfaces. Si tienes automatizado el alta de hosts contra la API —y deberías—, revísalo antes de tocar nada.
• Preprocesado JavaScript: los métodos nativos de los objetos pasan a ser de solo lectura y se prohíbe modificar prototipos. Cualquier script copiado de un foro que parchease un prototype deja de funcionar.
• Agente: el carácter % se añade a la lista de UnsafeUserParameters en ambos agentes. Si tienes UserParameters con porcentajes, revísalos.
• Ceph: el plugin de Ceph del agente 2 pasa a ser un plugin cargable y requiere pasos de instalación adicionales. A quien opera Ceph esto le toca de lleno —a nosotros, sin ir más lejos—.

Lo que es titular y no cambia cómo operas

Hay una parte de la release que ocupa mucho espacio en los resúmenes y poco en la operación: el nuevo widget de scatter plot para correlacionar dos métricas, la inversión del eje Y en gráficos, las tablas configurables en Hosts, Datos recientes y Problemas, el agrupamiento de marcadores en el geomapa. Está bien. Es un widget. Y hay más de treinta plantillas nuevas —AWS, Azure, Kubernetes, Podman, Oracle Cloud, GLPI—, incluidas plantillas para monitorizar las APIs de OpenAI y de Claude: la monitorización de toda la vida vigilando a la moda del año.

Dos excepciones justas, porque no todo lo visible es humo. La importación y exportación de dashboards sí cambia algo real: convierte los paneles en un fichero que puedes versionar y desplegar igual que el resto de la configuración, en vez de un artefacto que alguien montó a mano y nadie sabe reproducir. Y la UI modernizada importa más de lo que parece cuando tienes a alguien de guardia delante de ella en mitad de un incidente: la ergonomía de una consola no es estética, es tiempo de respuesta. En la 8.0 también llega la plantilla de Proxmox VE convertida a descubrimiento anidado, que encaja con lo que contábamos cuando Proxmox integró Zabbix como monitorización oficial.

Cómo miramos nosotros una versión así

Aquí va nuestra parte, y va sin receta a propósito. Nosotros no operamos Zabbix instalado a mano sobre un Ubuntu. Servidor, proxy y frontend son contenedores versionados sobre nuestra plataforma —Docker Swarm con Portainer y Traefik, desplegada por CI/CD desde GitLab—, igual que el resto de lo que corremos. No es postureo tecnológico: es que con una versión como esta la diferencia se nota en cuatro sitios concretos.

• Probar la beta no es tocar producción. Levantar la trunk contra una copia del histórico y ver qué se rompe —macros, scripts de preprocesado, llamadas a la API— es un entorno más, no una aventura sobre el servidor que vigila a tus clientes.
• El upgrade es cambiar una etiqueta de imagen, con una salvedad honesta que conviene decir en voz alta: el esquema de la base de datos no vuelve atrás solo. Zabbix migra el esquema al arrancar la versión nueva; volver a la anterior exige restaurar la base de datos. La vuelta atrás del contenedor es trivial, la de los datos hay que planificarla. Quien te venda un rollback de un LTS como si fuera gratis, no lo ha hecho nunca.
• Escalar proxies es replicar un servicio, no montar otra máquina. Cuando cada sede o cada cliente necesita su punto de recolección, la diferencia entre declarar un servicio más y aprovisionar un servidor más es la diferencia entre una tarde y una semana.
• Y el orden importa. Con los mínimos de base de datos subiendo dos versiones mayores, separar el motor de datos del servidor de aplicación deja de ser elegancia arquitectónica y pasa a ser la forma de hacer una cosa cada vez.

Hay un detalle que enlaza con todo esto y que ya nos ha costado explicaciones otras veces: trunk, igual que latest, no es una versión. Es un puntero móvil. Correr producción contra un puntero móvil es exactamente la forma de que un día tu monitorización cambie de versión sin que nadie lo decida. Lo contamos entero en «latest» no es una versión.

Qué haríamos con esto en agosto

Nuestra recomendación por defecto va a decepcionar a quien esperaba un plan de migración: no actualices el día que salga la 8.0.0. Espera a las primeras minor. Un LTS que vas a arrastrar hasta 2031 se merece dos meses de que otros encuentren los bordes. Mientras tanto, hay trabajo útil que se puede hacer hoy y que no depende de que Zabbix publique nada:

• Inventaría las macros retiradas. Un grep sobre tus acciones, plantillas y scripts buscando {HOSTNAME, {IPADDRESS, {ACK., {EVENT.ACK.HISTORY}, {PROFILE., {TRIGGER.COMMENT}, {TRIGGER.KEY}, {STATUS} y {USER.ALIAS}. Se puede sustituir hoy, en la 7.x, sin esperar a nada: los reemplazos ya funcionan.
• Busca massupdate en tu automatización. Mismo razonamiento: se puede reescribir antes, con calma, en vez de descubrirlo cuando el alta masiva de hosts devuelva un error.
• Mira la versión de tu base de datos. Ese es el trabajo real del upgrade, y probablemente el que más ventana de mantenimiento consume. Saberlo hoy cambia la conversación de «actualizamos Zabbix» a «actualizamos la base de datos y luego Zabbix».
• Sitúa tu reloj. Si estás en 7.0 LTS tienes soporte completo hasta el 30 de junio de 2027: no hay ninguna prisa, deja que la 8.0 madure. Si estás en 7.4, que es rama estándar, el soporte completo llega hasta la salida de la 8.0 y el limitado hasta el cuarto trimestre de 2026: ahí sí hay un reloj, y conviene que la planificación empiece ahora aunque la ejecución sea en otoño.

Zabbix 8.0 va a ser una buena LTS, probablemente. Pero la versión que hoy puedes evaluar no es la que cuentan los titulares, y la parte que de verdad te va a costar tiempo no es ninguna de las features que aparecen en ellos. Es tu base de datos y son tus macros. Empieza por ahí.

Fuentes (verificadas): fechas y contenido de 8.0.0alpha1 (30 oct 2025), 8.0.0beta1 (22 may 2026) y 8.0.0beta2 (9 jul 2026) — release notes oficiales. Features de la versión (ClickHouse, JSON, tablas configurables, scatter plot, plantillas, c-ares) — «What's new in Zabbix 8.0». Mínimos de base de datos y PHP, macros retiradas, preprocesado JavaScript de solo lectura, UnsafeUserParameters, plugin Ceph cargable y HistoryProviders — notas de actualización oficiales de 8.0. Límite de 128 MiB del tipo JSON y su restricción en triggers — documentación de ítems; la restricción de Elasticsearch con los arrays JSON, en la página de configuración de Elasticsearch. Métodos de API eliminados — cambios de la API en 8.0. Versiones soportadas de bases de datos y PHP — requisitos de 8.0. Contenido y fechas del roadmap (8.0 LTS en septiembre de 2026, 8.2 en marzo de 2027, OpenTelemetry, motor de eventos complejos, app móvil, permisos de proxy, servidor MCP) — roadmap oficial. Ciclo de vida y fechas de soporte de 7.0, 7.4 y 8.0 — política de ciclo de vida y publicación. Etiquetas de las imágenes oficiales de contenedor (latest para 7.4, alpine-trunk para 8.0) — repositorio oficial de Zabbix en Docker Hub. Los grupos de proxies con balanceo y alta disponibilidad existen desde la 7.0, no son novedad de la 8.0 — novedades de 7.0. La lectura de qué pesa y qué no, el criterio de esperar a las primeras minor y el trabajo previo recomendado son nuestros. Imagen: sala de control de la NASA (Johnson Space Center, abril de 2026), dominio público.