Volver al Blog

Zabbix 8.0 pide PostgreSQL 15 y el Ubuntu 22.04 trae la 14

Sala de ordenadores con filas de armarios de servidores y carteles escritos a mano sobre cada fila

Zabbix 8.0 LTS se publicó el 5 de noviembre de 2026, y el resumen que va a circular esta semana es la lista de novedades: OpenTelemetry, ClickHouse, procesamiento complejo de eventos, servidor MCP, app móvil. Todo eso hay que montarlo: no aparece encendido al día siguiente de actualizar. Lo que sí aparece sin pedirlo son seis suelos de versión que suben debajo del producto, y uno de ellos deja al servidor sin arrancar sin que exista ningún parámetro para convencerlo.

Llevamos la monitorización de nuestros clientes con Zabbix y SmokePing, así que estas actualizaciones no las leemos como noticia sino como ventana de trabajo. La primera cuenta que hicimos esta mañana fue coger la tabla de mínimos de la 8.0 y cruzarla contra lo que sirven de verdad los repositorios de las distribuciones donde están montados esos servidores. El resultado se resume en el título.

Seis suelos que suben a la vez

Las notas de actualización de la 8.0.0 traen una sección corta titulada Database versions y, unas líneas más arriba, otra para PHP. Juntas son esto, y las flechas de la tabla son suyas:

Pieza Mínimo en 7.4 Mínimo en 8.0 Rango soportado
MySQL / Percona8.0.308.4.08.4.0 – 9.7.X
MariaDB10.5.0010.11.0010.11.00 – 12.3.X
PostgreSQL13.015.015.0 – 18.X
TimescaleDB2.13.02.20.02.20.X – 2.29.X
Elasticsearch7.0.08.0.08.0.0 – 9.5.X
PHP (interfaz web)8.0.08.2.08.2.0 – 8.5.X

La cuarta columna conviene leerla despacio porque los rangos están cerrados por arriba: la línea de PostgreSQL dice de la 15 a la 18, y la de MariaDB termina en la 12.3. El margen de maniobra tiene techo además de suelo, y eso cambia a qué versión saltas si vas a mover la base de datos de todas formas. Hay un séptimo mínimo menor que solo afecta a quien usa la pasarela de Java: la biblioteca Logback pasa de 1.5.16 a 1.5.25.

Con dos de esas filas no podemos presumir de primicia: cinco de los seis números ya los adelantamos el 30 de julio leyendo la beta, cuando la mitad de la 8.0 todavía era una diapositiva. Lo que no estaba entonces es el sexto —Elasticsearch— ni la columna de la derecha, y son justo los dos que deciden el orden del trabajo.

Cinco tienen escalera. Uno es un muro

Zabbix lleva años con una válvula de escape para esto. El fichero del servidor tiene un parámetro, AllowUnsupportedDBVersions, descrito en una línea — "Allow server to work with unsupported database versions" — y con valor por defecto 0. Ponerlo a 1 es la diferencia entre un arranque que falla y un arranque que avisa. No es gratis y no lo recomendamos como plan, pero existe y a veces compra la noche que necesitas.

Salvo en una fila. Las propias notas de actualización lo escriben sin dejar hueco: "Zabbix server does not start if the Elasticsearch version is older than 8.0.0; this cannot be overridden with the AllowUnsupportedDBVersions parameter". De los seis suelos, cinco se pueden pisar a sabiendas y asumiendo el riesgo. El de Elasticsearch no: ahí la actualización de Zabbix depende de que antes hayas actualizado otro producto entero, y el orden no lo eliges tú.

Dónde cae tu distribución

Esta tabla no está en ninguna nota de versión porque cruza dos fuentes que nadie junta: los mínimos de arriba y lo que sirve el archivo de cada distribución. La hemos mirado esta mañana, paquete a paquete, en packages.debian.org y packages.ubuntu.com, para las cinco distribuciones que uno se encuentra hoy en producción:

Distribución PostgreSQL MariaDB MySQL PHP
Debian 11 bullseye13 ✗10.5.29 ✗—7.4 ✗
Debian 12 bookworm15 ✓10.11.19 ✓—8.2 ✓
Debian 13 trixie17 ✓11.8.6 ✓—8.4 ✓
Ubuntu 22.04 jammy14 ✗10.6.22 ✗8.0.46 ✗8.1 ✗
Ubuntu 24.04 noble16 ✓10.11.13 ✓8.0.46 ✗8.3 ✓

Lo que más nos ha sorprendido está en la cuarta fila. Ubuntu 22.04 no llega a ninguno de los cuatro paquetes que sirve, y no es una distribución abandonada: tiene soporte estándar hasta mayo de 2027. Montar la 8.0 ahí significa meter repositorios externos para la base de datos y para PHP, y pasar a mantenerlos tú. Un poco más abajo, la 24.04 falla solo en una columna, pero esa columna importa: sirve 8.0.46 de MySQL cuando el suelo está en 8.4.0, de modo que ninguna LTS de Ubuntu trae hoy un MySQL que valga y quien use ese motor cambia de repositorio aunque esté en la distribución más reciente.

Y una casualidad que dice bastante: Debian 12 clava los tres mínimos exactos —PostgreSQL 15, MariaDB 10.11, PHP 8.2—. El único archivo que encaja sin tocar nada es el de la versión que en agosto dejó de ser la estable y hoy figura como oldstable en debian.org.

Zabbix, por lo demás, no esconde la consecuencia. Su propia página de requisitos la escribe en una frase: "Although Zabbix can work with databases available in the operating systems, for the best experience, we recommend using databases installed from the official database developer repositories". Es decir, el fabricante ya asume que la base de datos no va a salir de tu distribución. Lo que no dice es lo que eso cuesta: un repositorio más en el inventario, una clave más que caduca, y una pieza más que se actualiza con su propio calendario.

Dónde pusieron la raya: medición en el repositorio

Hay una forma de ver qué considera aceptable el propio fabricante, y no está en la documentación: está en el índice de paquetes. Descargamos esta mañana los ficheros Packages del componente independiente de arquitectura de repo.zabbix.com/zabbix/8.0/stable para seis distribuciones. En Debian 11 y Ubuntu 20.04 —las dos con PHP 7.4— el repositorio sirve exactamente dos paquetes, la pasarela de Java y los scripts SQL: no hay interfaz web. En Debian 12, Debian 13, Ubuntu 22.04 y Ubuntu 24.04 sirve cinco, y entre ellos sí está zabbix-frontend-php.

Antes de sacar punta conviene poner delante la explicación aburrida: Debian 11 salió del soporte del equipo de LTS el 31 de agosto de 2026 y Ubuntu 20.04 del soporte estándar en mayo de 2025, así que lo más probable es que Zabbix sencillamente no construya interfaz para distribuciones muertas. Lo que no cambia es la consecuencia. La raya, sea cual sea el motivo, no quedó trazada en el mínimo publicado: Ubuntu 22.04 trae PHP 8.1 —por debajo del 8.2.0 que exige la 8.0— y aun así recibe su paquete de interfaz web, 2:8.0.0-1+ubuntu22.04, cuyas dependencias no llevan ninguna versión: php-mysql | php-pgsql, php-mbstring, php-bcmath, php-xml, php-gd, php-ldap, php-curl, fonts-dejavu | ttf-dejavu-core | ttf-japanese-gothic. Traducido: apt no te va a parar. El paquete instala contra el PHP 8.1 de la distribución sin una sola queja, y el requisito aparece después, cuando la interfaz se encuentra con un intérprete que no está en su rango.

La misma frontera reaparece en la función estrella. Para usar el nuevo monitoreo de aplicaciones por OpenTelemetry hace falta un proxy compilado con soporte de APM, y las notas dicen dónde viene ya incluido: Debian 12 o posterior, Raspberry Pi OS 12 o posterior, Ubuntu 24.04 o posterior. Para los demás sistemas —RHEL 10 tiene receta propia, con el repositorio EPEL, el CRB habilitado y un paquete aparte—, "upgrade Zabbix proxy from sources with the --with-apm option". En Ubuntu 22.04, la novedad del año se compila a mano.

El 12 de noviembre caducan dos cosas a la vez

La tabla de ciclo de vida de Zabbix ya tiene fechas exactas donde hasta octubre había trimestres: la 8.0 LTS salió el 5 de noviembre de 2026, con soporte completo hasta el 30 de noviembre de 2029 y limitado hasta el 30 de noviembre de 2031. Y en la fila de abajo, la 7.4 pierde el soporte completo el 12 de noviembre de 2026 — dentro de cinco días. Hace dos semanas contamos que esa casilla no llevaba fecha sino la cadena until 8.0 LTS; ahora ya tiene número.

El 12 de noviembre de 2026 es también, por pura coincidencia de calendarios ajenos, la fecha de fin de vida de PostgreSQL 14: su última versión menor es la 14.24 y la política de versiones del proyecto la retira ese día. Es decir, el mismo día que tu 7.4 deja de recibir funciones y correcciones, la base de datos que trae Ubuntu 22.04 deja de recibir parches. Si quieres el detalle de por qué ese vencimiento no te lo va a avisar nadie, lo escribimos hace unos días: PostgreSQL 14 caduca y nadie te va a avisar.

Y ahora el matiz que cambia la decisión, y que sale de la misma tabla de PostgreSQL: la 15 —el mínimo que te pide Zabbix 8.0— caduca el 11 de noviembre de 2027. Saltar exactamente al suelo compra un año. La 16 llega a noviembre de 2028 y la 17 a noviembre de 2029, que es casualmente el mes en que la propia 8.0 pierde el soporte completo. Si vas a parar el servidor y migrar la base de datos de todas formas, elegir el mínimo por prudencia es la opción que más veces te obliga a repetir la ventana.

Lo que se rompe sin decir nada

Un suelo de versión avisa: el servicio no arranca y lo ves. El resto de la lista de cambios rompedores es peor, porque todo sigue funcionando y lo que falta son avisos que ya no salen. Los cinco que apuntamos para revisar después de cada actualización:

  • 1.Macros retiradas en las plantillas de mensaje. Se van {HOSTNAME<1-9>}, {IPADDRESS<1-9>}, {STATUS}, {USER.ALIAS}, {TRIGGER.KEY}, {ACK.MESSAGE} y el resto de la familia {ACK.*} y {PROFILE.*}. Un correo de aviso que ya no dice qué máquina es sigue llegando igual.
  • 2.La lista blanca de la API vacía ahora deniega. Antes se ignoraba y se permitía todo. Para no romper nada, dice la nota, "the upgrade adds the * wildcard (any method) to all user roles that have Allow list selected but no methods specified". O sea: la medida de compatibilidad deja esos roles con la API entera abierta, y revisarlo queda de tu lado.
  • 3.El webhook de Microsoft Teams ya no funciona. No es un aviso de futuro: el tipo de medio clásico se apoyaba en los conectores de Office 365, que Microsoft retiró el 22 de mayo de 2026, y las notas lo dan por no longer functional. La sustitución es el webhook de flujos de trabajo, y hay que migrar la configuración a mano.
  • 4.Verificación TLS por defecto en plantillas y webhooks. Todo lo que hable HTTPS valida ahora el certificado del extremo. Es la decisión correcta, pero si monitorizas un trasto con certificado autofirmado, el día que actualices esa plantilla el ítem se queda sin datos. Se gobierna con la macro nueva {$HTTP.TLS.VERIFY} y sus tres valores: none, peer o full.
  • 5.El complemento de Ceph cambia de modo y de paquete. El modo restful sigue siendo el valor por defecto —marcado ya como obsoleto— y las notas avisan de que no funcionará con Ceph 20 (Tentacle) o posterior, por la retirada del módulo mgr/restful. El modo native habla el protocolo nativo msgr2, solo va en Linux y a partir de Ceph 16, y la misma página advierte de que "the user credential set differs for each mode and they are not compatible with each other". Además, el complemento pasa a ser cargable y a instalarse aparte. Quien ya saltó a Tentacle y no tocó el agente tiene las gráficas planas.

Cuándo no saltaríamos todavía

No por desconfianza: una LTS recién salida es una buena noticia para cualquiera que planifique a tres años. Pero hay tres situaciones en las que la prisa cuesta más de lo que ahorra:

  • —Si estás en 7.0 LTS. Tienes soporte completo hasta el 30 de junio de 2027. El 12 de noviembre no es tu fecha; la tuya está a siete meses y medio y da para hacer el salto de base de datos con cabeza, separado de la actualización de Zabbix.
  • —Si el salto de base de datos cae en la misma ventana. Actualizar Zabbix y cambiar de motor a la vez convierte cualquier fallo en una discusión sobre cuál de las dos cosas lo causó. Dos ventanas en dos semanas se explican mejor que una ventana larga que no se sabe deshacer.
  • —Si lo que te mueve es la lista de novedades. APM, ClickHouse, procesamiento complejo de eventos y el servidor MCP son proyectos con su presupuesto. Ninguno se enciende al actualizar. Si la razón para saltar esta semana es OpenTelemetry, el trabajo de verdad empieza después de la ventana y conviene presupuestarlo entero.

Las cinco comprobaciones antes de poner fecha

Ninguna modifica nada. Las cinco caben en una tarde y determinan si tu actualización es una tarde o un proyecto:

  • 1.La versión exacta del motor: SELECT version(); en PostgreSQL o SELECT VERSION(); en MySQL y MariaDB. Apúntala con los tres números.
  • 2.De dónde salió ese paquete: apt policy postgresql o dnf list installed. Si viene del archivo de la distribución, la tabla de arriba te dice ya si pasas o no.
  • 3.php -v en el servidor de la interfaz, que no siempre es la misma máquina que la base de datos ni la misma que el servidor de Zabbix.
  • 4.Si usas Elasticsearch para el histórico, su versión antes de tocar nada: es el único suelo sin válvula de escape y define el orden de todo el plan.
  • 5.Una búsqueda de HOSTNAME1, IPADDRESS1, USER.ALIAS y ACK. en tus plantillas de mensaje. Lo que aparezca es un aviso que después de la ventana dirá menos de lo que decía antes.

Dos horas de mañana y lo que queda apuntado en el cuaderno no es una lista de funciones: es la versión de cuatro motores, la fecha de un repositorio y el nombre del paquete que instaló alguien que ya no trabaja aquí. La 8.0 es una buena LTS y acabaremos poniéndola en todas partes. El calendario, sin embargo, lo marca la capa de abajo.

En everyWAN llevamos la monitorización como parte del soporte IT 24×7 y estas ventanas entran en el mantenimiento informático de quien nos tiene contratado el parque. No revendemos licencias de nadie, así que cuando decimos que tu salto a la 8.0 puede esperar a enero, no estamos dejando de facturar un proyecto.

Fuentes (verificadas el 07-11-2026): fecha de publicación y contenido de la versión — Release Notes for Zabbix 8.0.0 (5 de noviembre de 2026); mínimos de base de datos y PHP, la cita de Elasticsearch, las macros retiradas, el comodín de la lista de la API, la verificación TLS, el webhook de Teams, los modos del complemento de Ceph y los paquetes con APM — What's new and upgrade notes: 8.0; rangos soportados y la frase sobre los repositorios del fabricante de la base de datos — Requirements; AllowUnsupportedDBVersions y su valor por defecto — zabbix_server; fechas de ciclo de vida de 8.0, 7.4 y 7.0 — Zabbix Life Cycle and Release Policy; fin de vida de PostgreSQL 14 (12-11-2026, última 14.24), 15 (11-11-2027), 16 y 17 — PostgreSQL Versioning Policy; versiones de los archivos de distribución — packages.debian.org y packages.ubuntu.com; soporte estándar de Ubuntu 22.04 hasta mayo de 2027 y de Ubuntu 20.04 hasta mayo de 2025 — Ubuntu release cycle; estado oldstable de Debian 12 — debian.org/releases; fin del soporte de LTS de Debian 11 el 31-08-2026 — wiki.debian.org/LTS. La tabla de distribuciones y el recuento de paquetes por distribución son medición nuestra sobre los índices públicos de repo.zabbix.com, hecha el 07-11-2026 y reproducible descargando los ficheros Packages. Fotografía: sala de ordenadores del CERN, de Hugovanmeijeren, CC BY-SA 3.0 vía Wikimedia Commons, recortada por nosotros.

¿Tu Zabbix está en un Ubuntu 22.04 y nadie sabe de qué repositorio salió la base de datos?

Hacemos el inventario de versiones, decimos si tu salto es una tarde o un proyecto, y lo ejecutamos con ventana y vuelta atrás escritas. Con tus números.

Hablar con everyWAN

Etiquetas:

Compartir:

Suscríbete a nuestra newsletter

Para recibir historias del mundo IT, novedades de everyWAN y ofertas exclusivas para suscriptores, date de alta a nuestra lista de correo

everyWAN
everyWAN