Consulte también: Problemas de compilación.
La configuración sql_mode en MySQL/MariaDB debe tener el modo "STRICT_TRANS_TABLES" establecido. Si está ausente, la actualización de la base de datos de Zabbix fallará (consulte también ZBX-19435).
La actualización de Zabbix puede fallar si las tablas de la base de datos se crearon con MariaDB 10.2.1 y anteriores, porque en esas versiones el formato de fila predeterminado es compacto. Esto se puede solucionar cambiando el formato de fila a dinámico (consulte también ZBX-17690).
En entornos de doble pila (sistemas configurados para admitir tanto IPv4 como IPv6), el nombre de host localhost normalmente se resuelve en direcciones tanto IPv4 como IPv6. Debido a la priorización común de IPv6 sobre IPv4 por parte de muchos sistemas operativos y resolutores DNS, las plantillas de Zabbix pueden dejar de funcionar correctamente si el servicio que se está monitorizando está configurado para escuchar solo en IPv4.
Los servicios que no están configurados para escuchar en direcciones IPv6 pueden volverse inaccesibles, lo que provoca fallos en la monitorización. Los usuarios pueden configurar el acceso correctamente para IPv4 pero seguir enfrentando problemas de conectividad debido al comportamiento predeterminado de priorizar IPv6.
Una solución para esto es asegurarse de que los servicios (Nginx, Apache, PostgreSQL, etc.) estén configurados para escuchar en direcciones tanto IPv4 como IPv6, y que el servidor/agente Zabbix tenga permitido el acceso a través de IPv6. Además, en las plantillas y configuraciones de Zabbix, utilice explícitamente localhost en lugar de 127.0.0.1 para garantizar la compatibilidad con IPv4 e IPv6.
Por ejemplo, al monitorizar PostgreSQL con la plantilla PostgreSQL por Zabbix agent 2, es posible que deba editar el archivo pg_hba.conf para permitir conexiones para el usuario zbx_monitor. Si el entorno de doble pila prioriza IPv6 (el sistema resuelve localhost como ::1) y configura localhost pero solo agrega una entrada IPv4 (127.0.0.1/32), la conexión fallará porque no hay una entrada IPv6 correspondiente.
El siguiente ejemplo de archivo pg_hba.conf garantiza que el usuario zbx_monitor pueda conectarse a cualquier base de datos desde la máquina local utilizando direcciones tanto IPv4 como IPv6 con diferentes métodos de autenticación:
# TYPE DATABASE USER ADDRESS METHOD
host all zbx_monitor localhost trust
host all zbx_monitor 127.0.0.1/32 md5
host all zbx_monitor ::1/128 scram-sha-256Si es necesario, también puede utilizar la dirección IPv4 (127.0.0.1) directamente al configurar la macro de la plantilla PostgreSQL por Zabbix agent 2 para la cadena de conexión.
Si el repositorio EPEL está instalado y habilitado, al instalar paquetes de Zabbix se pueden obtener versiones de EPEL en lugar de los paquetes oficiales de Zabbix. Para resolver esto:
1. Elimine cualquier paquete de Zabbix instalado desde EPEL:
2. Excluya los paquetes de Zabbix de EPEL agregando la siguiente línea al archivo /etc/yum.conf:
3. Reinstale el paquete oficial del servidor Zabbix:
Durante la instalación, los paquetes oficiales de Zabbix incluyen la palabra release en su cadena de versión (por ejemplo, 7.0.0-release1.el8), lo que los distingue de los paquetes de EPEL.
Al instalar Zabbix desde paquetes de Red Hat Enterprise Linux en entornos Red Hat Universal Base Image, asegúrese de tener acceso a los repositorios y dependencias necesarios. Los paquetes de Zabbix dependen de las bibliotecas libOpenIPMI.so y libOpenIPMIposix.so, que no son proporcionadas por ningún paquete en los repositorios predeterminados del administrador de paquetes habilitados en los sistemas UBI y provocarán fallas en la instalación.
Las bibliotecas libOpenIPMI.so y libOpenIPMIposix.so están disponibles en el paquete OpenIPMI-libs, que es proporcionado por el repositorio redhat-#-for-<arch>-appstream-rpms. El acceso a este repositorio se gestiona mediante suscripciones que, en el caso de entornos UBI, se propagan montando la configuración del repositorio y los directorios secretos del host RHEL en el espacio de nombres del sistema de archivos del contenedor.
Para obtener más información, consulte ZBX-24291.
Al actualizar Zabbix en Red Hat Enterprise Linux o sus derivados, puede encontrarse con un problema de clave de firma caducada para los paquetes en el repositorio de Zabbix. Cuando una clave de firma caduca, los intentos de verificar las firmas de los paquetes darán como resultado un error que indica que el certificado o la clave ya no son válidos. Por ejemplo:
error: Verificando una firma usando el certificado D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
1. Certificado 19F2475308EFA7DD no válido: el certificado no está activo
porque: La clave primaria no está activa
porque: Caducó el 2024-07-04T11:41:23Z
2. Clave 19F2475308EFA7DD no válida: la clave no está activa
porque: La clave primaria no está activa
porque: Caducó el 2024-07-04T11:41:23ZPara resolver estos problemas, reinstale manualmente el paquete zabbix-release más reciente para su variante específica de RHEL (reemplace el enlace a continuación por el correcto del repositorio de Zabbix).
Por ejemplo, en RHEL 9, ejecute:
Luego, actualice la información del repositorio:
Para más información, consulte ZBX-24761.
La conexión TLS a la base de datos no es compatible con la opción 'verify_ca' para el parámetro DBTLSConnect si se utiliza MariaDB.
Al ejecutarse bajo alta carga, y con más de un trabajador LLD involucrado, es posible encontrarse con un interbloqueo causado por un error de InnoDB relacionado con la estrategia de bloqueo de filas (consulte el error upstream). El error ha sido corregido en MySQL desde la versión 8.0.29, pero no en MariaDB. Para más detalles, consulte ZBX-21506.
Es posible que los eventos no se correlacionen correctamente si el intervalo de tiempo entre el primer y el segundo evento es muy pequeño, es decir, medio segundo o menos.
PostgreSQL 11 y versiones anteriores solo admiten un rango de valores de punto flotante de aproximadamente -1.34E-154 a 1.34E+154.
Varios procesos de Zabbix pueden fallar aleatoriamente al iniciarse en las versiones 8.X y 9.X de NetBSD. Esto se debe a que el tamaño de pila predeterminado es demasiado pequeño (4MB), por lo que debe aumentarse ejecutando:
Para obtener más información, consulte el informe de problema relacionado: ZBX-18275.
Zabbix Agent 2 no admite búsquedas hacia adelante y hacia atrás en expresiones regulares debido a las limitaciones de la biblioteca estándar de expresiones regulares de Go.
Las comprobaciones IPMI no funcionarán con el paquete estándar de la biblioteca OpenIPMI en Debian anterior a la versión 9 (stretch) y Ubuntu anterior a la versión 16.04 (xenial). Para solucionar esto, vuelva a compilar la biblioteca OpenIPMI con OpenSSL habilitado como se explica en ZBX-6139.
Conector PostgreSQL, SQLite u Oracle → controlador MariaDB o MySQL unixODBC Conector MariaDB → controlador MariaDB unixODBC Conector MySQL → controlador MySQL unixODBC
Consulte ZBX-7665 para obtener más información y soluciones alternativas disponibles.
Los datos XML consultados desde Microsoft SQL Server pueden truncarse de varias maneras en sistemas Linux y UNIX.
Se ha observado que el uso de comprobaciones ODBC para monitorizar bases de datos Oracle utilizando varias versiones de Oracle Instant Client para Linux provoca que el servidor Zabbix se bloquee.
Consulte también: ZBX-18402, ZBX-20803.
Si utiliza el controlador FreeTDS UnixODBC, debe anteponer una instrucción 'SET NOCOUNT ON' a una consulta SQL (por ejemplo, SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....). De lo contrario, el elemento de monitorización de la base de datos en Zabbix no podrá recuperar la información y mostrará el error "La consulta SQL devolvió un resultado vacío".
Consulte ZBX-19917 para obtener más información.
El parámetro de método de solicitud, utilizado solo en comprobaciones HTTP, puede estar configurado incorrectamente en '1', un valor no predeterminado para todos los elementos como resultado de una actualización desde una versión de Zabbix anterior a la 4.0. Para obtener detalles sobre cómo solucionar esta situación, consulte ZBX-19308.
El servidor Zabbix presenta fugas de memoria en algunas distribuciones de Linux debido a un error upstream cuando "Verificar par SSL" está habilitado en escenarios web o en el agente HTTP. Consulte ZBX-10486 para obtener más información y soluciones alternativas disponibles.
Existe un error en las versiones de fping anteriores a la v3.10 que maneja incorrectamente los paquetes de eco de respuesta duplicados. Esto puede causar resultados inesperados en los elementos icmpping, icmppingloss, icmppingsec. Se recomienda utilizar la última versión de fping. Consulte ZBX-11726 para más detalles.
Cuando los contenedores se ejecutan en modo sin privilegios de root o en un entorno con restricciones específicas, puede encontrar errores relacionados con la ejecución de fping al realizar comprobaciones ICMP, como fping: Operación no permitida o la pérdida de todos los paquetes a todos los recursos.
Para solucionar este problema, agregue --cap-add=net_raw a los comandos "docker run" o "podman run".
Además, la ejecución de fping en entornos sin privilegios de root puede requerir la modificación de sysctl, es decir:
donde "1995" es el GID de zabbix. Para más detalles, consulte ZBX-22833.
Si se utiliza el sistema operativo OpenBSD, un error de uso después de liberar memoria en la biblioteca Net-SNMP hasta la versión 5.7.3 puede causar un fallo en el servidor Zabbix si el parámetro SourceIP está configurado en el archivo de configuración del servidor Zabbix. Como solución temporal, por favor no configure el parámetro SourceIP. El mismo problema también se aplica a Linux, pero no hace que el servidor Zabbix deje de funcionar. Se aplicó un parche local para el paquete net-snmp en OpenBSD y se lanzará con OpenBSD 6.3.
Se han observado picos en los datos SNMP que pueden estar relacionados con ciertos factores físicos, como picos de voltaje en la red eléctrica. Consulte ZBX-14318 para más detalles.
El paquete "net-snmp-perl", necesario para las trampas SNMP, fue eliminado en RHEL 8.0-8.2; se volvió a agregar en RHEL 8.3.
Por lo tanto, si está utilizando RHEL 8.0-8.2, la mejor solución es actualizar a RHEL 8.3.
Consulte también ZBX-17192 para obtener más información.
Se han encontrado casos de bloqueo del proceso alerter del servidor Zabbix en RHEL 7. Consulte ZBX-10461 para más detalles.
Al actualizar Zabbix agent 2 (versión 6.0.5 o anterior) desde paquetes, puede producirse un error de conflicto de archivos relacionado con el plugin. Para solucionar el error, haga una copia de seguridad de la configuración del agente 2 (si es necesario), desinstale el agente 2 e instálelo de nuevo.
En sistemas basados en RHEL, ejecute:
En sistemas basados en Debian, ejecute:
Para más información, consulte ZBX-23250.
Se ha observado que los idiomas de la interfaz web pueden cambiar sin una lógica aparente, es decir, algunas páginas (o partes de páginas) se muestran en un idioma mientras que otras páginas (o partes de páginas) en un idioma diferente. Típicamente, el problema puede aparecer cuando hay varios usuarios, algunos de los cuales usan un idioma, mientras que otros usan otro.
Una solución conocida para esto es deshabilitar el multihilo en PHP y Apache.
El problema está relacionado con cómo funciona la configuración del idioma en PHP: la información del idioma se mantiene por proceso, no por hilo. Así que en un entorno multihilo, cuando hay varios proyectos ejecutados por el mismo proceso de Apache, es posible que el idioma se cambie en otro hilo y eso cambie cómo se pueden procesar los datos en el hilo de Zabbix.
Para más información, consulte los informes de problemas relacionados:
bcdiv de las funciones BC Math)Los cambios en el horario de verano (DST) provocan irregularidades al mostrar las etiquetas del eje X (duplicación de fechas, fechas faltantes, etc.).
Al utilizar la agregación de suma en un gráfico para un período inferior a una hora, los gráficos muestran valores incorrectos (multiplicados) cuando los datos provienen de tendencias.
Para algunos idiomas de la interfaz (por ejemplo, japonés), las fuentes locales pueden causar superposición de texto en la leyenda del gráfico. Para evitar esto, utilice la versión 2.3.0 (o posterior) de la extensión PHP GD.
Los elementos log[] y logrt[] vuelven a leer repetidamente el archivo de registro desde el principio si el sistema de archivos está al 100% de su capacidad y el archivo de registro se está ampliando (consulte ZBX-10884 para obtener más información).
El servidor Zabbix genera consultas SELECT lentas en caso de valores inexistentes para los ítems. Se sabe que este problema ocurre en las versiones 5.6/5.7 de MySQL (para una discusión más detallada, consulte ZBX-10652), y, en casos específicos, también puede ocurrir en versiones posteriores de MySQL. Una solución temporal para esto es deshabilitar el optimizador index_condition_pushdown o prefer_ordering_index en MySQL. Sin embargo, tenga en cuenta que esta solución temporal puede no corregir todos los problemas relacionados con consultas lentas.
La sincronización de configuración puede ser lenta en instalaciones de Zabbix con Oracle DB que tienen un alto número de elementos y pasos de preprocesamiento de elementos. Esto es causado por la velocidad de procesamiento del motor de base de datos Oracle al procesar campos de tipo nclob.
Para mejorar el rendimiento, puede convertir los tipos de campo de nclob a nvarchar2 aplicando manualmente el parche de base de datos items_nvarchar_prepare.sql. Tenga en cuenta que esta conversión reducirá el límite máximo del tamaño del campo de 65535 bytes a 4000 bytes para los parámetros de preprocesamiento de elementos y parámetros de elementos como Descripción, el campo Script del elemento de Script, los campos Cuerpo de la solicitud y Encabezados del elemento de agente HTTP, el campo Consulta SQL del elemento de monitor de base de datos. Las consultas para determinar los nombres de plantillas que deben eliminarse antes de aplicar el parche se proporcionan en el parche como un comentario. Alternativamente, si MAX_STRING_SIZE está configurado, puede cambiar nvarchar2(4000) a nvarchar2(32767) en las consultas del parche para establecer el límite de tamaño de campo en 32767 bytes.
Para una discusión más detallada, consulte ZBX-22363.
Al abrir un enlace a una página del frontend de Zabbix que contiene configuraciones de filtro, incluido el selector de tiempo, el filtro se guarda automáticamente en la base de datos para el usuario, reemplazando la configuración de filtro y/o selector de tiempo guardada previamente para esa página. Estas configuraciones permanecen activas hasta que el usuario las actualice o restablezca manualmente.
Debido a un error en net-snmp, la dirección IPv6 puede no mostrarse correctamente al usar SNMPv3 en traps SNMP. Para más detalles y una posible solución, consulte ZBX-14541.
Un mensaje de intento de inicio de sesión fallido mostrará solo los primeros 39 caracteres de una dirección IP almacenada, ya que ese es el límite de caracteres en el campo de la base de datos. Eso significa que las direcciones IP IPv6 más largas de 39 caracteres se mostrarán de forma incompleta.
Las entradas DNS inexistentes en un parámetro Server del archivo de configuración del agente Zabbix (zabbix_agentd.conf) pueden aumentar el tiempo de respuesta del agente Zabbix en Windows. Esto ocurre porque el demonio de caché DNS de Windows no almacena en caché las respuestas negativas para direcciones IPv4. Sin embargo, para las direcciones IPv6, las respuestas negativas sí se almacenan en caché, por lo que una posible solución es deshabilitar IPv4 en el equipo.
Existen algunos problemas conocidos con la exportación/importación YAML:
El asistente de configuración del frontend no puede guardar el archivo de configuración en SUSE con NGINX + php-fpm. Esto se debe a una configuración en la unidad /usr/lib/systemd/system/php-fpm.service, que impide que Zabbix escriba en /etc. (introducido en PHP 7.4).
Hay dos opciones alternativas disponibles:
En algunos casos, Apache o NGINX pueden impedir que la cabecera Authorization en las solicitudes de la API llegue a Zabbix. Esto puede causar problemas de autenticación al utilizar la API de Zabbix o servicios de inicio de sesión único (SSO), como SAML con Okta.
Para solucionar esto, actualice la configuración de su servidor web.
Para Apache, si lo está utilizando como proxy inverso (configuración no CGI), agregue la siguiente directiva a /etc/httpd/conf/httpd.conf (en sistemas basados en RHEL) o /etc/apache2/apache2.conf (en Debian/Ubuntu):
Si Apache ejecuta directamente scripts para manejar las solicitudes (por ejemplo, usando mod_cgi), agregue la siguiente directiva en su lugar:
En cambio, NGINX maneja la cabecera Authorization automáticamente. Sin embargo, si NGINX está actuando como proxy inverso, puede reenviar explícitamente la cabecera Authorization agregando las siguientes directivas a /etc/nginx/nginx.conf (para la ubicación de su frontend de Zabbix):
...
location / {
...
proxy_set_header Authorization $http_authorization;
proxy_pass http://backend_server;
...
}Después de actualizar la configuración, reinicie su servidor web.
Para más detalles, consulte:
Aunque en la mayoría de los casos, el servicio web de Zabbix puede ejecutarse con Chromium, en Ubuntu 20.04 el uso de Chromium provoca el siguiente error:
Cannot fetch data: chrome failed to start:cmd_run.go:994:
WARNING: cannot create user data directory: cannot create
"/var/lib/zabbix/snap/chromium/1564": mkdir /var/lib/zabbix: permission denied
Sorry, home directories outside of /home are not currently supported. See https://forum.snapcraft.io/t/11209 for details.Este error ocurre porque /var/lib/zabbix se utiliza como directorio home del usuario 'zabbix'.
Cuando Zabbix detecta que la base de datos de backend no es accesible, envía una notificación y continúa intentando conectarse. Para ciertos motores de base de datos, se reconocen códigos de error específicos. En MySQL, estos códigos de error reconocidos incluyen:
Además, al usar Zabbix con una instalación de MySQL en Azure, puede aparecer en los registros de Zabbix el mensaje de error genérico [9002] Se produjeron algunos errores. Este mensaje es enviado por la base de datos al servidor o proxy de Zabbix. Para determinar la causa del error, consulte los registros de Azure.
En Zabbix 6.0 se ha añadido soporte para PCRE2. Aunque PCRE sigue siendo compatible, los paquetes de instalación de Zabbix para RHEL 7 y versiones posteriores, SLES (todas las versiones), Debian 9 y versiones posteriores, Ubuntu 16.04 y versiones posteriores se han actualizado para usar PCRE2. Si bien proporciona muchos beneficios, cambiar a PCRE2 puede hacer que ciertos patrones de expresiones regulares de PCRE existentes se vuelvan inválidos o se comporten de manera diferente. En particular, esto afecta al patrón ^[\w-\.]. Para que esta expresión regular vuelva a ser válida sin afectar a la semántica, cambie la expresión a ^[-\w\.] . Esto ocurre debido a que PCRE2 trata el signo de guion como un delimitador, creando un rango dentro de una clase de caracteres.
Es posible que los mapas en el widget Geomap no se carguen correctamente si ha actualizado desde una versión anterior de Zabbix con NGINX y no cambió al nuevo archivo de configuración de NGINX durante la actualización.
Para solucionar el problema, puede descartar el archivo de configuración antiguo, utilizar el archivo de configuración del paquete de la versión actual y reconfigurarlo como se describe en las instrucciones de descarga en la sección e. Configurar PHP para el frontend de Zabbix.
Alternativamente, puede editar manualmente un archivo de configuración de NGINX existente (normalmente, /etc/zabbix/nginx.conf). Para ello, abra el archivo y localice el siguiente bloque:
Luego, reemplace este bloque por:
location ~ /(api\/|conf[^\.]|include|locale) {
deny all;
return 404;
}
location /vendor {
deny all;
return 404;
}El JavaScript de preprocesamiento se ejecuta por solicitud, pero las asignaciones a identificadores no declarados (por ejemplo, secreto = valor) crean variables globales implícitas que pueden persistir más allá de la ejecución actual. Almacenar datos sensibles (tokens, contraseñas, etc.) en variables globales implícitas aumenta el riesgo de exposición accidental o reutilización por ejecuciones de preprocesamiento posteriores u otras integraciones que se ejecuten en el mismo entorno.
No confíe en las variables globales implícitas. Declare siempre las variables con var o const, y evite adjuntar secretos a objetos globales (por ejemplo, globalThis o window). No existe una forma compatible de sobrescribir objetos globales integrados desde el preprocesamiento.
Ejemplo seguro:
var apiToken = payload.token;
var count = 1;
return JSON.stringify({ token: apiToken, calls: count });Actualizar a Zabbix 7.0.1 (o posterior) desde Zabbix 7.0.0 con TimescaleDB provoca un bloqueo del servidor. Este problema es causado por una solución temporal a un problema de tarea de compresión en la tabla auditlog en Zabbix 7.0 que cambió irreversiblemente la política de compresión de la tabla auditlog.
Para solucionar el problema, realice una reconstrucción manual de la tabla auditlog. La tabla auditlog defectuosa se puede detectar utilizando esta consulta:
SELECT config FROM timescaledb_information.jobs WHERE application_name LIKE 'Compression%' AND hypertable_schema='public' AND hypertable_name='auditlog';.Si devuelve un objeto JSON que contiene la propiedad compress_after (como {"hypertable_id": 14, "compress_after": 612000}) entonces debe reconstruir la tabla.
Asegúrese de que el servidor Zabbix sea al menos la versión 7.0.1rc2 (o posterior); de lo contrario, volverá a establecer la política de compresión incorrecta. Además, detenga el servidor Zabbix antes de ejecutar el script y confirme que auditlog pertenece al usuario zabbix.
La forma más sencilla de reconstruir la tabla auditlog es:
CREATE TABLE auditlog_tmp (
LIKE auditlog INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES
);
SELECT create_hypertable('auditlog_tmp', 'auditid', chunk_time_interval => 604800,
time_partitioning_func => 'cuid_timestamp', migrate_data => true, if_not_exists => true);
WITH moved_rows AS (
DELETE FROM auditlog
RETURNING *
)
INSERT INTO auditlog_tmp
SELECT * FROM moved_rows;
DROP TABLE auditlog;
ALTER TABLE auditlog_tmp RENAME TO auditlog;Consulte también la documentación de TimescaleDB para obtener formas más optimizadas de migrar datos.
Dado que la marca de tiempo requerida para la partición se extrae del campo auditid con una función personalizada, los procedimientos auxiliares utilizados para la migración de datos desde timescaledb-extras no funcionarán.
Usar pg_restore para restaurar una copia de seguridad de PostgreSQL o TimescaleDB creada en Zabbix 7.0.0-7.0.4 resultará en un error de función base36_decode faltante, lo que provocará que la restauración falle:
ERROR: function base36_decode(text) does not exist
LINE 1: CAST(base36_decode(substring(cuid FROM 2 FOR 8))/1000 AS int...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.Este error ocurre al restaurar una copia de seguridad creada con pg_dump.
Para solucionar este problema, reemplace la función cuid_timestamp en su base de datos Zabbix antes de crear la copia de seguridad (se recomienda detener PostgreSQL/TimescaleDB antes de ejecutar el script):
CREATE OR REPLACE FUNCTION cuid_timestamp(cuid varchar(25)) RETURNS integer AS $$
DECLARE
base36 varchar;
a char[];
ret bigint;
i int;
val int;
chars varchar;
BEGIN
base36 := substring(cuid FROM 2 FOR 8);
chars := '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ';
FOR i IN REVERSE char_length(base36)..1 LOOP
a := a || substring(upper(base36) FROM i FOR 1)::char;
END LOOP;
i := 0;
ret := 0;
WHILE i < (array_length(a, 1)) LOOP
val := position(a[i + 1] IN chars) - 1;
ret := ret + (val * (36 ^ i));
i := i + 1;
END LOOP;
RETURN CAST(ret/1000 AS integer);
END;
$$ LANGUAGE 'plpgsql' IMMUTABLE;
DROP FUNCTION IF EXISTS base36_decode(character varying);Consulte también ZBX-24955 (para obtener detalles adicionales sobre el error) y la documentación de TimescaleDB (para opciones adicionales de copia de seguridad y restauración).
La documentación de Microsoft indica que los sistemas con menos de 64 procesadores lógicos siempre tienen un único grupo de procesadores, el Grupo 0. Sin embargo, los usuarios de Zabbix han informado de un error poco común ZBX-20260, cuando existen dos grupos de procesadores en sistemas con 64 o menos procesadores lógicos. Esto resultaba en que los contadores de rendimiento "(n)" solo estaban disponibles para uno de los dos grupos de procesadores. La causa raíz real de este error no se conoce. Sin embargo, un caso similar fue descrito en stackoverflow.com, y la causa raíz allí estaba en la interoperabilidad entre la BIOS y Windows.
Los filtros (por ejemplo, en Recopilación de datos > Mantenimiento) pueden no funcionar correctamente cuando se aplican a entidades que contienen ciertos caracteres Unicode (por ejemplo, ȼ, ɇ). Este problema surge debido a cómo la intercalación predeterminada utf8mb4_bin para bases de datos MySQL o MariaDB maneja la ordenación y comparación de caracteres Unicode.
Para abordar esta limitación, los usuarios pueden cambiar la intercalación de las columnas de la base de datos a alternativas como utf8mb4_0900_bin, utf8mb4_0900_ai_ci o utf8mb4_unicode_520_ci. Sin embargo, tenga en cuenta que cambiar la intercalación puede causar un comportamiento inesperado en el manejo de espacios vacíos, así como en la ordenación y filtrado de otros caracteres.
Para obtener más información sobre cómo cambiar intercalaciones, consulte la documentación de MySQL o la documentación de MariaDB. Para obtener detalles sobre las diferencias de intercalación, consulte Conjuntos de caracteres Unicode en la documentación de MySQL.
La información de los grupos de hosts anidados se muestra incorrectamente en los mapas, por ejemplo:
En la versión 7.0.7, el servidor Zabbix se bloquea al procesar anulaciones de reglas de descubrimiento de bajo nivel (overrides). Como solución temporal, desactive las reglas LLD que contengan anulaciones. El problema se ha solucionado en Zabbix 7.0.8rc2.
En la versión 7.0.14, el gestor de preprocesamiento de Zabbix puede causar una alta utilización de la CPU cuando se reciben múltiples valores para un solo ítem a la vez (como durante la monitorización de registros) y se configura más de un trabajador de preprocesamiento. Como solución temporal, establezca el parámetro de configuración StartPreprocessors en el servidor/proxy en 1. El problema ha sido corregido en Zabbix 7.0.15.
Las funciones de macro no funcionan en los parámetros de ítems de script ni en los parámetros de script de ítems de navegador. Corregido en Zabbix 7.0.7.
Acceder a la interfaz web de Zabbix con un rol distinto a Super Admin puede resultar en el mensaje: "Se produjo un error del sistema. Por favor, contacte al administrador de Zabbix.". Este problema afecta a las instalaciones que utilizan versiones de MariaDB desde la 10.5.1 hasta la 10.5.9.
Para evitar este problema, actualice MariaDB a una versión posterior a la 10.5.9. Para más detalles, consulte ZBX-25746.
Si sospecha que su instalación de Zabbix está utilizando demasiada memoria, puede usar la función de perfilado de memoria de tcmalloc para investigar el consumo de memoria del servidor/proxy de Zabbix.
1. Al instalar Zabbix desde las fuentes, configure las siguientes banderas adicionales:
La bandera -std=gnu99 es necesaria para compilar el servidor, proxy o agente de Zabbix. La bandera -g agrega información de depuración adicional, mientras que -O0 desactiva las optimizaciones, que pueden interferir con el perfilado de tcmalloc.
2. Establezca las siguientes variables de entorno antes de iniciar el servidor de Zabbix. Estas variables indican a tcmalloc cómo rastrear e informar el uso de memoria:
LD_PRELOAD="/usr/lib/aarch64-linux-gnu/libtcmalloc.so" \
HEAPPROFILE=./heap_profile \
HEAP_PROFILE_ALLOCATION_INTERVAL=0 \
HEAP_PROFILE_INUSE_INTERVAL=4294967296 \
HEAPPROFILESIGNAL=5 \
MALLOCSTATS=1 \
./sbin/zabbix_server -f -c /etc/zabbix/zabbix_server.conf3. Genere un volcado de perfil enviando la señal 5 al proceso objetivo. Reemplace 1234 por el ID real del proceso (PID):
4. Imprima el perfil generado:
pprof-symbolize -text ./sbin/zabbix_server ./heap_profile.0001.heap
Using local file ./sbin/zabbix_server.
Using local file ./heap_profile.0001.heap.
Total: 1078.1 MB
1076.8 99.9% 99.9% 1076.8 99.9% zbx_malloc2
1.0 0.1% 100.0% 1.0 0.1% __GI___strdup
0.2 0.0% 100.0% 0.2 0.0% CRYPTO_zalloc@@OPENSSL_3.0.0
0.1 0.0% 100.0% 0.1 0.0% OPENSSL_LH_insert@@OPENSSL_3.0.0
0.0 0.0% 100.0% 0.0 0.0% zbx_realloc2
0.0 0.0% 100.0% 0.1 0.0% PKCS7_decrypt@@OPENSSL_3.0.0
0.0 0.0% 100.0% 0.0 0.0% find_best_tree_node
0.0 0.0% 100.0% 0.0 0.0% CRYPTO_strndup@@OPENSSL_3.0.0
...
0.0 0.0% 100.0% 0.0 0.0% preprocessing_flush_value
0.0 0.0% 100.0% 1074.0 99.6% preprocessor_add_requestEn este ejemplo, zbx_malloc2 es responsable de casi todas las asignaciones de memoria.
Consulte también:
-std=gnu99, -g, -O0, etc.).Al utilizar la replicación de grupo de MySQL 8.0 en modo multi‐primario, puede encontrar un error durante la confirmación de transacciones similar al siguiente:
1531697:20250128:064734.697 query [txnlev:1] [update alerts set status=1,retries=0,error='' where alertid=154618;
1531697:20250128:064734.713 query [txnlev:1] [commit;]
1531697:20250128:064734.753 [Z3005] query failed: [3101] Plugin instructed the server to rollback the current transaction. [commit;]Este error parece ser provocado por problemas con operaciones de reversión que involucran restricciones de clave externa.
Consulte también: