Veieu també: Problemes de compilació.
Zabbix 6.4.0rc1 (rc1 = Release Candidate 1) no admet la plantilla niuada (restaurada a 6.4.0rc2). Si heu actualitzat a Zabbix 6.4.0rc1, un pedaç de base de dades convertirà totes les plantilles heretades en una estructura de plantilles plana. Això vol dir que totes les entitats (elements, triggers, etc.) de les plantilles heretades es transferiran a la plantilla que contenia aquestes plantilles heretades. El suport per al niuat de plantilles s'ha restaurat completament a Zabbix 6.4.0rc2. Tanmateix, si ja heu actualitzat a Zabbix 6.4.0rc1, no es recuperarà l'estructura de plantilla existent anteriorment. :::
El zabbix_proxy amb les versions 8.0.0-8.0.17 de MySQL falla amb l'error d'"accés rebutjat" següent:
[Z3001] connection to database 'zabbix' failed: [1227] Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation
Això es deu al fet que MySQL 8.0.0 comença a aplicar permisos especials per establir variables de sessió. Tanmateix, a la versió 8.0.18, aquest comportament s'ha esborrat: A partir de MySQL 8.0.18, establir el valor de sessió d'aquesta variable del sistema ja no és una operació restringida.
La solució passa per concedir privilegis addicionals a l'usuari zabbix
:
Per les versions 8.0.14 a 8.0.17 de MySQL :
Per les versions 8.0.0 a 8.0.13 de MySQL :
Les versions 9.6-12 de PostgreSQL empren massa memòria quan actualitzen taules amb un gran nombre de particions (veieu l'informe del problema). Aquest problema es manifesta quan Zabbix actualitza les tendències als sistemes amb TimescaleDB si les tendències es divideixen en segments relativament petits (p. ex., 1 dia). Això fa que es vegin centenars de fragments a les taules de tendències amb la configuració de manteniment predeterminada, la condició en la qual és probable que PostgreSQL es quedi sense memòria.
El problema s'ha corregit des de Zabbix 5.0.1 per a instal·lacions noves amb TimescaleDB, però si TimescaleDB es va configurar amb Zabbix abans, consulteu ZBX-16347 per a notes de migració.
Aquest problema es manifesta quan s'empra TimescaleDB 2.5.0 / 2.5.1. S'ha resolt des de TimescaleDB 2.5.2.
Per obtindre més informació, consulteu TimescaleDB Issues #3773.
La configuració sql_mode
a MySQL/MariaDB ha de tindre el mode "STRICT_TRANS_TABLES" establert. Si és absent, l'actualització de la base de dades Zabbix fallarà (veieu també ZBX-19435).
L'actualització de Zabbix pot fallar si les taules de base de dades es van crear amb MariaDB 10.2.1 o versions anteriors, perquè en aquestes versions el format de fila predeterminat és compacte. Això es pot resoldre canviant el format de fila a dinàmic (veieu també ZBX-17690).
En entorns de doble pila (sistemes configurats per suportar tant IPv4 com IPv6), el nom d'equip "localhost" normalment es resol tant per adreces IPv4 com IPv6. A causa de la priorització comuna d'IPv6 sobre IPv4 per part de molts sistemes operatius i solucionadors de DNS, les plantilles Zabbix poden no funcionar correctament si el servei que s'està monitorant és configurat per escoltar només IPv4.
Els serveis que no són configurats per escoltar a les adreces IPv6 poden arribar a ser inabastables, la qual cosa comporta errors de monitoratge. Els usuaris poden configurar l'accés correctament per a IPv4, però encara s'enfronten a problemes de connectivitat degut al comportament predeterminat de prioritzar IPv6.
Una solució alternativa és assegurar-se que els serveis (Nginx, Apache, PostgreSQL, etc.) siguin configurats per escoltar tant adreces IPv4 com IPv6, i que el servidor/agent Zabbix tingui accés mitjançant IPv6. A més, a les plantilles i configuracions de Zabbix, empreu localhost
explícitament en lloc de 127.0.0.1
per garantir la compatibilitat amb IPv4 i IPv6.
Per exemple, quan es monitora PostgreSQL amb l'agent PostgreSQL by Zabbix 2, potser haureu d'editar el fitxer pg_hba.conf
per permetre connexions per a l'usuari zbx_monitor
. Si l'entorn de doble pila prioritza IPv6 (el sistema resol localhost a ::1
) i configureu localhost
però només afegiu una entrada IPv4 (127.0.0.1/32
), la connexió fallarà perquè no hi ha coincidències amb l'entrada IPv6.
El següent exemple de fitxer pg_hba.conf
garanteix que l'usuari zbx_monitor
es pugui connectar a qualsevol base de dades des de la màquina local mitjançant adreces IPv4 i IPv6 amb mètodes d'autenticació diferents:
# 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-256
Si cal, també podeu emprar l'adreça IPv4 (127.0.0.1
) directament quan configureu la macro de plantilla PostgreSQL by Zabbix agent 2 per a la cadena de connexió.
Amb el repositori EPEL instal·lat i habilitat, la instal·lació de Zabbix des dels paquets farà que s'instal·lin els paquets EPEL Zabbix en lloc dels paquets oficials de Zabbix.
En aquest cas, desinstal·leu els paquets Zabbix d'EPEL, és a dir:
Bloqueu els paquets Zabbix d'EPEL. Afegiu la línia següent al fitxer /etc/yum.conf
:
Torneu a instal·lar el servidor Zabbix:
Tingueu en compte que els paquets oficials de Zabbix tenen la paraula release
a la cadena de la versió:
Quan instal·leu Zabbix des de paquets de Red Hat Enterprise Linux en entorns Red Hat Universal Base Image, assegureu-vos l'accés als repositoris i dependències necessàries. Els paquets Zabbix depenen de les biblioteques libOpenIPMI.so
i libOpenIPMIposix.so
, que no són proporcionades per cap paquet als repositoris del gestor de paquets per defecte habilitats als sistemes UBI i provocaran errors d'instal·lació.
Les biblioteques libOpenIPMI.so
i libOpenIPMIposix.so
són disponibles al paquet OpenIPMI-libs
, que és proporcionat pel repositori redhat-#-for-<arch>-appstream-rpms
. L'accés a aquest dipòsit es soluciona mitjançant subscripcions, que, en el cas dels entorns UBI, es propaguen muntant la configuració del dipòsit i els directoris de secrets de l'equip RHEL a l'espai de noms del sistema de fitxers del contenidor.
Per obtindre més informació, veieu ZBX-24291.
Quan actualitzeu Zabbix a Red Hat Enterprise Linux, és possible que us trobeu amb un problema de clau de signatura caducada per als paquets al repositori Zabbix. Quan caduca una clau de signatura, els intents de verificar les signatures dels paquets donaran lloc a un error que indica que el certificat o la clau ja no són vàlids. Per exemple:
error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
1. Certificiate 19F2475308EFA7DD invalid: certificate is not alive
because: The primary key is not live
because: Expired on 2024-07-04T11:41:23Z
2. Key 19F2475308EFA7DD invalid: key is not alive
because: The primary key is not live
because: Expired on 2024-07-04T11:41:23Z
Per resoldre aquests problemes, torneu a instal·lar manualment el darrer paquet zabbix-release
per a la vostra variant específica de RHEL (substituïu l'enllaç següent per el correcte del repositori Zabbix).
Per exemple, a RHEL 9, executeu:
A continuació, actualitzeu la informació del repositori:
Per obtindre més informació, veieu ZBX-24761.
La connexió TLS a la base de dades no s'admet pas amb l'opció 'verify_ca' per al paràmeetre DBTLSConnect si s'empra MariaDB.
Quan s'executa amb una càrrega pesada i amb més d'un agent LLD implicat, és possible entrar en un bloqueig causat per un error d'InnoDB relacionat amb la política de bloqueig de filera (veieu l'error. mysql-server/commit/7037a0bdc83196755a3bf3e935cfb3c0127715d5)). L'error s'ha corregit a MySQL des de l'8.0.29, però no a MariaDB. Per obtindre més informació, consulteu ZBX-21506.
Els esdeveniments poden no ésser correlacionats correctament si l'interval de temps entre el primer i el segon esdeveniment és molt petit, és a dir, mig segon o menys.
PostgreSQL 11 i versions anteriors només admeten l'interval de valors de coma flotant al rang de -1.34E-154 a 1.34E+154.
Diversos processos Zabbix es poden bloquejar aleatòriament a l'inici a les versions 8.X i 9.X de NetBSD. Això es deu al fet que la mida de la pila per defecte és massa petita (4 Mo), i es pot d'augmentar executant:
Per obtindre més informació, consulteu l'informe del problema relacionat: ZBX-18275.
L'agent Zabbix 2 no admet els lookaheads i lookbacks a les expressions regulars degut a les limitacions estàndard de la biblioteca d'expressions regulars de Go.
Les comprovacions IPMI no funcionaran amb el paquet estàndard de la biblioteca OpenIPMI a Debian abans de la versió 9 (stretch) i Ubuntu anterior a la 16.04 (xenial). Per resoldre aquest problema, torneu a compilar la biblioteca OpenIPMI amb OpenSSL habilitat, tal com es mostra a ZBX-6139.
- Algunes distribucions de Linux com Debian i Ubuntu no admeten claus privades xifrades (amb mot de pas) si la biblioteca libssh2 és instal·lada des dels paquets. Consulteu [ZBX-4850](https://support.zabbix.com/browse/ZBX-4850) per obtindre més informació.
- Quan empreu libssh 0.9.x a CentOS 8 en algunes distribucions de Linux amb OpenSSH 8, les comprovacions SSH poden informar de tant en tant que "No es poden llegir les dades del servidor SSH". Això és causat per un [problema](https://gitlab.com/libssh/libssh-mirror/-/merge_requests/101) a libssh ([informe detallat](https://bugs.libssh.org/T231)) . L'error s'hauria d'haver corregit amb una versió estable de libssh 0.9.5. Consulteu també [ZBX-17756](https://support.zabbix.com/browse/ZBX-17756) per a més detalls.
- Emprar la pleca "|" a l'script SSH pot provocar un error "No es poden llegir les dades del servidor SSH". En aquest cas, es recomana actualitzar la versió de la biblioteca libssh. Consulteu també [ZBX-21337](https://support.zabbix.com/browse/ZBX-21337) per obtindre més detalls.
El controlador MySQL unixODBC no s'ha d'emprar amb el servidor Zabbix o el proxy Zabbix compilat amb la biblioteca de connectors MariaDB i viceversa, si és possible. També és millor evitar emprar el mateix connector que el controlador a causa d'un error. Configuració suggerida:
Connector PostgreSQL, SQLite o Oracle → Controlador unixODBC MariaDB o MySQL Connector MariaDB → Controlador MariaDB unixODBC Connector MySQL → Controlador MySQL unixODBC
Consulteu ZBX-7665 per obtindre més informació i solucions alternatives disponibles.
Les dades XML consultades des de Microsoft SQL Server es poden truncar de diferents maneres en sistemes Linux i UNIX.
S'ha observat que l'ús de comprovacions ODBC per monitorar les bases de dades Oracle emprant diferents versions d'Oracle Instant Client per a Linux fa que el servidor Zabbix es bloquegi. Veieu també ZBX-18402, ZBX-20803.
Si empreu el controlador FreeTDS UnixODBC, heu d'afegir una instrucció 'SET NOCOUNT ON' a una consulta SQL (per exemple, SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....
). En cas contrari, l'element de monitoratge de la base de dades a Zabbix no podrà recuperar la informació amb un error "La consulta SQL ha retornat un resultat buit". Consulteu ZBX-19917 per obtindre més informació.
El paràmetre del mètode de sol·petició, que només s'empra a les comprovacions HTTP, pot estar configurat incorrectament a "1", un valor no predeterminat per a tots els elements després d'una actualització d'una versió anterior a la versió 4.0 de Zabbix. Per obtindre més informació sobre com solucionar aquest problema, consulteu ZBX-19308.
El servidor Zabbix perd memòria en algunes distribucions de Linux a causa d'un error quan s'habilita "SSL verifica peer" en escenaris web o un agent HTTP. Consulteu ZBX-10486 per obtindre més informació i solucions alternatives disponibles.
Hi ha un error a les versions fping anteriors a la v3.10 que gestiona malament els paquets de reproducció d'eco duplicats. Això pot provocar resultats inesperats per als elements icmpping
, icmpping
, icmpping
, icmppingsec
. Es recomana emprar la darrera versió d'fping. Consulteu ZBX-11726 per obtindre més informació.
Quan els contenidors s'executen en mode sense arrel o en un entorn de restriccions específiques, és possible que us trobeu amb errors relacionats amb l'execució d'fping quan feu comprovacions ICMP, com ara "fping: operació no permesa" o es perdin tots els paquets de tots els recursos.
Per solucionar aquest problema, afegiu --cap-add=net_raw
a les ordres "docker run" o "podman run".
A més, l'execució d'fping en entorns no root pot menester modificacions de sysctl, és a dir:
on "1995" és el GID zabbix. Per obtindre més informació, consulteu ZBX-22833.
Si s'empra el sistema operatiu OpenBSD, un error a la biblioteca Net-SNMP, fins a la versió 5.7.3, pot provocar que el servidor Zabbix es bloquegi si el paràmetre SourceIP s'estableix al fitxer de configuració del servidor Zabbix. Per solucionar aquest problema, no configureu el paràmetre SourceIP. El mateix problema també s'aplica a Linux, però no impedeix que el servidor Zabbix funcioni. S'ha aplicat una correcció local per al paquet net-snmp a OpenBSD i es publicarà amb OpenBSD 6.3.
S'han observat pics en les dades SNMP que poden estar relacionats amb alguns factors físics com ara pics de tensió. Consulteu ZBX-14318 per obtindre més informació.
El paquet "net-snmp-perl", necessari per a les trampes SNMP, es va treure a RHEL 8.0-8.2; i s'ha afegit a RHEL 8.3.
Per tant, si empreu RHEL 8.0-8.2, la millor solució és actualitzar a RHEL 8.3.
Consulteu també ZBX-17192 per obtindre més informació.
S'han trobat bloquejos de les instàncies del procés d'alerta del servidor Zabbix a RHEL 7. Consulteu ZBX-10461 per obtindre més informació.
Quan actualitzeu l'agent Zabbix 2 (versió 6.0.5 o anterior) des dels paquets, es pot produir un error de conflicte de fitxer relacionat amb els connectors. Per solucionar l'error, feu una còpia de seguretat de la configuració de l'agent 2 (si cal), desinstal·leu l'agent 2 i instal·leu-lo de nou.
En sistemes basats en RHEL, executeu:
En sistemes basats en Debian, executeu:
Per obtindre més informació, veieu ZBX-23250.
S'ha observat que la configuració regional de la interfície web pot canviar sense lògica aparent, és a dir, algunes pàgines (o parts de pàgines) es mostren en un idioma mentre que altres pàgines (o parts de pàgines) es mostren en un idioma diferent. Normalment, el problema pot aparèixer quan hi ha diversos usuaris, alguns dels quals empren una configuració regional, mentre que altres n'empren una altra.
Una solució alternativa coneguda és desactivar el multithreading a PHP i Apache.
El problema és relacionat amb el funcionament de la configuració de localitzacions a PHP: la informació de la configuració regional es manté per procés, no per fil. Per tant, en un entorn multifils, quan s'executen diversos projectes pel mateix procés d'Apache, és possible que la configuració regional es canviï en un altre fil i això canviï la manera com es poden processar les dades al fil Zabbix.
Per obtindre més informació, consulteu els informes de problemes relacionats:
bcdiv
de les funcions BC Math)Si "opcache" és habilitat a la configuració de PHP 7.3, el frontal de Zabbix pot mostrar una pantalla en blanc a la primera càrrega. Aquest és un error registrat de PHP. Per solucionar aquest problema, configureu el paràmetre "opcache.optimization_level" a 0x7FFFBFDF
a la configuració de PHP (fitxer php.ini).
Els canvis a l'horari d'estiu (DST) causen irregularitats en mostrar les etiquetes de l'eix X (data doble, data que manca, etc.).
Quan s'empra la suma afegida a un gràfic durant un període inferior a una hora, els gràfics mostren valors incorrectes (multiplicats) quan les dades provenen de tendències.
Per a alguns idiomes d'interfície (per exemple, el japonès), els tipus de lletra locals poden provocar que el text es superposi a la llegenda del gràfic. Per evitar-ho, empreu la versió 2.3.0 (o posterior) de l'extensió PHP GD.
Els elements log[]
i logrt[]
reprodueixen repetidament el fitxer de registre des del principi si el sistema de fitxers és ple al 100% i el fitxer de registre és en mode d'adjuntar (veieu ZBX-10884 per obtindre més informació).
El servidor Zabbix genera consultes SELECT
lentes en cas de valors inexistents per als elements. Això es deu a un problema conegut a les versions de MySQL 5.6/5.7. Una solució alternativa és desactivar l'optimitzador d'index_condition_pushdown
o prefer_ordering_index
a MySQL. Per a una discussió en profunditat, veieu ZBX-10652.
De tota manera, això és una solució temporal i no corregirà pas tots els elements relatius a les consultes lentes.
La sincronització de la configuració pot esdevindre lenta a les instal·lacions de Zabbix 6.0 amb Oracle DB que tenen un gran nombre d'elements i passes de preprocessament d'elements. Això és degut als camps de tipus nclob que processen la velocitat del motor de base de dades Oracle.
Per millorar el rendiment, podeu convertir els tipus de camp de nclob a nvarchar2 aplicant manualment el pedaç de la base de dades items_nvarchar_prepare.sql. Tingueu en compte que aquesta conversió reduirà el límit màxim de mida del camp de 65535 a 4000 octets per als paràmetres de preprocessament d'elements i paràmetres d'element com ara Descripció, el camp de l'element d'script Script, camps de l'element de l'agent HTTP Cos de la petició i Capçaleres, camp de l'element del monitor de la base de dades Consulta SQL. Les consultes per determinar els noms de les plantilles que cal esborrar abans d'aplicar el pedaç es proporcionen al pedaç com a comentari. Alternativament, si s'estableix MAX_STRING_SIZE, podeu canviar nvarchar2(4000) a nvarchar2(32767) a les consultes de pedaços per establir el límit de mida del camp de 32767 octets.
Per a una discussió ampliada, vegeu ZBX-22363.
Es poden crear un gran nombre de sessions d'usuari obertes quan s'empren scripts personalitzats amb el mètode user.login
sense user.logout
després.
A causa d'un error net-snmp, és possible que l'adreça IPv6 no es mostri correctament quan s'empra SNMPv3 a les trampes SNMP. Per obtindre més detalls i una possible solució, veieu ZBX-14541.
Un missatge d'intent d'inici de sessió fallit només mostrarà els primers 39 caràcters d'una adreça IP emmagatzemada perquè aquest és el límit de caràcters al camp de la base de dades. Això significa que les adreces IP IPv6 de més de 39 caràcters es mostraran de manera incompleta.
Les entrades de DNS inexistents al paràmetre "Servidor" del fitxer de configuració de l'agent Zabbix (zabbix_agentd.conf) poden augmentar el temps de resposta de l'agent Zabbix a Windows. Això passa perquè el dimoni de memòria cau DNS de Windows no guarda a la memòria cau les respostes negatives per a adreces IPv4. Tanmateix, per a les adreces IPv6, les respostes negatives s'emmagatzemen a la memòria cau, de manera que una possible solució serà desactivar IPv4 a l'equip.
Hi ha problemes coneguts amb exportacions/importacions YAML:
L'assistent de configuració de la interfície no pot desar el fitxer de configuració a SUSE amb NGINX + php-fpm. Això és causat per una configuració a la unitat /usr/lib/systemd/system/php-fpm.service, que impedeix que Zabbix escrigui a /etc (afegit amb PHP 7.4).
Hi ha dues opcions per passar de llarg disponibles:
Tot i que en la majoria dels casos el servei web Zabbix pot funcionar amb Chromium, a Ubuntu 20.04 amb Chromium provoca el següent error:
No es poden recuperar les dades: no s'ha pogut iniciar Chrome:cmd_run.go:994:
AVÍS: no es pot crear el directori de dades d'usuari: no es pot crear
"/var/lib/zabbix/snap/chromium/1564": mkdir /var/lib/zabbix: permís denegat
Ho sentim, els directoris d'inici fora de /home actualment no són compatibles. Consulteu https://forum.snapcraft.io/t/11209 per obtindre més informació.
Aquest error es produeix perquè /var/lib/zabbix
s'empra com a directori inicial de l'usuari 'zabbix'.
Si Zabbix s'empra amb la instal·lació de MySQL a Azure, pot aparèixer un missatge d'error poc clar [9002] Alguns errors poden aparèixer als registres de Zabbix. Aquest text d'error genèric s'envia al servidor o proxy Zabbix per la base de dades. Per obtindre més informació sobre la causa de l'error, consulteu els registres d'Azure.
A Zabbix 6.0, es va afegir suport per a PCRE2. Tot i que PCRE encara és compatible, els paquets d'instal·lació de Zabbix per a RHEL 7 i posteriors, SLES (totes les versions), Debian 9 i posteriors, Ubuntu 16.04 i posteriors s'han actualitzat per emprar PCRE2. Tot i que ofereix molts avantatges, canviar a PCRE2 pot invalidar alguns patrons d'expressió regular PCRE existents o comportar-se de manera diferent. En particular, això afecta el patró ^[\w-\.]. Per tal que aquesta expressió regular torni a ser vàlida sense afectar la semàntica, substituïu l'expressió per ^[-\w\.]. Això es deu al fet que PCRE2 tracta el guió com un delimitador, creant un interval dins d'una classe de caràcters.
És possible que els mapes del giny Geomap no es carreguin correctament si heu actualitzat des d'una versió anterior de Zabbix amb NGINX i no heu canviat al nou fitxer de configuració d'NGINX durant l'actualització.
Per solucionar el problema, podeu descartar el fitxer de configuració antic, emprar el fitxer de configuració del paquet de la versió actual i tornar-lo a configurar tal com es descriu a les instruccions de descàrrega a la secció e. Configura PHP per a la interfície Zabbix.
Alternativament, podeu editar manualment un fitxer de configuració NGINX existent (normalment, /etc/zabbix/nginx.conf). Per fer-ho, obriu el fitxer i localitzeu el bloc següent:
Ara, canvieu aquest bloc amb:
location ~ /(api\/|conf[^\.]|include|locale) {
deny all;
return 404;
}
location /vendor {
deny all;
return 404;
}
A les versions 6.4.3 i anteriors de Zabbix, la rotació de registres (logrotate) només s'inclou als paquets per a zabbix-agent, zabbix-agent2 i zabbix-web-service, però s'ha d'instal·lar per separat per al servidor Zabbix i al proxy. La dependència logrotate s'ha afegit als paquets de servidor i proxy per a RHEL i SUSE a partir de Zabbix 6.4.4rc1.
Al fitxer ZIP de descàrrega de l'agent de Windows Zabbix hi manquen els fitxers zabbix_sender.h i zabbix_sender.lib a les versions 6.4.0-6.4.12, necessaris per a zabbix_sender.dll.
El servidor Zabbix 6.4.12 i el proxy Zabbix 6.4.12 no són compatibles amb altres versions de proxy/servidor. Si el servidor o el proxy són 6.4.12, tant el servidor com el proxy han d'ésser 6.4.12.
Aquest problema es soluciona a les versions 6.4.13 i posteriors. Tanmateix, encara que les versions següents són compatibles amb el servidor/proxy 6.4.11 (o posteriors), encara no són compatibles amb el servidor/proxy 6.4.12.
A mesura que les variables globals es comparteixen entre diferents crides de webhook, el codi següent farà que el comptador del valor de l'etiqueta augmenti gradualment:
try
{
aa = aa + 1;
}
catch(e)
{
aa = 0;
}
result = {
'tags': {
'endpoint': aa
}
};
return JSON.stringify(result);
Es recomana emprar variables locals en lloc de globals per assegurar-se que cada script funciona amb les seves pròpies dades i que no hi ha conflicte entre crides simultànies.