Ahora se agrega una verificación de actualización de software de forma predeterminada a las instalaciones nuevas y existentes: la interfaz de Zabbix se comunicará con el punto final público de Zabbix para buscar actualizaciones.

Las noticias sobre las actualizaciones de software Zabbix disponibles se muestran en Informes -> Información del sistema y (opcionalmente) en el [widget](/manual /web_interface/frontend_sections/dashboards/widgets/system) de tablero Información del sistema.

Puede deshabilitar la verificación de actualización de software configurando AllowSoftwareUpdateCheck=0 en la configuración del servidor.

Sondeadores asincrónicos

Se han agregado nuevos procesos de sondeo capaces de ejecutar múltiples comprobaciones al mismo tiempo:

agent poller
http agent poller
snmp poller (para las métricas walk[OID] y get[OID])

Estos sondeadores son asíncronos: son capaces de iniciar nuevas comprobaciones sin necesidad de esperar una respuesta, con una simultaneidad configurable de hasta 1000 comprobaciones simultáneas.

Se han desarrollado sondeadores asíncronos porque, en comparación, los procesos de sondeo síncronos pueden ejecutar solo una coprobación al mismo tiempo y la mayor parte de su tiempo se dedica a esperar la respuesta. Por lo tanto, la eficiencia podría aumentarse iniciando nuevas comprobaciones paralelas mientras se espera la respuesta de la red, y los nuevos sondeadores lo hacen.

Puede iniciar sondeadores de agentes asíncronos modificando el valor de StartAgentPollers, un nuevo parámetro de servidor/proxy. Los sondeadores de agentes HTTP se pueden iniciar modificando StartHTTPAgentPollers. Los sondeadores SNMP se pueden iniciar modificando StartSNMPPollers.

La simultaneidad máxima para sondeadores asíncronos (agente, agente HTTP y SNMP) está definida por MaxConcurrentChecksPerPoller.

Tenga en cuenta que después de la actualización, todas las comprobaciones de agente, agente HTTP y walk[OID] de SNMP se trasladarán a sondeadores asíncronos.

Como parte del desarrollo, se agregó la función cURL de conexiones persistentes a las comprobaciones del agente HTTP.

Monitoreo del navegador

Se ha agregado a Zabbix un nuevo tipo de métrica: Métrica de navegador, lo que permite monitorear sitios web y aplicaciones web complejos mediante un navegador. Las métricas de navegador permiten la ejecución de código JavaScript definido por el usuario para simular acciones relacionadas con el navegador, como hacer clic, ingresar texto, navegar por páginas web, etc.

Esta métrica recopila datos a través de HTTP/HTTPS e implementa parcialmente el estándar WebDriver del W3C con Selenium Server o un WebDriver simple (por ejemplo, ChromeDriver) como punto final de prueba.

Tenga en cuenta que la compatibilidad con métricas de navegador es actualmente experimental.

Además, esta característica agrega la plantilla Sitio web por navegador y nuevos elementos para exportar/importar la configuración, archivos de configuración de servidor/proxy Zabbix, tiempos de espera y la utilidad de línea de comandos zabbix_js. Para obtener más información, consulte Notas de actualización a 7.0.0.

Equilibrio de carga y alta disponibilidad de los proxy

El equilibrio de carga de los proxy se implementa mediante la introducción de grupos de proxy en Zabbix. Los grupos de proxy proporcionan la distribución automática de los host entre los proxy, el reequilibrio de carga de los proxy y alta disponibilidad: cuando un proxy deja de estar disponible, sus host se distribuyen inmediatamente entre los demás proxy del grupo.

Para obtener más información, consulte equilibrio de carga y alta disponibilidad de los proxy.

Búfer de memoria del proxy

Se ha desarrollado un búfer de memoria para el proxy de Zabbix. El búfer de memoria permite almacenar datos nuevos (valores de item, descubrimiento de red, registro automático de hosts) en el búfer y cargarlos en el server de Zabbix sin acceder a la base de datos.

En las instalaciones anteriores a Zabbix 7.0, los datos recopilados se almacenaban en la base de datos antes de cargarlos en el server de Zabbix. En estas instalaciones, este comportamiento sigue siendo el predeterminado después de la actualización.

Para obtener un rendimiento óptimo, se recomienda configurar el uso del búfer de memoria en el proxy. Esto es posible modificando el valor de ProxyBufferMode de "disk" (valor predeterminado codificado para las instalaciones existentes) a "hybrid" (recomendado) o "memory". También es necesario establecer el tamaño del búfer de memoria (parámetro ProxyMemoryBufferSize).

En el modo híbrido, el búfer está protegido contra la pérdida de datos, ya que los datos no enviados se vacían en la base de datos si el proxy se detiene, el búfer está lleno o los datos son demasiado antiguos. Cuando todos los valores se han vaciado en la base de datos, el proxy vuelve a utilizar el búfer de memoria.

En el modo de memoria, se utiliza el búfer de memoria; sin embargo, no existe protección contra la pérdida de datos. Si el proxy se detiene o la memoria se llena, los datos no enviados se descartan.

El modo híbrido (ProxyBufferMode=hybrid) se aplica a todas las instalaciones nuevas desde Zabbix 7.0.

Los parámetros adicionales, como ProxyMemoryBufferSize y ProxyMemoryBufferAge, definen respectivamente el tamaño del búfer de memoria y la antigüedad máxima de los datos en el búfer.

Se han añadido nuevos items internos para supervisar el búfer de memoria del proxy.

Aprovisionamiento de usuarios JIT

Anteriormente, los usuarios aprovisionados estaban limitados únicamente a los medios creados durante el aprovisionamiento, sin flexibilidad para editar propiedades como el horario de trabajo o las severidades.

Ahora, los usuarios aprovisionados en Zabbix disponen de mayor flexibilidad:

los medios del usuario aprovisionados se pueden deshabilitar/habilitar;
los campos de los medios del usuario aprovisionados, como Cuándo está activo, Usar si la severidad y Habilitado, se pueden editar manualmente;
se pueden añadir manualmente medios de usuario adicionales (por ejemplo, direcciones de correo electrónico adicionales) para los usuarios aprovisionados;
los medios de usuario añadidos manualmente se pueden eliminar (los medios de usuario aprovisionados no se pueden eliminar).

Además, al configurar la asignación de medios de usuario para el aprovisionamiento, ahora están disponibles campos como Cuándo está activo, Usar si la severidad y Habilitado. Tenga en cuenta que los cambios en el formulario de asignación del tipo de medio del usuario solo tendrán efecto en los nuevos medios creados durante el aprovisionamiento.

Tiempos de espera configurables por métrica

La configuración de tiempo de espera por métrica ahora está disponible para más tipos de métricas (consulte tipos de métricas compatibles). Además de configurar los valores de tiempo de espera a nivel de métrica, es posible definir tiempos de espera globales y proxy para varios tipos de métricas.

Los tiempos de espera configurados a nivel de métrica tienen la máxima prioridad. De forma predeterminada, los tiempos de espera globales se aplican a todas las métricas; sin embargo, si se establecen tiempos de espera de proxy, anularán los globales.

Base de datos Oracle considerada obsoleta

El soporte de Oracle como base de datos del servidor está considerado obsoleto y se espera que sea completamente eliminado en versiones futuras.

Protocolo JSON para comprobaciones pasivas del agent

Se ha implementado un protocolo basado en JSON para las comprobaciones pasivas del agent.

Para garantizar la compatibilidad con versiones anteriores del agent, se ha añadido un mecanismo de conmutación por error al protocolo de texto sin formato anterior. Si el agent devuelve "ZBX_NOTSUPPORTED", Zabbix almacenará en caché la interfaz como perteneciente al protocolo anterior y volverá a intentar la comprobación enviando únicamente la clave del item en texto sin formato.

Ahora Zabbix get puede ejecutarse con una nueva opción -P --protocol <value>, donde "value" puede ser:

auto: conectarse mediante el protocolo JSON, cambiar al protocolo de texto sin formato y volver a intentarlo (predeterminado);
json: conectarse mediante la clave del protocolo JSON;
plaintext: conectarse mediante el protocolo de texto sin formato, enviando únicamente la clave del item.

Si no se admite una clave de item, Zabbix get devolverá el código de salida 1.

Protocolos unificados de agent/agent2

Los protocolos de Zabbix agent y agent 2 se han unificado al cambiar Zabbix agent al protocolo de Zabbix agent 2. La diferencia entre las solicitudes/respuestas de Zabbix agent y Zabbix agent 2 se expresa mediante el valor de la etiqueta "variant" ("1": Zabbix agent, "2": Zabbix agent 2).

Consulte también: Comprobaciones pasivas y activas de agent.

Soporte de intervalos de programación/flexibles en controles activos

Ahora se admiten intervalos flexibles/de programación en las comprobaciones activas tanto del agente Zabbix como del agente 2 Zabbix (anteriormente solo el agente Zabbix 2).

Deshabilitación automática de recursos perdidos

Ahora los recursos que ya no son descubiertos por el descubrimiento de bajo nivel pueden deshabilitarse automáticamente. Pueden deshabilitarse inmediatamente, después de un período de tiempo especificado o nunca (consulte el nuevo parámetro Disable lost resources en la configuración de la regla de descubrimiento).

Los recursos perdidos (hosts, items, triggers) se indican mediante un icono en la columna de información. El texto de la información sobre herramientas proporciona detalles sobre su estado.

En el marco del mismo desarrollo, el parámetro Keep lost resources period cambió de nombre a Delete lost resources, con opciones para eliminar los recursos inmediatamente, después de un período de tiempo especificado o nunca.

Envío de datos al Zabbix server mediante la API de Zabbix

Anteriormente, el envío de datos específicos al Zabbix server era posible mediante la utilidad Zabbix sender o implementando un protocolo de comunicación personalizado basado en JSON, similar al utilizado en Zabbix sender.

Ahora también es posible enviar datos al Zabbix server mediante el protocolo HTTP utilizando el método de API history.push. Tenga en cuenta que, para recibir los datos enviados, se requiere un item trapper configurado o un item de HTTP agent (con la captura habilitada).

Además, las operaciones history.push correctas se registran en Reports → Audit log, que cuenta con opciones de filtrado adicionales (una nueva acción Push y el recurso History). El método de API history.push también está disponible en la Allow/Deny list de métodos de API al configurar un rol de usuario.

Scripts

Ejecución de scripts en agentes activos

Ahora es posible ejecutar scripts en agentes que operan en modo activo. Una vez que la ejecución del script se activa mediante una operación de una acción o mediante la ejecución manual de un script, el comando se incluye en la configuración de las comprobaciones activas y se ejecuta cuando el agente activo lo recibe.

Los scripts manuales se envían al agente activo junto con el tiempo de espera de ejecución de scripts del server/proxy. Aumente el tiempo de espera predeterminado del server/proxy para la ejecución de scripts. El tiempo de espera debe ser superior a la frecuencia de actualización de las comprobaciones activas; de lo contrario, se agotará antes de que el agente activo reciba el script y pueda devolver el resultado.

Tenga en cuenta que los agentes activos antiguos ignoran los comandos remotos incluidos en la configuración de las comprobaciones activas. Para obtener más información, consulte Comprobaciones pasivas y activas del agente.

Entrada manual del usuario para scripts

La entrada manual del usuario para los scripts del frontend permite proporcionar un parámetro personalizado en cada ejecución del script. Esto evita la necesidad de crear varios scripts de usuario similares con una única diferencia en los parámetros.

Por ejemplo, puede que desee proporcionar un número entero diferente o una dirección URL diferente al script durante su ejecución.

Para habilitar la entrada manual del usuario:

use la macro {MANUALINPUT} en el script (comandos, script, parámetro del script) donde sea necesario; o en el campo URL de los scripts URL;
en la configuración avanzada del script, habilite la entrada manual del usuario y configure las opciones de entrada:

Con la entrada del usuario habilitada, antes de ejecutar el script, aparecerá al usuario una ventana emergente de Entrada manual en la que se le solicitará proporcionar un valor personalizado. El valor proporcionado reemplazará a {MANUALINPUT} en el script.

Según la configuración, se solicitará al usuario que introduzca un valor de cadena o que seleccione el valor en una lista desplegable con opciones predeterminadas.

Rendimiento

Reacción más rápida a la actualización del período de mantenimiento del host

Anteriormente, los mantenimientos se recalculaban solo una vez por minuto, lo que podía provocar una latencia de hasta 60 segundos al iniciar o detener un período de mantenimiento.

Ahora, los mantenimientos siguen recalculándose cada minuto o tan pronto como se recarga la caché de configuración si hay cambios en el período de mantenimiento.

Cada segundo, el proceso del temporizador comprueba si se debe iniciar o detener algún mantenimiento en función de si hay cambios en los períodos de mantenimiento después de la actualización de la configuración. Por lo tanto, la velocidad de inicio o detención de los períodos de mantenimiento depende del intervalo de actualización de la configuración (10 segundos de forma predeterminada). Tenga en cuenta que los cambios en el período de mantenimiento no incluyen la configuración de Activo desde/Activo hasta. Además, si se añade un host o un grupo de hosts a un período de mantenimiento activo existente, los cambios solo serán activados por el proceso del temporizador al inicio del minuto siguiente.

Comprobaciones de permisos más rápidas

Las comprobaciones de permisos ahora son mucho más rápidas gracias a la introducción de varias tablas intermedias para comprobar los permisos de los usuarios sin privilegios.

Estas tablas almacenan hashes (SHA-256) de los conjuntos de grupos de usuarios y de los conjuntos de grupos de hosts correspondientes a cada usuario y host, respectivamente. Además, hay una tabla de permisos que almacena únicamente las combinaciones accesibles de usuarios y hosts, especificadas mediante los ID de hash.

Esta mejora acelera considerablemente la carga de las páginas del frontend con un uso intensivo de permisos (es decir, hosts y problemas). Tenga en cuenta que los hashes y los permisos no se calculan para los usuarios Super-admin.

Ejecución más rápida de acciones de disparador

La ejecución de acciones de disparador, operaciones de recuperación y operaciones de actualización en el servidor Zabbix ahora ocurre inmediatamente (menos de 100 milisegundos) después de un cambio en el estado del disparador, mientras que anteriormente los usuarios podían experimentar hasta 4 segundos de latencia.

La reducción de la latencia es posible gracias a la implementación de mecanismos de comunicación entre procesos (IPC) entre múltiples procesos (escalador y su módulo de despacho de escalamiento, escalador y alertador, gestor de preprocesamiento y sincronizador de historial).

Widgets

Se han añadido varios widgets nuevos en la nueva versión, mientras que se ha ampliado la funcionalidad disponible en otros.

Además, ahora los widgets del dashboard pueden conectarse y comunicarse entre sí, lo que hace que los widgets y los dashboards sean más dinámicos.

Gauge

Se agregó un widget Gauge a widgets del tablero, que permite mostrar el valor de una sola métrica como gauge. Para obtener más información, consulte Gauge.

Gráfico circular

Se ha agregado un widget de gráfico circular a los widgets del tablero, que permite mostrar valores de métricas seleccionadas como:

**Gráfico circular;
Gráfico de doughnut.


Gráfico circular.	![](.. /../../assets/en/manual/web_interface/frontend_sections/monitoring/doughnut_chart_7_0.png){width="300"} Gráfico de doughnut.

Para obtener más información, consulte Gráfico circular.

Como parte de este desarrollo, se agregó una casilla de verificación Mostrar función de agregación a la configuración del widget gráfico (en la pestaña Leyenda).

Panal

Se ha agregado un widget Panal a los widgets del tablero, que ofrece una descripción general dinámica y vibrante de la infraestructura y los recursos de la red monitoreados, donde se ubican los grupos de equipos, como las máquinas virtuales y los dispositivos de red, junto con sus respectivas métricas, se representan visualmente como celdas hexagonales interactivas. Para obtener más información, consulte Panal.

Triggers principales

Se ha añadido un widget de Triggers principales a los widgets del dashboard, que permite ver los triggers con el mayor número de problemas.

Para obtener más información, consulte: Triggers principales.

Historial del item y texto sin formato

El nuevo widget de panel Historial del item ha reemplazado al widget Texto sin formato y ofrece varias mejoras.

A diferencia del widget Texto sin formato, que solo mostraba los datos más recientes del item en texto sin formato, el widget Historial del item admite varias opciones de visualización para distintos tipos de item (numérico, carácter, registro, texto y binario). Por ejemplo, puede mostrar barras de progreso o indicadores, imágenes para tipos de datos binarios (útil para items de navegador) y resaltar valores de texto (útil para la supervisión de archivos de registro).

Para obtener más información, consulte Historial del item. Para obtener información detallada sobre el reemplazo del widget Texto sin formato, consulte Notas de actualización para 7.0.0.

Navegador de equipos y navegador de métricas

Los widgets Navegador de equipos y Navegador de métricas se han agregado a widgets del tablero. Estos widgets muestran equipos o métricas, respectivamente, según varias opciones de filtrado y agrupación, y permiten controlar la información que se muestra en otros widgets según el equipo o métrica seleccionada. Para obtener más información, consulte Navegador de equipos y Navegador de métricas.

Marco de comunicación para widgets

Ahora los widgets del dashboard pueden conectarse y comunicarse entre sí, lo que hace que los widgets y los dashboards sean más dinámicos. Varios widgets tienen parámetros que les permiten compartir datos de configuración entre widgets compatibles o con el dashboard.

Esta funcionalidad introduce los siguientes cambios:

Los parámetros Host groups, Hosts e Item permiten seleccionar las entidades correspondientes o una fuente de datos que las proporcione.
El parámetro Enable host selection ha sido reemplazado por el parámetro Override host, que permite seleccionar una fuente de datos que proporcione hosts.
Se ha añadido el parámetro Time period a varios widgets, lo que permite seleccionar una fuente de datos que proporcione un período de tiempo.
El parámetro Map del widget Map permite seleccionar un mapa u otro widget como fuente de datos para los mapas.
El parámetro Graph del widget Graph (classic) permite seleccionar un gráfico u otro widget como fuente de datos para los gráficos.

Según el widget y sus parámetros, la fuente de datos puede ser un widget compatible del mismo dashboard o el propio dashboard. Para obtener más información, consulte Dashboard widgets.

Para consultar los cambios en los templates incluidos con Zabbix, consulte Template changes.

Períodos de tiempo para la agregación en los widgets «Valor del item» y «Hosts principales»

Ahora se pueden configurar períodos de tiempo en los widgets Valor del item y Hosts principales.

También es posible mostrar un valor agregado en el widget de valor del item para el período seleccionado. El valor agregado se puede mostrar como:

mínimo
máximo
promedio
cantidad
suma
primero
último

Estas funciones adicionales son útiles para crear widgets de comparación de datos. Por ejemplo, en un widget puede mostrar el valor más reciente y, en otro, el valor promedio de un período más largo. También puede utilizar varios widgets para comparar lado a lado valores agregados de distintos períodos del pasado.

Disponibilidad ampliada de widgets en plantillas de tablero

Anteriormente, en una plantilla de tablero, solo podía crear los siguientes widgets: Reloj, Gráfico (clásico), Prototipo de gráfico, Valor de métrica, Texto sin formato, URL.

Ahora las plantillas de tablero admiten la creación de todos los widgets.

Ahora, además de ordenar por Valor del item, también es posible establecer las columnas Nombre del host o Texto como columna de ordenación en el widget Top hosts.

El widget Disponibilidad de host ahora permite mostrar los hosts con la interfaz Zabbix agent (active checks). Se ha añadido un estado de disponibilidad más: Mixto, que corresponde a la situación en la que al menos una interfaz no está disponible y al menos una está disponible o en estado desconocido. Además, se ha introducido la posibilidad de ver únicamente el total de hosts, sin desglosarlo por interfaces.

El widget Gráfico ahora admite la configuración de un número variable de filas legend determinadas por el número de métricas configuradas.

Funciones

Nuevas funciones

Se han agregado nuevas funciones para usar en expresiones de iniciador y métricas calculadas:

jsonpath() - devuelve el resultado de JSONPath;
xmlxpath() - devuelve el resultado XML XPath.

Ver también: Funciones de cadena

Funciones actualizadas

Se han actualizado varias funciones:

Las funciones de agregación ahora también admiten tipos no numéricos para los cálculos. Esto puede resultar útil, por ejemplo, con las funciones count y count_foreach.
Las funciones de agregación count y count_foreach admiten los parámetros opcionales operator y pattern, que pueden utilizarse para ajustar el filtrado de items y contar únicamente los valores que coincidan con los criterios especificados.
Todas las funciones foreach ya no incluyen items no compatibles en el recuento.
La función last_foreach, que anteriormente estaba configurada para ignorar el argumento del período de tiempo, ahora lo acepta como parámetro opcional.
El rango admitido para los valores devueltos por las funciones de predicción se ha ampliado para coincidir con el rango del tipo de datos double. Ahora la función timeleft() puede aceptar valores de hasta 1.7976931348623158E+308 y la función forecast() puede aceptar valores comprendidos entre -1.7976931348623158E+308 y 1.7976931348623158E+308.

Métricas

Período de almacenamiento predeterminado coherente del historial

El período predeterminado para conservar el historial de los item se ha establecido de forma coherente en 31 días tanto en el frontend como en la base de datos.
Este cambio afecta a los formularios de configuración de item, item de template y prototipos de item, así como a la anulación del período de almacenamiento del historial en el descubrimiento de bajo nivel.

Valores de coma flotante truncados para items de tipo entero

Ahora, si se recibe un valor de coma flotante para un item de tipo entero sin signo, se eliminará la parte decimal del valor y se guardará como un entero.
Anteriormente, un valor de coma flotante hacía que un item de tipo entero dejara de ser compatible.

Conteo de líneas en el registro de eventos de Windows

Se agregó una nueva métrica eventlog.count al agente/agente 2 de Zabbix en Windows. Esta métrica devuelve un valor entero con el recuento de líneas en el registro de eventos de Windows según los parámetros especificados.

Solicitudes SNMP asincrónicas de OID único

Se agregó una nueva métrica SNMP get[OID] que permite consultar un único valor OID de forma asincrónica.

Items internos

Las comprobaciones internas ahora son gestionadas por un nuevo proceso internal poller de Zabbix server/proxy.

Se han añadido items internos para supervisar el búfer de memoria del proxy:

zabbix[proxy_buffer,buffer,<mode>] - devuelve las estadísticas de uso del búfer de memoria del proxy;
zabbix[proxy_buffer,state,changes] - devuelve el número de cambios de estado entre los modos de búfer en disco/memoria desde el inicio;
zabbix[proxy_buffer,state,current] - devuelve el estado de funcionamiento actual en el que se almacenan los nuevos datos.

También se han añadido los siguientes items internos:

zabbix[discovery_queue] - permite supervisar el número de comprobaciones de descubrimiento en la cola;
zabbix[vps,written] - permite supervisar el número total de valores de historial escritos en la base de datos.

Items de agent nuevos y actualizados

Se han añadido nuevos items al agent de Zabbix/agent 2:

El item net.dns.perf devuelve el número de segundos empleados esperando una respuesta de un servicio, midiendo el tiempo de ejecución del item net.dns.
El item net.dns.get del agent 2 de Zabbix devuelve información detallada sobre los registros DNS.

Se han actualizado los siguientes items del agent de Zabbix/agent 2:

Los items net.dns y net.dns.record ahora aceptan el nombre DNS en formato inverso y no inverso al realizar búsquedas DNS inversas;
Los items proc.get en los modos "process" y "summary" ahora también devuelven la memoria PSS (tamaño proporcional del conjunto) en Linux;
Los items system.sw.packages y system.sw.packages.get ahora son compatibles con Gentoo Linux;
El item system.hostname ahora puede devolver un nombre de dominio completo (FQDN), si se especifica la nueva opción fqdn en el parámetro type;
Los items wmi.get y wmi.getall utilizados con el agent 2 de Zabbix ahora devuelven JSON con los valores booleanos representados como cadenas (por ejemplo, "RealTimeProtectionEnabled": "True" en lugar de "RealTimeProtectionEnabled": true, que se devolvía anteriormente), para coincidir con el formato de salida de estos items en el agent de Zabbix;
El item oracle.ts.discovery del agent 2 de Zabbix ahora devuelve una nueva macro LLD {#CON_NAME} con el nombre del contenedor;
El item oracle.ts.stats del agent 2 de Zabbix tiene un nuevo parámetro conname para especificar el nombre del contenedor de destino.

Se ha actualizado el formato JSON de los datos devueltos. Cuando no se especifica tablespace, type ni conname en los parámetros de la clave, los datos devueltos incluirán un nivel JSON adicional con el nombre del contenedor, lo que permitirá diferenciar entre contenedores.

Comprobaciones simples

El item vmware.eventlog ahora admite el filtrado opcional por gravedad en el tercer parámetro.

El item vmware.vm.discovery ahora también devuelve datos sobre las interfaces de red de las máquinas virtuales. Estos datos se pueden utilizar para configurar interfaces de host personalizadas.

El item vmware.vm.net.if.discovery ahora también devuelve una matriz de direcciones de interfaces de red.

Se ha añadido un nuevo parámetro options a los siguientes items:

Este parámetro se puede utilizar para especificar si las respuestas redirigidas deben tratarse como si el host de destino estuviera disponible o no. Consulte comprobaciones simples para obtener más información.

Registro de Engine IDs SNMPv3 duplicados

Los Engine IDs en SNMPv3 se utilizan como identificadores únicos del dispositivo. A veces, los Engine IDs son iguales en varios dispositivos debido a una configuración incorrecta o a los ajustes de fábrica. Dado que los estándares SNMP requieren que los Engine IDs sean únicos, los items que comparten el mismo Engine ID dejan de ser compatibles en Zabbix, lo que provoca problemas de disponibilidad con estos dispositivos.

Para ayudar a solucionar estos problemas, Zabbix server registrará periódicamente información sobre los dispositivos SNMPv3 que comparten el mismo Engine ID. Tenga en cuenta que la detección de Engine IDs duplicados funciona por separado en cada sondeador SNMP.

Enlace de documentación para cada métrica estándar

Cada métrica estándar ahora tiene un enlace directo desde la interfaz a su página de documentación.

Los enlaces se colocan debajo del ícono del signo de interrogación, al abrir la ventana auxiliar de al métrica desde el formulario de configuración de la métrica (haga clic en Seleccionar al lado del campo clave de la métrica).

Preprocesamiento

Gestión avanzada de la causa raíz para el estado de item no compatible

La gestión de errores en caso de que no se pueda recuperar el valor de un item (y, por lo tanto, este pase a estar en estado no compatible) no permitía anteriormente distinguir el motivo ni la etapa de ejecución en la que fallaba el proceso.
Todos los errores debían gestionarse mediante una misma opción de gestión de errores: descartar el valor, establecer un valor especificado o establecer un mensaje de error especificado.

Ahora es posible hacer coincidir el mensaje de error con una expresión regular.
Si el error coincide (o no coincide), es posible especificar cómo debe procesarse el caso de error.
Por ejemplo, un mensaje de error específico puede "asignarse" a un caso más general para que coincida con él y sea gestionado por un paso de preprocesamiento posterior, o un problema intermitente (por ejemplo, de conectividad de red) puede gestionarse de forma diferente a un fallo definitivo al obtener el valor del item.

Ahora se pueden añadir varios pasos de preprocesamiento Comprobar si el valor no es compatible.
Tenga en cuenta que solo puede haber un paso de coincidencia "cualquier error" al final de la canalización que comprueba si el item está en estado no compatible.
Si está presente, se activa cuando ninguna de las comprobaciones específicas coincide (o no coincide) con el patrón correspondiente, o cuando se ha transferido un mensaje de error (modificado); es decir, cuando no se ha aplicado ninguna anulación de "Descartar valor" o "Establecer valor en".

Véase también: Comprobar si el valor no es compatible

Mayor facilidad de uso para la actualización masiva de pasos de preprocesamiento

El diseño anterior del formulario de actualización masiva de item no dejaba suficientemente claro si la actualización de los pasos de preprocesamiento añadiría o reemplazaría los pasos existentes. En el nuevo diseño se han añadido los botones de opción Reemplazar y Eliminar todo, lo que permite a los usuarios saber claramente cuál será el resultado de la actualización masiva de los pasos de preprocesamiento:

Macros

Macros de usuario compatibles con los nombres de los item y de los prototipos de item

Ahora los macros de usuario son compatibles con los nombres de los item y de los prototipos de item.

Tenga en cuenta que la compatibilidad con macros de usuario se eliminó de los nombres de los item y de los prototipos de item en Zabbix 6.0.
Ahora se ha restaurado.
También se admite buscar por el nombre del item con los macros resueltos, algo que anteriormente no era compatible.

El nombre del item con los macros resueltos se almacena en una tabla independiente de la base de datos (item_rtname), que es una extensión de la tabla items.
Para cada registro de la tabla items, se crea un registro correspondiente en item_rtname (excepto para los prototipos de item, los item de las reglas de descubrimiento y los item de los template).
El nombre con los macros resueltos está limitado a 2048 caracteres.

El nombre del item con los macros resueltos se muestra en todas las ubicaciones del frontend, excepto en la sección Recopilación de datos.

Se ha añadido un nuevo proceso del server, configuration syncer worker, responsable de resolver y sincronizar los valores de los macros de usuario en los nombres de los item.

Compatibilidad ampliada con las funciones de macro

Las funciones de macro ahora son compatibles con todos los tipos de macros:

Las funciones de macro se pueden utilizar en todas las ubicaciones compatibles con las macros indicadas. Esto se aplica a menos que se indique explícitamente que solo se espera una macro (por ejemplo, al configurar macros de host o filtros de reglas de descubrimiento de bajo nivel).

Informes programados

La funcionalidad informes programados ya no es experimental.

Informes de varias páginas

Para los dashboards de varias páginas, ahora los informes se devuelven con todas las páginas del dashboard, y cada página del PDF corresponde a una página del dashboard. Anteriormente, esta funcionalidad se limitaba a devolver únicamente la primera página del dashboard.

Notificaciones

Soporte de procesamiento de etiquetas para eventos internos

El procesamiento de etiquetas devueltas por el script del webhook ahora también es compatible con eventos internos.

Además, las macros {EVENT.TAGS.<nombre de etiqueta>}, {EVENT.TAGS}, {EVENT.TAGSJSON}, {EVENT.RECOVERY.TAGS}, {EVENT.RECOVERY.TAGSJSON} ahora son compatibles con notificaciones de eventos internos.

Estos cambios permiten utilizar webhooks para actualizar o cerrar un problema externo/ticket de soporte mediante una notificación de recuperación de evento interno.

Bases de datos

Auditlog convertido a hypertable en TimescaleDB

La tabla auditlog se ha convertido en una hypertable en TimescaleDB en las nuevas instalaciones para beneficiarse de la partición automática por tiempo (7 días por defecto) y de un mejor rendimiento.

Para actualizar correctamente las instalaciones existentes, consulte Actualización del esquema de TimescaleDB.

Véase también: Versiones de TimescaleDB compatibles

Tabla de base de datos independiente para los proxy

Los registros de los proxy se han trasladado fuera de la tabla hosts y ahora se almacenan en la nueva tabla proxy.

Además, los datos operativos de los proxy (como el último acceso, la versión y la compatibilidad) se han trasladado fuera de la tabla host_rtdata y ahora se almacenan en la nueva tabla proxy_rtdata.

Procesos

Multihilo

Se han realizado varios cambios como parte de la transición a una arquitectura multihilo:

Se ha añadido un nuevo parámetro de configuración: --with-stacksize. Este parámetro permite sobrescribir el tamaño de pila predeterminado de los hilos utilizado por el sistema (en kilobytes).
La resolución de macros de usuario se ha trasladado del gestor de preprocesamiento a los workers de preprocesamiento.

Refuerzo de la seguridad del entorno del server

Ahora es posible restringir algunas funciones de Zabbix para reforzar la seguridad del entorno del server:

La ejecución de scripts globales en el server de Zabbix se puede deshabilitar estableciendo EnableGlobalScripts=0 en la configuración del server.
Para las instalaciones nuevas, la ejecución de scripts globales en el server de Zabbix está deshabilitada de forma predeterminada.
La autenticación HTTP de los usuarios se puede deshabilitar estableciendo $ALLOW_HTTP_AUTH=false en el archivo de configuración del frontend (zabbix.conf.php).
El módem GSM para las notificaciones SMS ahora se puede especificar en el nuevo parámetro SMSDevices, lo que limita la posibilidad de configurar incorrectamente la ruta del módem GSM desde el frontend.

Validación del archivo de configuración

Se ha añadido la posibilidad de validar el archivo de configuración a los comandos de mantenimiento de server, proxy, agent, agent 2 y web service de Zabbix.
La validación se puede realizar mediante la opción -T --test-config.
En caso de que la validación sea correcta, el código de salida será "0"; de lo contrario, el componente finalizará con un código de salida distinto de cero y mostrará el mensaje de error correspondiente.
Las advertencias (por ejemplo, en caso de un parámetro obsoleto) no afectarán al código de salida correcto.

Detección de las funcionalidades de la biblioteca cURL en tiempo de ejecución

Anteriormente, las funcionalidades de la biblioteca cURL se detectaban durante la compilación del server, proxy o agent de Zabbix. Si se actualizaban las funcionalidades de cURL, era necesario volver a compilar el componente de Zabbix correspondiente para poder utilizarlas.

Ahora solo es necesario reiniciar para que las funcionalidades actualizadas de la biblioteca cURL estén disponibles en Zabbix. Ya no es necesario volver a compilar. Esto se aplica al server, proxy y agent de Zabbix.

Consulte también las notas de actualización.

Configuración del agente 2

Tamaño del búfer

El valor predeterminado del parámetro de configuración BufferSize para el agente Zabbix 2 se ha aumentado de 100 a 1000.

Se permiten valores vacíos

Ahora se permiten valores vacíos en los parámetros de configuración relacionados con el complemento en el agente Zabbix 2.

Configuración del tipo de inicio del servicio del agente de Windows

Se ha añadido la opción para establecer el tipo de inicio del servicio de Windows de Zabbix agente/agente 2 (-S --startup-type). Esta opción permite configurar el servicio del agente/agente 2 para que se inicie automáticamente al arrancar Windows (automatic), después de que los servicios iniciados automáticamente hayan completado su inicio (delayed), cuando sea iniciado manualmente por un usuario o aplicación (manual) o para deshabilitar el servicio por completo (disabled).

Al realizar la instalación del agente de Windows desde MSI, el tipo de inicio predeterminado en Windows Server 2008/Vista y versiones posteriores ahora es delayed si no se especifica lo contrario en el parámetro de línea de comandos STARTUPTYPE parámetro de línea de comandos. Esto mejora la fiabilidad y el rendimiento del servicio de agente/agente 2 de Zabbix en Windows, especialmente durante los reinicios del sistema.

Se eliminó la compatibilidad con el antiguo tipo numérico

El antiguo estilo de valores de punto flotante, anteriormente obsoleto, ya no se admite, ya que se utilizan valores numéricos de rango extendido.

Parámetro de prefijo de Vault agregado a los archivos de configuración

Los archivos de configuración zabbix_server.conf y zabbix_proxy.conf se han complementado con un nuevo parámetro opcional Vault Prefix; zabbix.conf.php se ha complementado con el $DB['VAULT_PREFIX'] opcional, y setup.php se ha actualizado en consecuencia.

Por lo tanto, las rutas de Vault para CyberArk y HashiCorp ya no están codificadas para permitir implementaciones de Vault con rutas no estándar.

Descubrimiento

Concurrencia en el descubrimiento de red

Anteriormente, cada regla de descubrimiento de red era procesada por un proceso discoverer. Por lo tanto, todas las comprobaciones de servicios dentro de la regla solo podían realizarse secuencialmente.

En la nueva versión, el proceso de descubrimiento de red se ha rediseñado para permitir la concurrencia entre las comprobaciones de servicios. Se ha añadido un nuevo proceso de gestión del descubrimiento, junto con un número configurable de workers de descubrimiento (o hilos).

El gestor de descubrimiento procesa las reglas de descubrimiento y crea un trabajo de descubrimiento para cada regla, con sus tareas (comprobaciones de servicios). Los workers de descubrimiento toman y realizan las comprobaciones de servicios. Solo las comprobaciones que tienen la misma IP y el mismo puerto se programan secuencialmente, ya que algunos dispositivos pueden no permitir conexiones simultáneas en el mismo puerto.

Un nuevo item interno zabbix[discovery_queue] permite supervisar el número de comprobaciones de descubrimiento en la cola.

El parámetro StartDiscoverers ahora determina el número total de workers de descubrimiento disponibles. El número predeterminado de StartDiscoverers ha aumentado de 1 a 5, y el rango ha cambiado de 0-250 a 0-1000. Los procesos discoverer de versiones anteriores de Zabbix se han eliminado.

Además:

Ahora todas las comprobaciones de servicios se realizan de forma asíncrona, excepto las comprobaciones LDAP;
Ahora se puede configurar en el frontend el número de comprobaciones asíncronas simultáneas para cada tipo de comprobación de servicio (o el número de workers disponibles para todas las comprobaciones de servicios síncronas) (consulte Maximum concurrent checks per type). Este parámetro es opcional.
Anteriormente, la comprobación del servicio HTTP era igual que la comprobación TCP. Ahora las comprobaciones HTTP/HTTPS se realizan mediante libcurl. Si el server/proxy de Zabbix se compila sin libcurl, las comprobaciones HTTP funcionarán como antes (es decir, como comprobaciones TCP), pero las comprobaciones HTTPS no funcionarán.
Los errores en el proceso de descubrimiento de red ahora se mostrarán en el frontend (en Recopilación de datos > Descubrimiento), por ejemplo:
- errores de fping;
- OID de SNMP incorrecto;
- macro incorrecta para el tiempo de espera del item;
- errores en el rango de direcciones.

Agregar etiquetas de equipo durante el descubrimiento/registro automático

Ahora hay operaciones adicionales disponibles para eventos de descubrimiento y registro automático:

Agregar etiquetas de equipo
Eliminar etiquetas de equipo

Compartir grupos de equipos descubiertos

Las reglas de descubrimiento de bajo nivel ahora pueden vincular grupos de equipos existentes y ya descubiertos con equipos creados mediante las mismas reglas de descubrimiento de bajo nivel. Esto afecta a los grupos de equipos previamente descubiertos y creados por otras reglas de descubrimiento de bajo nivel basadas en los prototipos de grupo especificados.

Conectores

La funcionalidad transmisión de datos ya no es experimental.

Transmita datos selectivos y configure intervalos de intento

Al transmitir valores de métricas desde Zabbix a sistemas externos, ahora puede configurar qué valores de métricas debe transmitir el conector en función de su tipo de información (numérica (sin firmar), numérica (flotante), carácter, etc.).

Además, para evitar intentos fallidos de transmitir valores de métricas o eventos (por ejemplo, si el punto final HTTP está ocupado o tiene una velocidad limitada), ahora también puede configurar el intervalo de intento: cuánto tiempo debe esperar el conector después de un intento fallido de transmitir. datos.

Los conectores ahora también aceptan como correctos los códigos de respuesta HTTP 201, 202, 203 y 204 (anteriormente solo 200).

Transmitir datos a Apache Kafka

Una nueva herramienta para transmitir datos a sistemas externos: el conector Kafka para el servidor Zabbix - ya está disponible. El conector Kafka es un servidor liviano escrito en Go, diseñado para reenviar valores de métricas y eventos desde un servidor Zabbix a un broker Kafka.

Templates

Para consultar las nuevas templates y los cambios en las templates existentes, consulte Template changes.

Interfaz

Autenticación multifactor

Autenticación multifactor (MFA) con contraseña de un solo uso basada en tiempo (TOTP) o el método de autenticación Duo Universal Prompt ahora se puede utilizar para iniciar sesión en Zabbix. proporcionando una capa adicional de seguridad más allá de solo un nombre de usuario y contraseña.

Formato de hora de EE. UU.

Las visualizaciones de hora y fecha en la interfaz ahora se ajustan a la visualización de fecha y hora estándar de EE. UU. cuando se utiliza el idioma de interfaz predeterminado (en_US).

Antes	Ahora

Clonación simplificada

Anteriormente era posible Clonar y Clonar por completo equipos, plantillas y mapas.

Ahora se eliminó la opción Clonar y se cambió el nombre de la opción Clonar por completo a Clonar conservando toda la funcionalidad anterior de Clonar por completo.

Iconos reemplazados por fuentes

Todos los íconos en la interfaz se han cambiado de imágenes de íconos a fuentes.

Formularios modales

Ahora varios formularios del frontend se abren en ventanas modales (emergentes):

Configuración de la regla de descubrimiento de red;
Configuración del script global;
Configuración de la correlación de eventos;
Configuración del módulo;
Configuración del tipo de medio;
Configuración del template;
Configuración del trigger y del prototipo de trigger;
Configuración del item y del prototipo de item.

Configuración avanzada plegable

Las casillas de verificación de Configuración avanzada, responsables de mostrar las opciones de configuración avanzada, se han reemplazado por bloques plegables (consulte, por ejemplo, Configuración del conector, Configuración del servicio, Configuración del widget Reloj, etc.).

Esto mejora la experiencia del usuario, ya que contraer estos bloques y guardar la configuración ya no restablecerá los valores predeterminados de las opciones avanzadas configuradas.

Sección de menú mejorada para los iniciadores principales

La sección del menú para ver los iniciadores principales ahora se llama 100 iniciadores principales. Se ha agregado la posibilidad de filtrar los iniciadores por nombre del problema y etiquetas. Además, ahora se muestra la cantidad de problemas detectados en lugar de la cantidad de cambios de estado para cada iniciador.

Aumento del límite de caracteres para los campos de configuración

Campos de URL

El límite de caracteres para todos los campos de URL ahora es de 2048 caracteres. Esto incluye ahora: Tile URL para la configuración relacionada con los mapas geográficos, Frontend URL para configurar diversos parámetros del frontend, URLs para los mapas de red y los elementos de los mapas de red, URL A-C para los campos del inventario del host, y URL para el widget de URL del dashboard.

Campos de autenticación

El límite de caracteres para los campos de autenticación User/User name y Password ahora es de 255 caracteres. Esto se aplica a la configuración de la autenticación HTTP para los items de HTTP agent, los escenarios web y los conectores, así como a la configuración de la autenticación para las comprobaciones simples, la monitorización ODBC, las comprobaciones SSH, las comprobaciones Telnet y la monitorización JMX.

Truncamiento de los resultados de las pruebas de item y preprocesamiento

Al probar items o probar pasos de preprocesamiento, los valores recuperados de un host y los resultados de las pruebas ahora se truncan a un tamaño máximo de 512 KB al enviarse al frontend. Tenga en cuenta que los datos de más de 512 KB siguen siendo procesados completamente por Zabbix server.

Pestañas de tableros de equipo

Todos los paneles de equipo configurados para el equipo seleccionado ahora se muestran como pestañas debajo del encabezado de la página de tableros de equipo, reemplazando el menú desplegable anterior en la esquina superior derecha. Esto permite una fácil transición entre varios tableros de equipo y mejora la navegación a través de los datos de monitoreo.

Registro de auditoría

En Administración > Registro de auditoría, ahora puede activar o desactivar el registro de auditoría de las actividades de descubrimiento de bajo nivel, descubrimiento de red y registro automático realizadas por el server (usuario del sistema).

El período predeterminado de almacenamiento de los registros de auditoría antes de que housekeeper los elimine ha cambiado de 365 días a 31 días.

Filtro de datos recientes

En Monitoring > Latest data, el subfiltro y los datos ya no se muestran de forma predeterminada si no se ha establecido el filtro.

Si actualiza desde versiones anteriores de Zabbix, consulte también: Notas de actualización para 7.0.0.

Versión PHP mínima requerida

La versión mínima requerida de PHP se ha elevado de 7.4.0 a 8.0.0.

Elementos renombrados

Algunos parámetros de widget de panel con la etiqueta Etiquetas han sido renombrados para mayor claridad: Etiquetas de elemento (para el widget Resumen de datos), Etiquetas de escenario (para el widget Supervisión web); Etiquetas de problema (para los widgets Gráfico, Equipos con problemas, Problemas, Problemas por gravedad y Resumen de disparadores);
El enlace de acción para editar el contenido del mapa, disponible desde la lista de mapas en la sección Supervisión → Mapas, ha sido renombrado de Constructor a Editar;
Los campos para establecer los períodos de almacenamiento de historial y tendencias en los formularios de configuración de elemento y prototipo de elemento han sido renombrados;
En la configuración del widget Equipos principales, los campos Columna de orden y Cantidad de equipos han sido renombrados a Ordenar por y Límite de equipos para describir mejor sus funciones.
En la configuración del widget Gráfico, el campo de leyenda Mostrar mín/máx/prom ha sido renombrado a Mostrar mín/prom/máx, y los campos de conjunto de datos patrón de equipo y patrón de elemento han sido renombrados a patrones de equipo y patrones de elemento.
En la configuración del Perfil de usuario, la pestaña Mensajería ha sido renombrada a Notificaciones en la interfaz, en la que la opción Mensajería en la interfaz también ha sido renombrada a Notificaciones en la interfaz.

Varios

Se han actualizado los iconos del menú principal;
Se han actualizado los mensajes que indican la ausencia de datos o los filtros no establecidos (en widgets o filtros emergentes sin datos que mostrar). Además, se ha eliminado el pie de página «Displaying 0 of 0 found» cuando no hay datos que mostrar o cuando el filtrado (o el uso de la búsqueda global) no produce coincidencias.
Los números de versión del frontend de Zabbix y del server de Zabbix ahora se pueden consultar en la página de información del sistema;
Todas las acciones en las que se utiliza el tipo de medio ahora se muestran en la lista de tipos de medio (columna Used in actions). Anteriormente, las acciones en las que la opción Send only to de la configuración de operaciones de la acción era «All» no se incluían en la columna Used in actions del tipo de medio;
Se ha añadido una nueva opción de filtrado a la sección Últimos datos: ahora permite filtrar los items por su estado (compatible/no compatible);
Se ha añadido una nueva opción de filtrado Acknowledgement status a la sección Problemas: ahora permite filtrar los problemas por su estado (no reconocidos/reconocidos/reconocidos por mí);
Se ha añadido un botón de cierre de ventana estándar a las ventanas emergentes destinadas a configurar y actualizar masivamente los elementos y las formas del mapa;
Se ha perfeccionado la configuración de los permisos de los grupos de usuarios y de las etiquetas para filtrar los problemas visibles. Ahora es posible seleccionar varios grupos de hosts/templates a la vez para asignarles los mismos permisos.
Al posponer las notificaciones globales en un navegador, estas se pospondrán en todos los navegadores/dispositivos en los que el usuario haya iniciado sesión.
El parámetro Override host del widget Valor del item se ha movido antes de la sección Advanced configuration para facilitar su uso.

Complementos

Ember+

Se ha agregado un nuevo complemento para el monitoreo directo de Ember+ por parte del agente 2 de Zabbix.

Para más información, ver:

Instalación

Paquetes de instalación independientes para derivados de RHEL

Hay paquetes de instalación específicos disponibles para las versiones 8 y 9 de AlmaLinux, CentOS Stream, Oracle Linux y Rocky Linux.

Anteriormente, se proporcionaban paquetes de instalación únicos para RHEL y las distribuciones basadas en RHEL.

Ahora se utilizan paquetes independientes para RHEL y para cada uno de los derivados mencionados anteriormente, con el fin de evitar posibles problemas de incompatibilidad binaria.

Soporte para ARM64/AArch64

Los paquetes de instalación ARM64/AArch64 ahora están disponibles para Debian, RHEL 8, 9 y sus derivados, así como SLES/OpenSUSE Leap 15.

¿Qué sigue?

6 Novedades de Zabbix 7.0.1

Docs

5 Novedades de Zabbix 7.0.0

Licencia AGPL-3.0

Comprobación de actualización de software