Consulte los cambios importantes para esta versión.
El software Zabbix, ahora, es escrito y distribuido bajo la licencia AGPL-3.0 (previamente licencia GPL v2.0).
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 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.
El soporte de Oracle como base de datos del servidor está considerado obsoleto y se espera que sea completamente eliminado en versiones futuras.
Anteriormente, era posible enviar datos específicos al servidor Zabbix usando la utilidad Zabbix sender o implementando un protocolo de comunicación personalizado basado en JSON similar al usado por Zabbix sender.
Ahora también es posible enviar datos al servidor Zabbix a través del protocolo HTTP utilizando el método de la API history.push
. Tenga en cuenta que para recibir los datos enviados se requiere una métrica de captura configurada o una métrica de agente HTTP (con captura habilitada).
Además, las operaciones correctas de history.push
se registran en Reports → Registro de auditoría que tiene opciones de filtrado adicionales (una nueva acción Push y un recurso Historial), y el método de la API history.push
también está disponible en la lista Permitir/Denegar de métodos API al configurar un rol de usuario.
Anteriormente, los mantenimientos se recalculaban solo cada minuto, lo que provocaba una posible latencia de hasta 60 segundos para iniciar o detener un período de mantenimiento.
Ahora los mantenimientos todavía se recalculan 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 verifica si se debe iniciar/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/detención de los períodos de mantenimiento depende de la configuración intervalo de actualización (10 segundos de forma predeterminada). Tenga en cuenta que los cambios en el período de mantenimiento no incluyen la configuración Activo desde/Activo hasta. Además, si se agrega un equipo/grupo de equipos a un período de mantenimiento activo existente, los cambios solo se activarán mediante el proceso del temporizador al comienzo del siguiente minuto.
Las comprobaciones de permisos se han hecho mucho más rápidas mediante la introducción de varias tablas intermedias para comprobar los permisos de los usuarios sin privilegios.
Estas tablas mantienen hashes (SHA-256) de conjuntos de grupos de usuarios y conjuntos de grupos de equipos para cada usuario/equipo respectivamente. Además, hay una tabla de permisos que almacena solo las combinaciones accesibles de usuarios y equipos, especificadas por los ID de hash.
Esta mejora hace que la carga de páginas en la interfaz con muchos permisos (es decir, equipos, problemas) sea mucho más rápida. Tenga en cuenta que los hash y los permisos no se calculan para los usuarios superadministradores.
La operación acción del iniciador, la operación de recuperación y la ejecución de la operación de actualización en el servidor Zabbix ahora ocurren inmediatamente (menos de 100 milisegundos) después de un cambio de estado del iniciador, mientras que anteriormente los usuarios podían experimentar hasta 4 segundos de latencia.
La reducción de la latencia es posible mediante la implementación de mecanismos de comunicación entre procesos (IPC) entre múltiples procesos (escalador e iniciador de escalada, escalador y alerta, administrador de preprocesamiento y sincronizador de historia).
Ahora es posible restringir algunas funciones de Zabbix para reforzar la seguridad del entorno del servidor:
$ALLOW_HTTP_AUTH=false
en el archivo de configuración de la interfaz (zabbix.conf.php).Se ha añadido la posibilidad de validación del archivo de configuración a los comandos de mantenimiento del servidor, proxy Zabbix, agente, agente 2 y servicio web. La validación se puede realizar utilizando la opción -T --test-config. En caso de validación exitosa, el código de salida será "0"; de lo contrario, el componente saldrá con un código de salida distinto de cero y el mensaje de error correspondiente. Las advertencias (por ejemplo, en el caso de un parámetro obsoleto) no afectarán el código de salida exitoso.
La opción para configurar el tipo de inicio del servicio del agente/agent 2 Windows Zabbix (-S --startup-type
) ha sido añadido. Esta opción permite configurar el servicio agente/agente 2 para que se inicie automáticamente al iniciar Windows (automático
), después de que los servicios iniciados automáticamente hayan completado el inicio (retrasado
), cuando lo inicie manualmente un usuario o aplicación (manual
) o para deshabilitar el servicio por completo (deshabilitado
).
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 "retrasado" si no se especifica lo contrario en el parámetro de línea de comando "STARTUPTYPE"](/manual/installation/install_from_packages/win_msi#command-line-based-installation). Esto mejora la confiabilidad y el rendimiento del servicio de Windows agente/agente 2 Zabbix, particularmente durante los reinicios del sistema.
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).
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.
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.
El equilibrio de carga de proxy se implementa mediante la introducción de grupos de proxy en Zabbix. Los grupos de proxy proporcionan distribución automática de equipos entre servidores proxy, reequilibrio de carga de proxy y alta disponibilidad: cuando un proxy se desconecta, sus equipos se distribuyen inmediatamente entre otros servidores proxy del grupo.
Para obtener más información, consulte el equilibrio de carga de proxy y alta disponibilidad.
Se han realizado varios cambios como parte de la transición a una arquitectura multiproceso:
--with-stacksize
. Este parámetro permite anular el tamaño de pila de subprocesos predeterminado utilizado por el sistema (en kilobytes).Anteriormente, las funciones de la biblioteca cURL se detectaban en el momento de la compilación del servidor, proxy o agente de Zabbix. Si se actualizaban las funciones de cURL, para utilizarlas era necesario volver a compilar el componente Zabbix respectivo.
Ahora solo se requiere reiniciar para que las funciones actualizadas de la biblioteca cURL estén disponibles en Zabbix. Ya no es necesaria la recompilación. Esto es cierto para el servidor, proxy o agente de Zabbix.
Consulte también las notas de actualizació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.
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.
Se ha desarrollado un búfer de memoria para el proxy Zabbix. El buffer de memoria permite almacenar nuevos datos (valores de métricas, descubrimiento de red, registro automático de equipos) en el búfer y cargarlo en el servidor Zabbix sin acceder a la base de datos.
En instalaciones anteriores a Zabbix 7.0, los datos recopilados se almacenaban en la base de datos antes de cargarlos en el servidor de Zabbix. Para estas instalaciones este sigue siendo el comportamiento predeterminado después de la actualización.
Para un rendimiento optimizado, se recomienda configurar el uso del búfer de memoria en el proxy. Esto es posible modificando el valor de ProxyBufferMode del valor "disk" (asignado de forma predeterminada para 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 al vaciar los datos no enviados a la base de datos si se detiene el proxy, el buffer 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 la memoria intermedia.
En el modo de memoria, se utilizará el búfer de memoria, sin embargo, no hay protección contra la pérdida de datos. Si el proxy se detiene, o la memoria se llena en exceso, los datos no enviados se eliminarán.
El modo híbrido (ProxyBufferMode=hybrid) se aplica a todas las instalaciones nuevas desde Zabbix 7.0.
Parámetros adicionales como ProxyMemoryBufferSize y ProxyMemoryBufferAge definen el tamaño del búfer de memoria y la antigüedad máxima de los datos en el búfer, respectivamente.
Se han agregado nuevas métricas internas para monitorear el búfer de memoria del proxy.
Los usuarios aprovisionados anteriormente estaban limitados únicamente a los medios creados durante el aprovisionamiento sin la flexibilidad de editar propiedades como horas de trabajo o gravedad.
Ahora hay más flexibilidad disponible para los usuarios aprovisionados en Zabbix:
Además, al configurar la asignación de medios del usuario para aprovisionar campos como Cuando esté activo, Usar si la gravedad y Habilitado ahora están disponibles. Tenga en cuenta que los cambios en el formulario de asignación de tipos de medios del usuario tendrán efecto solo para los nuevos medios creados durante el aprovisionamiento.
Se ha implementado un protocolo basado en JSON para comprobaciones de agentes pasivos.
Para compatibilidad con agentes más antiguos, se agregó una conmutación por error al antiguo protocolo de texto sin formato. Si el agente devuelve "ZBX_NOTSUPPORTED", Zabbix almacenará en caché la interfaz como protocolo antiguo y volverá a intentar la verificación enviando solo la clave de la métrica en texto sin formato.
Zabbix get ahora se puede ejecutar con una nueva opción -P --protocol <valor>
donde "valor" es:
Los protocolos del agente Zabbix y del agente 2 se han unificado cambiando el agente Zabbix al protocolo del agente Zabbix 2. La diferencia entre las solicitudes/respuestas del agente Zabbix y del agente Zabbix 2 se expresa mediante el valor de etiqueta "variant" ("1" - agente Zabbix, "2" - agente Zabbix 2).
Ver también: Comprobaciones de agentes activos y pasivos.
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).
Anteriormente, cada regla de descubrimiento de red era procesada por un proceso de descubrimiento. Por lo tanto, todas las comprobaciones de servicio dentro de la regla sólo podrían realizarse secuencialmente.
En la nueva versión, el proceso de descubrimiento de red se ha rediseñado para permitir la simultaneidad entre las comprobaciones de servicio. Se ha agregado un nuevo proceso administrador de descubrimiento junto con una cantidad configurable de trabajadores (o subprocesos) de descubrimiento.
El administrador de descubrimiento procesa las reglas de descubrimiento y crea un trabajo de descubrimiento por cada regla con tareas (verificaciones de servicio). Las comprobaciones de servicio son recogidas y realizadas por los trabajadores de descubrimiento. Sólo aquellas comprobaciones que tengan la misma IP y puerto son programadas de forma secuencial porque es posible que algunos dispositivos no permitan conexiones simultáneas en el mismo puerto.
Una nueva métrica interna zabbix[discovery_queue]
permite monitorear la cantidad de comprobaciones de descubrimiento en la cola.
El parámetro StartDiscoverers ahora determina el número total de trabajadores de descubrimiento disponibles para el descubrimiento. El número predeterminado de StartDiscoverers se ha aumentado de 1 a 5 y el rango de 0-250 a 0-1000. Los procesos de "descubrimiento" de versiones anteriores de Zabbix se han eliminado.
Además:
Ahora hay operaciones adicionales disponibles para eventos de descubrimiento y registro automático:
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.
La funcionalidad transmisión de datos ya no es experimental.
Para plantillas nuevas y cambios en plantillas existentes, consulte Cambios de plantilla.
Se han actualizado varias funciones:
El período predeterminado para mantener el historial de la métrica se ha hecho consistente en 31 días en la interfaz y en la base de datos. Este cambio afecta los formularios de configuración de métricas, plantilla de métricas y prototipos de métricas, así como la anulación del período de almacenamiento del historial en el descubrimiento de bajo nivel.
Ahora, si se recibe un valor de punto flotante para ua métrica de entero sin signo, el valor se recortará de la parte decimal y se guardará como un número entero. Anteriormente, un valor de coma flotante hacía que una m-etrica de entero no fuera compatible.
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.
Se agregó una nueva métrica SNMP get[OID]
que permite consultar un único valor OID de forma asincrónica.
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.
Se han agregado métricas internas para monitorear el búfer de memoria 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 disco/memoria buffer desde el inicio;zabbix[proxy_buffer,state,current]
- devuelve el estado de trabajo actual donde se almacenan los nuevos datos.También se han agregado las siguientes métricas internas:
zabbix[discovery_queue]
- permite monitorear la cantidad de comprobaciones de descubrimiento en la cola;zabbix[vps,write]
: permite monitorear el número total de valores históricos escritos en la base de datos.Se han agregado nuevas métricas al agente/agente 2 de Zabbix:
net.dns.perf
devuelve el número de segundos transcurridos esperando una respuesta de un servicio, cronometrando el [net.dns
] `](/manual/config/items/itemtypes/zabbix_agent#net.dns) ejecución del elemento.net.dns.get
del agente 2 de Zabbix devuelve información detallada del registro DNS.Se han actualizado las siguientes métricas del agente/agente 2 de Zabbix:
net.dns
y net.dns.record
ahora aceptan el nombre DNS en formato invertido y no invertido al realizar búsquedas DNS inversas;proc.get
en modo "proceso" y "resumen" ahora también devuelven la memoria PSS (tamaño de conjunto proporcional) en Linux;system.sw.packages
y system.sw.packages.get
ahora son compatibles con Gentoo Linux;system.hostname
ahora puede devolver un nombre de dominio completo, si la nueva opción fqdn se especifica en tipo parámetro;wmi.get
y wmi.getall
utilizados con el agente Zabbix 2 ahora devuelven JSON con valores booleanos representados como cadenas (por ejemplo, "RealTimeProtectionEnabled": "True"
en lugar de "RealTimeProtectionEnabled": true
devuelto anteriormente) para coincidir con el formato de salida de estos elementos en el agente Zabbix;oracle.ts.discovery
del agente 2 de Zabbix ahora devuelve un nuevo {#CON_NAME} Macro LLD con nombre de contenedor;oracle.ts.stats
del agente 2 de Zabbix tiene un nuevo parámetro conname para especificar el nombre del contenedor de destino. Se actualizó el formato JSON de los datos devueltos. Cuando no se especifica ningún tablespace, type o conname en los parámetros clave, los datos devueltos incluirán un nivel JSON adicional con el nombre del contenedor, lo que permitirá la diferenciación entre contenedores.La métrica vmware.eventlog
ahora admite el filtrado opcional por gravedad en el tercer parámetro.
La métrica vmware.vm.discovery
ahora también devuelve datos en las interfaces de red de máquinas virtuales. Estos datos se pueden utilizar para configurar interfaces de equipo personalizadas.
La métrica vmware.vm.net.if.discovery
ahora también devuelve una matriz de direcciones de interfaz.
Se agregó un nuevo parámetro opciones a las siguientes métricas:
Este parámetro se puede utilizar para especificar si las respuestas redirigidas deben tratarse como equipo de destino activo o equipo de destino inactivo. Consulte comprobaciones simples para obtener más detalles.
Los ID de motor en SNMPv3 se utilizan como identificadores únicos del dispositivo. A veces, los ID de motor son los mismos en varios dispositivos debido a una mala configuración o a los ajustes de fábrica. Como los estándares SNMP requieren que los ID de motor sean únicos, las métricas que comparten el mismo ID de motor dejan de ser compatibles con Zabbix, lo que genera problemas de disponibilidad con estos dispositivos.
Para ayudar a solucionar estos problemas, el servidor Zabbix ahora registrará periódicamente la información sobre los dispositivos SNMPv3 que comparten el mismo ID de motor. Tenga en cuenta que la detección de ID de motor duplicado funciona en cada sondeador SNMP por separado.
Ahora es posible ejecutar comandos remotos en un agente versión 7.0 que esté funcionando en modo activo. Una vez que la ejecución de un comando remoto se activa mediante una acción operación o una ejecución manual de script, el comando se incluirá en la configuración de comprobaciones activas y se ejecutará una vez que el agente activo lo reciba. Tenga en cuenta que los agentes activos más antiguos ignorarán cualquier comando remoto incluido en la configuración de comprobaciones activas. Para obtener más información, consulte Comprobaciones de agentes activos y pasivos.
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.
La tabla history_bin
se ha convertido a hipertabla en TimescaleDB para beneficiarse de la partición automática a tiempo (1 día de manera predeterminada) y un mejor rendimiento.
Para actualizar correctamente las instalaciones existentes, consulte Actualización del esquema de TimescaleDB.
Consulte también: Versiones de TimescaleDB compatibles
Los registros de proxy se han eliminado de la tabla "hosts" y ahora están almacenados en la nueva tabla "proxy".
Además, los datos operativos de los servidores proxy (como el último acceso, la versión, la compatibilidad) se han eliminado de la tabla host_rtdata
y ahora se almacenan en la nueva tabla proxy_rtdata
.
Campos de URL
El límite de caracteres para todos los campos de URL ahora es de 2048 caracteres. Esto ahora incluye: URL de mosaico para configuraciones relacionadas con mapas geográficos, URL de interfaz para configurar varios parámetros de interfaz, URL para mapas de red y elementos del mapa de red, URL A-C para los campos inventario de equipo, y URL para el widget URL de tablero.
Campos de autenticación
El límite de caracteres para los campos de autenticación Usuario/Nombre de usuario y Contraseña ahora es de 255 caracteres. Esto se aplica a la configuración de la autenticación HTTP para métricas de agente HTTP, escenarios web y conectores, así como configurar la autenticación para comprobaciones simples, Monitoreo ODBC, Comprobaciones SSH, Comprobaciones de Telnet, y monitoreo JMX.
Al probar métricas o probar pasos de preprocesamiento, los valores recuperados de un equipo y los resultados de la prueba ahora se truncan al máximo tamaño de 512 KB cuando se envía al frontend. Tenga en cuenta que el servidor Zabbix aún procesa completamente los datos de más de 512 KB.
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.
En Administración → Registro de auditoría, ahora puede habilitar/deshabilitar el registro de auditoría de descubrimiento de bajo nivel, descubrimiento de red y actividades de registro automático realizadas por el servidor (usuario del sistema). ).
El período predeterminado de almacenamiento de registros de auditoría antes de que el administrador los elimine se ha cambiado de 365 días a 31 días.
En Monitoreo → Últimos datos, el subfiltro y los datos ya no se muestran de forma predeterminada si el filtro no está configurado.
Si actualiza desde versiones anteriores de Zabbix, consulte también: Notas de actualización para 7.0.0.
La versión mínima requerida de PHP se ha elevado de 7.4.0 a 8.0.0.
Varios formularios de interfaz ahora se abren en ventanas modales (emergentes):
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.
El antiguo estilo de valores de punto flotante, anteriormente obsoleto, ya no se admite, ya que se utilizan valores numéricos de rango extendido.
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.
Se han agregado varios widgets nuevos en la nueva versión, mientras que se ha mejorado la funcionalidad disponible en otros. Además, los widgets de tablero ahora pueden conectarse y comunicarse entre sí, lo que hace que los widgets y los tableros sean más dinámicos.
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.
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. |
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).
Se ha agregado un widget Iniciadores principales a widgets del tablero, lo que permite visualizar los iniciadores con mayor número de problemas.
Para obtener más información, consulte: Iniciadores principales.
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.
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.
El nuevo widget de tablero Historial de métricas ha reemplazado al widget de Texto sin formato y ofrece varias mejoras.
A diferencia del widget Texto sin formato, que solo mostraba los datos más recientes de la métrica en texto sin formato, el widget Historial de métricas admite varias opciones de visualización para múltiples tipos de métricas (numéricos, de caracteres, de registro, de texto y binarios). Por ejemplo, puede mostrar barras o indicadores de progreso, imágenes para tipos de datos binarios (útiles para métricas de navegador) y resaltar valores de texto (útiles para monitoreo de archivos de registro).
Para obtener más información, consulte Historial de métricas. Para obtener detalles sobre el reemplazo del widget Texto sin formato, consulte Notas de actualización para 7.0.0.
Los períodos de tiempo ahora se pueden configurar en los widgets Valor de métrica y Equipos principales.
Ahora también es posible mostrar un valor agregado en el widget de valor de métrica para el período elegido. El valor agregado se puede mostrar como:
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, mientras que en otro el valor promedio durante un período más largo. O se pueden utilizar varios widgets para comparar en paralelo valores agregados de varios períodos del pasado.
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 de la métrica, también es posible establecer la columna Nombre de equipo o Texto como columna de orden en el widget Equipos principales.
Se han agregado nuevas funciones para usar en expresiones de iniciador y métricas calculadas:
Ver también: Funciones de cadena
Las casillas de verificación Configuración avanzada, responsables de mostrar las opciones de configuración avanzadas, han sido reemplazadas por bloques plegables. (ver, por ejemplo, Configuración del conector, Configuración del servicio, configuración del widget Reloj, etc.). Esto mejora la experiencia del usuario, ya que al contraer estos bloques y guardar la configuración ya no se restablecerán las opciones avanzadas configuradas a sus valores predeterminados.
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.
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 |
---|---|
Los widgets de tablero ahora pueden conectarse y comunicarse entre sí, lo que hace que los widgets y los tableros sean más dinámicos. Varios widgets tienen parámetros que les permiten compartir datos de configuración entre widgets compatibles o el tablero.
Esta característica introduce los siguientes cambios:
Dependiendo del widget y sus parámetros, la fuente de datos puede ser un widget compatible del mismo tablero o el propio tablero. Para obtener más información, consulte widgets del tablero.
Para cambios en las plantillas por defecto que se envían con Zabbix, consulte Cambios de plantilla.
El widget Disponibilidad de equipo ahora permite mostrar los equipos con la interfaz Agente Zabbix (comprobaciones activas). Se ha agregado un estado de disponibilidad más, es decir, Mixto, que corresponde a la situación en la que al menos una interfaz no está disponible y al menos una está disponible o desconocido. Además, la posibilidad de ver sólo el total de equipos, sin desglose 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.
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).
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.
Los recursos que ya no se descubren mediante descubrimiento de bajo nivel ahora se pueden desactivar automáticamente. Se pueden desactivar inmediatamente, después de un período de tiempo específico o nunca (consulte el nuevo parámetro Desactivar recursos perdidos en la configuración de la regla de descubrimiento).
Los recursos perdidos (equipos, métricas, iniciadores) están marcados con un ícono de información en la columna de estado. El texto de información sobre herramientas proporciona detalles sobre su estado.
Dentro del mismo desarrollo, el parámetro Mantener período de recursos perdidos ha pasado a llamarse Eliminar recursos perdidos con opciones para eliminar inmediatamente, después de un período de tiempo específico o nunca.
La entrada manual del usuario para scripts frontend permite proporcionar un parámetro personalizado en cada ejecución del script. Esto ahorra la necesidad de crear múltiples scripts de usuario similares con una única diferencia de parámetro.
Por ejemplo, es posible que desee proporcionar un número entero diferente o una dirección URL diferente al script durante la ejecución.
Para habilitar la entrada manual del usuario:
Con la entrada del usuario habilitada, antes de la ejecución del script, aparecerá una ventana emergente de Entrada manual al usuario solicitándole que proporcione un valor personalizado. El valor proporcionado reemplazará a {MANUALINPUT} en el script.
Dependiendo de la configuración, se le pedirá al usuario que ingrese un valor de cadena o seleccione el valor de un menú desplegable de opciones predeterminadas.
El manejo de errores en caso de que no se pudiera recuperar el valor de una métrica (y, por lo tanto, dejara de ser compatible) anteriormente carecía de la capacidad de distinguir el motivo o la etapa de tiempo de ejecución donde falló el proceso. Todos los errores debían manejarse utilizando la misma opción para el manejo de errores: ya sea descartar el valor, establecer un valor específico o establecer un mensaje de error específico.
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 se debe procesar el caso de error. Por ejemplo, un mensaje de error específico se puede "asignar" a un caso más general para que coincida y se maneje mediante un paso de preprocesamiento adicional, o algún problema intermitente (por ejemplo, conectividad de red) se puede manejar de manera diferente a una falla definitiva en la adquisición del mensaje. valor del ítem.
Ahora se pueden agregar varios pasos de preprocesamiento Verificar valor no admitido. Tenga en cuenta que solo puede haber un paso de coincidencia de "cualquier error" al final de la canalización que busca el estado no compatible del elemento. Si está presente, se activa si ninguna de las comprobaciones específicas coincide (mal) con el patrón correspondiente, o si se transfirió un mensaje de error (modificado), es decir, no entró en vigor ninguna anulación de "Descartar valor" o "Establecer valor en".
Consulte también: Compruebe si hay valores no admitidos
El diseño anterior del formulario de actualización masiva de métricas no era lo suficientemente claro si la actualización del paso de preprocesamiento agregaba o reemplazaba pasos de preprocesamiento. En el nuevo diseño se agregaron los botones de opción Reemplazar y Eliminar todo, lo que deja claro a los usuarios qué esperar como resultado de la actualización masiva del paso de preprocesamiento:
Las macros de usuario ahora son compatibles con los nombres de métricas y los nombres de prototipos de métricas.
Tenga en cuenta que la compatibilidad con macros de usuario se eliminó de los nombres de métricas/prototipos de métricas en Zabbix 6.0. Ahora ha sido restaurado. Ahora también se admite la búsqueda por nombre de métrica con las macros resueltas, que anteriormente no era compatible.
El nombre de la métrica con las macros resueltas se almacena en una tabla de base de datos separada (item_rtname
), que es una extensión de la tabla de métricas. Para cada registro en la tabla de métricas, se crea un registro item_rtname
correspondiente (excepto para prototipos de métricas, métricas de reglas de descubrimiento y métricas de plantilla). El nombre con macros resueltas está limitado a 2048 caracteres.
El nombre de la métrica con las macros resueltas se muestra en todas las ubicaciones de la interfaz excepto en la sección Recopilación de datos.
Se ha agregado un nuevo proceso de servidor "trabajador de sincronización de configuración" que es responsable de resolver y sincronizar los valores de macro de usuario en los nombres de las métricas.
Las funciones de macro ahora son compatibles con todo tipo de macros:
Las funciones de macro se pueden utilizar en todas las ubicaciones que admitan las macros enumeradas. Esto se aplica a menos que se indique explícitamente que solo se espera una macro. (por ejemplo, al configurar macros de equipo o filtros de regla de descubrimiento de bajo nivel).
La funcionalidad informes programados ya no es experimental.
Para tableros de varias páginas, los informes ahora se devuelven con todas las páginas del tablero, y cada página PDF corresponde a una página del tablero. Anteriormente, esta funcionalidad se limitaba a devolver solo la primera página del tablero.
Todos los íconos en la interfaz se han cambiado de imágenes de íconos a fuentes.
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:
Hay paquetes de instalación dedicados 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 distribuciones basadas en RHEL. Ahora se utilizan paquetes separados para RHEL y cada uno de sus derivados mencionados anteriormente. para evitar posibles problemas de incompatibilidad binaria.
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.