- Problemi noti
- Aggiornamento
- Template
- Installazione accidentale dei pacchetti Zabbix di EPEL
- Pacchetti Zabbix per RHEL negli ambienti Red Hat UBI
- Chiave di firma scaduta per i pacchetti RHEL
- Timescale DB: utilizzo elevato della memoria con un numero elevato di partizioni
- Timescale DB 2.5.0: il criterio di compressione può non riuscire sulle tabelle che contengono interi
- Connessione TLS al database con MariaDB
- Possibili deadlock con MySQL/MariaDB
- Correlazione globale degli eventi
- NetBSD 8.0 e versioni successive
- Limitazioni delle espressioni regolari in Zabbix agent 2
- Controlli IPMI
- IPMI — host non attendibili possono mandare in crash OpenIPMI
- Controlli SSH
- Controlli ODBC
- Parametro del metodo di richiesta errato negli item
- Monitoraggio web e HTTP agent
- Controlli semplici
- Errori con l'esecuzione di fping in container rootless
- Controlli SNMP
- Picchi nei dati SNMP
- Trap SNMP
- Arresto anomalo del processo alerter in RHEL 7
- Aggiornamento di Zabbix agent 2 (6.0.5 o versioni precedenti)
- Cambio casuale delle impostazioni locali del frontend
- Grafici
- Monitoraggio dei file di log
- Query MySQL lente
- Impostazioni persistenti del filtro dai link
- Problema con l'indirizzo IPv6 nelle trap SNMPv3
- Indirizzo IP IPv6 lungo troncato nelle informazioni di accesso non riuscito
- Controlli di Zabbix agent su Windows
- Esportazione/importazione YAML
- Procedura guidata di configurazione su SUSE con NGINX e php-fpm
- Inoltro dell'header Authorization
- Chromium per il servizio web Zabbix su Ubuntu 20
- Codici di errore personalizzati MySQL
- Espressioni regolari non valide dopo il passaggio a PCRE2
- Errore del widget Geomap
- Preprocessing — le variabili globali non sono sicure
- Gruppi di processori in Windows
- Limiti del filtraggio con collations utf8mb4
- Accesso agli elementi dell'interfaccia utente con MariaDB 10.5.1–10.5.9
- Analisi dell'utilizzo eccessivo della memoria con tcmalloc
- Replica di gruppo MySQL 8.0 in modalità multi-primary
Problemi noti
Vedi anche: Problemi di compilazione.
Aggiornamento
Impostazione della modalità SQL per un aggiornamento riuscito
L'impostazione sql_mode in MySQL/MariaDB deve avere la modalità "STRICT_TRANS_TABLES" impostata.
Se è assente, l'aggiornamento del database Zabbix non riuscirà (vedere anche ZBX-19435).
Aggiornamento con MariaDB 10.2.1 e versioni precedenti
L'aggiornamento di Zabbix potrebbe non riuscire se le tabelle del database sono state create con MariaDB 10.2.1 o versioni precedenti, perché in tali versioni il formato di riga predefinito è compact. Questo problema può essere risolto modificando il formato di riga in dynamic (vedere anche ZBX-17690).
Template
Compatibilità dei template in ambienti dual-stack (IPv4/IPv6)
Negli ambienti dual-stack (sistemi configurati per supportare sia IPv4 che IPv6), il nome host localhost viene generalmente risolto sia in indirizzi IPv4 che IPv6.
A causa della comune priorità assegnata a IPv6 rispetto a IPv4 da molti sistemi operativi e resolver DNS, i template di Zabbix potrebbero non funzionare correttamente se il servizio monitorato è configurato per ascoltare solo su IPv4.
I servizi che non sono configurati per ascoltare su indirizzi IPv6 possono diventare inaccessibili, causando errori di monitoraggio. Gli utenti potrebbero configurare correttamente l'accesso per IPv4 ma continuare a riscontrare problemi di connettività a causa del comportamento predefinito che privilegia IPv6.
Una soluzione alternativa consiste nell'assicurarsi che i servizi (Nginx, Apache, PostgreSQL, ecc.) siano configurati per ascoltare sia su indirizzi IPv4 che IPv6 e che al server/agent Zabbix sia consentito l'accesso tramite IPv6.
Inoltre, nei template e nelle configurazioni di Zabbix, utilizzare esplicitamente localhost invece di 127.0.0.1 per garantire la compatibilità sia con IPv4 che con IPv6.
Ad esempio, quando si monitora PostgreSQL con il template PostgreSQL by Zabbix agent 2, potrebbe essere necessario modificare il file pg_hba.conf per consentire le connessioni all'utente zbx_monitor.
Se l'ambiente dual-stack assegna priorità a IPv6 (il sistema risolve localhost in ::1) e si configura localhost ma si aggiunge solo una voce IPv4 (127.0.0.1/32), la connessione non riuscirà perché non esiste una voce IPv6 corrispondente.
Il seguente esempio di file pg_hba.conf garantisce che l'utente zbx_monitor possa connettersi a qualsiasi database dalla macchina locale utilizzando sia indirizzi IPv4 che IPv6 con diversi metodi di autenticazione:
# 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
Se necessario, è anche possibile utilizzare direttamente l'indirizzo IPv4 (127.0.0.1) quando si configura la macro del template PostgreSQL by Zabbix agent 2 per la stringa di connessione.
Installazione accidentale dei pacchetti Zabbix di EPEL
Se il repository EPEL è installato e abilitato, l'installazione dei pacchetti Zabbix potrebbe scaricare le versioni EPEL invece dei pacchetti Zabbix ufficiali. Per risolvere il problema:
1. Rimuovere eventuali pacchetti Zabbix installati da EPEL:
dnf remove zabbix-server-mysql
2. Escludere i pacchetti Zabbix da EPEL aggiungendo la seguente riga al file /etc/yum.repos.d/epel.repo:
[epel]
...
excludepkgs=zabbix*
3.\ Reinstallare il pacchetto ufficiale del server Zabbix:
dnf install zabbix-server-mysql
Durante l'installazione, i pacchetti Zabbix ufficiali includono la parola release nella loro stringa di versione (ad esempio, 7.0.0-release1.el8), distinguendosi così dai pacchetti EPEL.
Pacchetti Zabbix per RHEL negli ambienti Red Hat UBI
Quando si installa Zabbix dai pacchetti Red Hat Enterprise Linux negli ambienti Red Hat Universal Base Image, assicurarsi di avere accesso ai repository richiesti e alle dipendenze necessarie.
I pacchetti Zabbix dipendono dalle librerie libOpenIPMI.so e libOpenIPMIposix.so, che non sono fornite da alcun pacchetto nei repository predefiniti del gestore pacchetti abilitati sui sistemi UBI e ciò comporterà errori di installazione.
Le librerie libOpenIPMI.so e libOpenIPMIposix.so sono disponibili nel pacchetto OpenIPMI-libs, fornito dal repository redhat-#-for-<arch>-appstream-rpms.
L'accesso a questo repository è regolato dalle sottoscrizioni che, nel caso degli ambienti UBI, vengono propagate montando nel namespace del file system del container la configurazione del repository e le directory dei segreti dell'host RHEL.
Per ulteriori informazioni, vedere ZBX-24291.
Chiave di firma scaduta per i pacchetti RHEL
Durante l'aggiornamento di Zabbix su Red Hat Enterprise Linux o sulle sue derivate, potresti riscontrare un problema di chiave di firma scaduta per i pacchetti nel repository Zabbix. Quando una chiave di firma scade, i tentativi di verificare le firme dei pacchetti generano un errore che indica che il certificato o la chiave non sono più validi. Per esempio:
error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
1. Certificate 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 risolvere questi problemi, reinstalla manualmente l'ultima versione del pacchetto zabbix-release per la tua specifica variante di RHEL (sostituisci il link seguente con quello corretto dal repository Zabbix).
Per esempio, su RHEL 10, esegui:
rpm -Uvh https://repo.zabbix.com/zabbix/8.0/release/rhel/10/noarch/zabbix-release-latest.el10.noarch.rpm
Quindi aggiorna le informazioni del repository:
dnf update
Per ulteriori informazioni, vedi ZBX-24761.
Timescale DB: utilizzo elevato della memoria con un numero elevato di partizioni
Le versioni di PostgreSQL 9.6-12 utilizzano troppa memoria durante l'aggiornamento di tabelle con un numero elevato di partizioni.
Questo problema si manifesta quando Zabbix aggiorna i trend su sistemi con TimescaleDB se i trend sono suddivisi in chunk relativamente piccoli (ad esempio 1 giorno).
Ciò comporta la presenza di centinaia di chunk nelle tabelle dei trend con le impostazioni di housekeeping predefinite, una condizione in cui PostgreSQL rischia di esaurire la memoria.
Il problema è stato risolto a partire da Zabbix 5.0.1 per le nuove installazioni con TimescaleDB, ma se TimescaleDB è stato configurato con Zabbix prima di allora, consultare ZBX-16347 per le note sulla migrazione.
Timescale DB 2.5.0: il criterio di compressione può non riuscire sulle tabelle che contengono interi
Questo problema si manifesta quando viene utilizzato TimescaleDB 2.5.0/2.5.1.
È stato risolto a partire da TimescaleDB 2.5.2.
Per ulteriori informazioni, consultare TimescaleDB Issue #3773.
Connessione TLS al database con MariaDB
La connessione TLS al database non è supportata con l'opzione 'verify_ca' per il parameter DBTLSConnect se viene utilizzato MariaDB.
Possibili deadlock con MySQL/MariaDB
Quando si opera con un carico elevato e con più di un worker LLD coinvolto, è possibile incorrere in un deadlock causato da un errore di InnoDB relativo alla strategia di blocco delle righe (vedere bug upstream). L'errore è stato corretto in MySQL a partire dalla versione 8.0.29, ma non in MariaDB. Per maggiori dettagli, vedere ZBX-21506.
Correlazione globale degli eventi
Gli eventi potrebbero non essere correlati correttamente se l'intervallo di tempo tra il primo e il secondo evento è molto piccolo, cioè mezzo secondo o meno.
NetBSD 8.0 e versioni successive
Vari processi di Zabbix potrebbero arrestarsi in modo casuale all'avvio nelle versioni 8.X e 9.X di NetBSD.
Ciò è dovuto alla dimensione predefinita troppo ridotta dello stack (4 MB), che deve essere aumentata eseguendo:
ulimit -s 10240
Per ulteriori informazioni, consultare la segnalazione del problema correlata: ZBX-18275.
Limitazioni delle espressioni regolari in Zabbix agent 2
Zabbix agent 2 non supporta i lookahead e i lookbehind nelle espressioni regolari a causa delle limitazioni della libreria standard regexp di Go.
Controlli IPMI
I controlli IPMI non funzionano con il pacchetto standard della libreria OpenIPMI su Debian precedenti alla 9 (stretch) e Ubuntu precedenti alla 16.04 (xenial). Per risolvere il problema, ricompilare la libreria OpenIPMI con OpenSSL abilitato, come descritto in ZBX-6139.
IPMI — host non attendibili possono mandare in crash OpenIPMI
Esiste un bug nella libreria OpenIPMI utilizzata da Zabbix per il polling dei dati IPMI che può essere attivato da risposte appositamente predisposte provenienti da un dispositivo non attendibile.
Un dispositivo IPMI non attendibile può inviare dati appositamente predisposti che causano il crash della libreria OpenIPMI, il che a sua volta può causare la terminazione del processo Zabbix server che esegue il polling IPMI.
Controlli SSH
- Alcune distribuzioni Linux come Debian e Ubuntu non supportano le chiavi private cifrate (con passphrase) se la libreria libssh2 è installata dai pacchetti. Per maggiori dettagli, vedere ZBX-4850.
- Quando si utilizza libssh 0.9.x su alcune distribuzioni Linux con OpenSSH 8, i controlli SSH possono occasionalmente segnalare "Cannot read data from SSH server". Ciò è causato da un problema di libssh (rapporto più dettagliato). Si prevede che l'errore sia stato corretto con una release stabile di libssh 0.9.5. Per dettagli, vedere anche ZBX-17756.
- L'uso della pipe "|" nello script SSH può causare l'errore "Cannot read data from SSH server". In questo caso si consiglia di aggiornare la versione della libreria libssh. Per dettagli, vedere anche ZBX-21337.
Controlli ODBC
- Il driver MySQL unixODBC non dovrebbe essere utilizzato con Zabbix server o Zabbix proxy compilati con la libreria del connettore MariaDB e viceversa; se possibile, è inoltre preferibile evitare di usare lo stesso connettore come driver a causa di un bug upstream. Configurazione consigliata:
Connettore PostgreSQL, SQLite o Oracle → driver MariaDB o MySQL unixODBC Connettore MariaDB → driver MariaDB unixODBC Connettore MySQL → driver MySQL unixODBC
Per ulteriori informazioni e le soluzioni alternative disponibili, vedere ZBX-7665.
-
I dati XML interrogati da Microsoft SQL Server possono essere troncati in vari modi sui sistemi Linux e UNIX.
-
È stato osservato che l'utilizzo dei controlli ODBC per monitorare database Oracle usando varie versioni di Oracle Instant Client per Linux provoca l'arresto anomalo di Zabbix server.\ Vedere anche: ZBX-18402, ZBX-20803.
-
Se si utilizza il driver FreeTDS UnixODBC, è necessario anteporre un'istruzione 'SET NOCOUNT ON' a una query SQL (ad esempio,
SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....). In caso contrario, il database monitor item in Zabbix non riuscirà a recuperare le informazioni e verrà restituito l'errore "La query SQL ha restituito un risultato vuoto".
Per ulteriori informazioni, vedere ZBX-19917.
Parametro del metodo di richiesta errato negli item
Il parametro del metodo di richiesta, utilizzato solo nei controlli HTTP, potrebbe essere impostato in modo errato su '1', un valore non predefinito per tutti gli item come risultato di un aggiornamento da una versione di Zabbix precedente alla 4.0. Per i dettagli su come correggere questa situazione, vedere ZBX-19308.
Monitoraggio web e HTTP agent
Zabbix server presenta perdite di memoria su alcune distribuzioni Linux a causa di un bug upstream quando "SSL verify peer" è abilitato negli scenari web o in HTTP agent. Per ulteriori informazioni e per le soluzioni alternative disponibili, vedere ZBX-10486.
Controlli semplici
Esiste un bug nelle versioni di fping precedenti alla v3.10 che gestisce in modo errato i pacchetti di risposta echo duplicati.
Ciò può causare risultati inattesi per gli item icmpping, icmppingloss, icmppingsec.
Si consiglia di utilizzare la versione più recente di fping.
Per maggiori dettagli, vedere ZBX-11726.
Errori con l'esecuzione di fping in container rootless
Quando i container sono in esecuzione in modalità rootless o in un ambiente con restrizioni specifiche, durante l'esecuzione di controlli ICMP potresti riscontrare errori relativi all'esecuzione di fping, come fping: Operation not permitted oppure la perdita di tutti i pacchetti verso tutte le risorse.
Per risolvere questo problema, aggiungi --cap-add=net_raw ai comandi "docker run" o "podman run".
Inoltre, l'esecuzione di fping in ambienti non root può richiedere una modifica di sysctl, ad esempio:
sudo sysctl -w "net.ipv4.ping_group_range=0 1995"
dove "1995" è il GID di zabbix. Per maggiori dettagli, vedi ZBX-22833.
Controlli SNMP
Se viene utilizzato il sistema operativo OpenBSD, un bug di tipo use-after-free nella libreria Net-SNMP fino alla versione 5.7.3 può causare un arresto anomalo di Zabbix server se il parametro SourceIP è impostato nel file di configurazione di Zabbix server. Come soluzione alternativa, non impostare il parametro SourceIP. Lo stesso problema si applica anche a Linux, ma non causa l'interruzione del funzionamento di Zabbix server. Una patch locale per il pacchetto net-snmp su OpenBSD è stata applicata e verrà rilasciata con OpenBSD 6.3.
Picchi nei dati SNMP
Sono stati osservati picchi nei dati SNMP che potrebbero essere correlati a determinati fattori fisici, come sbalzi di tensione nella rete elettrica. Per maggiori dettagli, vedere ZBX-14318.
Trap SNMP
Il pacchetto "net-snmp-perl", necessario per le trap SNMP, è stato rimosso in RHEL 8.0-8.2; reintrodotto in RHEL 8.3.
Quindi, se si utilizza RHEL 8.0-8.2, la soluzione migliore è eseguire l'aggiornamento a RHEL 8.3.
Per ulteriori informazioni, consultare anche ZBX-17192.
Arresto anomalo del processo alerter in RHEL 7
Sono stati riscontrati casi di arresto anomalo di un processo alerter di Zabbix server in RHEL 7. Per i dettagli, vedere ZBX-10461.
Aggiornamento di Zabbix agent 2 (6.0.5 o versioni precedenti)
Durante l'aggiornamento di Zabbix agent 2 (versione 6.0.5 o precedente) dai pacchetti, potrebbe verificarsi un errore di conflitto dei file relativo ai plugin. Per risolvere l'errore, eseguire un backup della configurazione di agent 2 (se necessario), disinstallare agent 2 e installarlo nuovamente.
Sui sistemi basati su RHEL, eseguire:
dnf remove zabbix-agent2
dnf install zabbix-agent2
Sui sistemi basati su Debian, eseguire:
apt remove zabbix-agent2
apt install zabbix-agent2
Per ulteriori informazioni, vedere ZBX-23250.
Cambio casuale delle impostazioni locali del frontend
È stato osservato che le impostazioni locali del frontend possono cambiare senza una logica apparente, cioè alcune pagine (o parti di pagine) vengono visualizzate in una lingua, mentre altre pagine (o parti di pagine) in una lingua diversa. In genere il problema può comparire quando ci sono diversi utenti, alcuni dei quali usano una locale, mentre altri ne usano un'altra.
Una soluzione alternativa nota consiste nel disabilitare il multithreading in PHP e Apache.
Il problema è legato al modo in cui l'impostazione della locale funziona in PHP: le informazioni sulla locale vengono mantenute per processo, non per thread. Quindi, in un ambiente multithread, quando ci sono diversi progetti eseguiti dallo stesso processo Apache, è possibile che la locale venga modificata in un altro thread e che ciò cambi il modo in cui i dati possono essere elaborati nel thread di Zabbix.
Per ulteriori informazioni, vedere le segnalazioni di problema correlate:
- ZBX-10911 (Problema con il cambio casuale delle impostazioni locali del frontend)
- ZBX-16297 (Problema con l'elaborazione dei numeri nei grafici che utilizzano la funzione
bcdivdelle funzioni BC Math)
Grafici
Problemi con i grafici (classici)
Se riscontri problemi con i grafici classici, si consiglia di aggiornare la libreria GD (libgd) alla versione 2.3.3-13 o successiva, e PHP alla versione 8.0.19, 8.1.33, 8.2.29, 8.3.25, 8.4.12 o successiva.
Ora legale
Le modifiche all'ora legale (DST) comportano irregolarità nella visualizzazione delle etichette dell'asse X (duplicazione della data, data mancante, ecc.).
Aggregazione sum
Quando si utilizza l'aggregazione sum in un grafico per un periodo inferiore a un'ora, i grafici mostrano valori errati (moltiplicati) quando i dati provengono dai trend.
Sovrapposizione del testo
Per alcune lingue del frontend (ad esempio il giapponese), i font locali possono causare la sovrapposizione del testo nella legenda del grafico. Per evitare questo problema, utilizzare la versione 2.3.0 (o successiva) dell'estensione PHP GD.
Monitoraggio dei file di log
Gli item log[] e logrt[] rileggono ripetutamente il file di log dall'inizio se il file system è pieno al 100% e il file di log viene aggiornato in append (vedere ZBX-10884 per ulteriori informazioni).
Query MySQL lente
Il server Zabbix genera query SELECT lente in caso di valori inesistenti per gli item.
Questo problema è noto nelle versioni MySQL 5.6/5.7 (per una discussione più estesa, vedere ZBX-10652) e, in casi specifici, può verificarsi anche nelle versioni MySQL successive.
Una soluzione alternativa consiste nel disabilitare l'ottimizzatore index_condition_pushdown o prefer_ordering_index in MySQL.
Si noti, tuttavia, che questa soluzione alternativa potrebbe non risolvere tutti i problemi relativi alle query lente.
Impostazioni persistenti del filtro dai link
Quando si apre un link a una pagina del frontend di Zabbix che contiene impostazioni del filtro, incluso il selettore dell’ora, il filtro viene salvato automaticamente nel database per l’utente, sostituendo il filtro precedentemente salvato e/o le impostazioni del selettore dell’ora per quella pagina. Queste impostazioni rimangono attive finché l’utente non le aggiorna o reimposta manualmente.
Problema con l'indirizzo IPv6 nelle trap SNMPv3
A causa di un bug di net-snmp, l'indirizzo IPv6 potrebbe non essere visualizzato correttamente quando si utilizza SNMPv3 nelle trap SNMP. Per maggiori dettagli e una possibile soluzione alternativa, vedere ZBX-14541.
Indirizzo IP IPv6 lungo troncato nelle informazioni di accesso non riuscito
Un messaggio di tentativo di accesso non riuscito visualizzerà solo i primi 39 caratteri di un indirizzo IP memorizzato, poiché questo è il limite di caratteri del campo nel database. Ciò significa che gli indirizzi IP IPv6 più lunghi di 39 caratteri verranno mostrati in modo incompleto.
Controlli di Zabbix agent su Windows
Le voci DNS inesistenti nel parametro Server del file di configurazione di Zabbix agent (zabbix_agentd.conf) possono aumentare il tempo di risposta di Zabbix agent su Windows.
Questo accade perché il demone di caching DNS di Windows non memorizza nella cache le risposte negative per gli indirizzi IPv4.
Tuttavia, per gli indirizzi IPv6 le risposte negative vengono memorizzate nella cache, quindi una possibile soluzione alternativa consiste nel disabilitare IPv4 sull'host.
Esportazione/importazione YAML
Esistono alcuni problemi noti con l'esportazione/importazione YAML:
- I messaggi di errore non sono traducibili;
- JSON valido con estensione di file .yaml a volte non può essere importato;
- Le date leggibili dall'uomo non racchiuse tra virgolette vengono convertite automaticamente in timestamp Unix.
Procedura guidata di configurazione su SUSE con NGINX e php-fpm
La procedura guidata di configurazione del frontend non riesce a salvare il file di configurazione su SUSE con NGINX + php-fpm.
Ciò è causato da un'impostazione nell'unità /usr/lib/systemd/system/php-fpm.service, che impedisce a Zabbix di scrivere in /etc. (introdotta in PHP 7.4).
Sono disponibili due soluzioni alternative:
- Impostare l'opzione ProtectSystem su 'true' invece di 'full' nell'unità systemd di php-fpm.
- Salvare manualmente il file /etc/zabbix/web/zabbix.conf.php.
Inoltro dell'header Authorization
In alcuni casi, Apache o NGINX possono impedire che l'header Authorization nelle richieste API raggiunga Zabbix. Questo può causare problemi di autenticazione quando si utilizza la API di Zabbix o servizi di single sign-on (SSO), come SAML con Okta.
Per risolvere questo problema, aggiorna la configurazione del tuo web server.
Per Apache, se lo stai utilizzando come reverse proxy (configurazione non CGI), aggiungi la seguente direttiva a /etc/httpd/conf/httpd.conf (sui sistemi basati su RHEL) o /etc/apache2/apache2.conf (su Debian/Ubuntu):
SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
Se Apache esegue direttamente gli script per gestire le richieste (ad esempio, utilizzando mod_cgi), aggiungi invece la seguente direttiva:
CGIPassAuth On
Al contrario, NGINX gestisce automaticamente l'header Authorization.
Tuttavia, se NGINX agisce come reverse proxy, puoi inoltrare esplicitamente l'header Authorization aggiungendo le seguenti direttive a /etc/nginx/nginx.conf (per la posizione del tuo frontend Zabbix):
...
location / {
...
proxy_set_header Authorization $http_authorization;
proxy_pass http://backend_server;
...
}
Dopo aver aggiornato la configurazione, riavvia il tuo web server.
Per maggiori dettagli, vedi:
- ZBX-22952
- Apache 2.4 + PHP-FPM and Authorization headers
- Direttive SetEnvIfNoCase e CGIPassAuth
- NGINX Reverse Proxy
Chromium per il servizio web Zabbix su Ubuntu 20
Sebbene nella maggior parte dei casi il servizio web Zabbix possa essere eseguito con Chromium, su Ubuntu 20.04 l'uso di Chromium provoca il seguente errore:
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.
Questo errore si verifica perché /var/lib/zabbix viene utilizzata come directory home dell'utente 'zabbix'.
Codici di errore personalizzati MySQL
Quando Zabbix rileva che il database di backend non è accessibile, invia una notifica e continua a tentare la connessione. Per alcuni motori di database, vengono riconosciuti codici di errore specifici. In MySQL, questi codici di errore riconosciuti includono:
- CR_CONN_HOST_ERROR
- CR_SERVER_GONE_ERROR
- CR_CONNECTION_ERROR
- CR_SERVER_LOST
- CR_UNKNOWN_HOST
- ER_SERVER_SHUTDOWN
- ER_ACCESS_DENIED_ERROR
- ER_ILLEGAL_GRANT_FOR_TABLE
- ER_TABLEACCESS_DENIED_ERROR
- ER_UNKNOWN_ERROR
Inoltre, quando si utilizza Zabbix con un'installazione MySQL su Azure, nei log di Zabbix può comparire il messaggio di errore generico [9002] Some errors occurred. Questo messaggio viene inviato dal database al server o al proxy Zabbix. Per determinare la causa dell'errore, consultare i log di Azure.
Espressioni regolari non valide dopo il passaggio a PCRE2
In Zabbix 6.0 è stato aggiunto il supporto per PCRE2.
Anche se PCRE è ancora supportato, i pacchetti di installazione di Zabbix per RHEL 7 e versioni successive, SLES (tutte le versioni), Debian 9 e versioni successive, Ubuntu 16.04 e versioni successive sono stati aggiornati per utilizzare PCRE2.
Pur offrendo numerosi vantaggi, il passaggio a PCRE2 può causare l'invalidità di alcuni pattern regexp PCRE esistenti o un comportamento differente.
In particolare, questo riguarda il pattern \^[\w-\.].
Per rendere nuovamente valida questa regexp senza alterarne la semantica, modificare l'espressione in \^[-\w\.] .
Ciò accade perché PCRE2 tratta il trattino come un delimitatore, creando un intervallo all'interno di una classe di caratteri.
Errore del widget Geomap
Le mappe nel widget Geomap potrebbero non caricarsi correttamente se è stato eseguito l'aggiornamento da una versione precedente di Zabbix con NGINX e durante l'aggiornamento non è stato adottato il nuovo file di configurazione NGINX.
Per risolvere il problema, è possibile scartare il vecchio file di configurazione, utilizzare il file di configurazione del pacchetto della versione corrente e riconfigurarlo come descritto nelle istruzioni di download, nella sezione e. Configure PHP for Zabbix frontend.
In alternativa, è possibile modificare manualmente un file di configurazione NGINX esistente (in genere, /etc/zabbix/nginx.conf). Per farlo, aprire il file e individuare il seguente blocco:
location ~ /(api\/|conf[^\.]|include|locale|vendor) {
deny all;
return 404;
}
Quindi, sostituire questo blocco con:
location ~ /(api\/|conf[^\.]|include|locale) {
deny all;
return 404;
}
location /vendor {
deny all;
return 404;
}
Preprocessing — le variabili globali non sono sicure
Il codice JavaScript di preprocessing viene eseguito per ogni richiesta, ma le assegnazioni a identificatori non dichiarati (ad esempio secret = value) creano variabili globali implicite che possono persistere oltre l'esecuzione corrente.
Memorizzare dati sensibili (token, password, ecc.) in variabili globali implicite aumenta il rischio di esposizione accidentale o di riutilizzo da parte di successive esecuzioni del preprocessing o di altre integrazioni eseguite nello stesso ambiente.
Non fare affidamento sulle variabili globali implicite.
Dichiara sempre le variabili con var o const ed evita di collegare segreti a oggetti globali (ad esempio globalThis o window).
Non esiste alcun modo supportato per sovrascrivere gli oggetti globali integrati dall'interno del preprocessing.
Esempio sicuro:
var apiToken = payload.token;
var count = 1;
return JSON.stringify({ token: apiToken, calls: count });
Gruppi di processori in Windows
La documentazione Microsoft afferma che i sistemi con meno di 64 processori logici hanno sempre un solo gruppo di processori, il Gruppo 0. Tuttavia, gli utenti di Zabbix hanno segnalato un raro bug ZBX-20260, in cui sono presenti due gruppi di processori su sistemi con 64 o meno processori logici. Questo ha comportato la presenza dei contatori delle prestazioni "\Processor(n)" solo per uno dei due gruppi di processori. La causa principale effettiva di questo bug non è nota. Tuttavia, un caso simile è stato descritto su stackoverflow.com, e in quel caso la causa principale era nell'interazione tra BIOS e Windows.
Limiti del filtraggio con collations utf8mb4
I filtri (ad esempio, in Raccolta dati > Manutenzione) potrebbero non funzionare correttamente quando vengono applicati a entità che contengono determinati caratteri Unicode (ad esempio, ȼ, ɇ). Questo problema è dovuto al modo in cui la collation predefinita utf8mb4_bin per i database MySQL o MariaDB gestisce l'ordinamento e il confronto dei caratteri Unicode.
Per risolvere questa limitazione, gli utenti possono modificare la collation delle colonne del database scegliendo alternative come utf8mb4_0900_bin, utf8mb4_0900_ai_ci o utf8mb4_unicode_520_ci. Si noti, tuttavia, che la modifica della collation può causare comportamenti imprevisti nella gestione degli spazi vuoti, nonché nell'ordinamento e nel filtraggio di altri caratteri.
Per ulteriori informazioni sulla modifica delle collations, vedere la documentazione MySQL o la documentazione MariaDB. Per i dettagli sulle differenze tra collations, vedere Unicode Character Sets nella documentazione MySQL.
Accesso agli elementi dell'interfaccia utente con MariaDB 10.5.1–10.5.9
L'accesso al frontend web di Zabbix con un ruolo diverso da Super Admin può comportare la visualizzazione del messaggio: "Si è verificato un errore di sistema. Contattare l'amministratore Zabbix.". Questo problema interessa le installazioni che utilizzano versioni di MariaDB dalla 10.5.1 alla 10.5.9.
Per evitare questo problema, aggiornare MariaDB a una versione successiva alla 10.5.9. Per maggiori dettagli, vedere ZBX-25746.
Analisi dell'utilizzo eccessivo della memoria con tcmalloc
Se sospetti che la tua installazione di Zabbix stia utilizzando troppa memoria, puoi usare la funzionalità di profiling della memoria di tcmalloc per analizzare il consumo di memoria del server/proxy Zabbix.
1. Durante l'installazione di Zabbix dai sorgenti, configura i flag aggiuntivi:
export CFLAGS="-std=gnu99 -g -O0"
Il flag -std=gnu99 è richiesto per compilare Zabbix server, Zabbix proxy o Zabbix agent.
Il flag -g aggiunge informazioni di debug aggiuntive, mentre -O0 disabilita le ottimizzazioni, che possono interferire con il profiling di tcmalloc.
2. Imposta le seguenti variabili d'ambiente prima di avviare Zabbix server. Queste variabili indicano a tcmalloc come tracciare e riportare l'utilizzo della 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.conf
3. Attiva un dump del profilo inviando il segnale 5 al processo di destinazione. Sostituisci 1234 con l'ID di processo (PID) effettivo:
kill -5 1234
4. Stampa il profilo generato:
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_request
In questo esempio, zbx_malloc2 è responsabile di quasi tutte le allocazioni di memoria.
Vedi anche:
- ZBX-25050 e ZBX-25584 per le segnalazioni di problema correlate.
- GCC Option Summary sulle opzioni di compilazione (
-std=gnu99,-g,-O0, ecc.). - Documentazione di Gperftools Heap Profiler sulle variabili d'ambiente per il profiling di tcmalloc.
Replica di gruppo MySQL 8.0 in modalità multi-primary
Quando si utilizza la Replica di gruppo MySQL 8.0 in modalità multi-primary, è possibile riscontrare un errore durante i commit delle transazioni simile al seguente:
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;]
Questo errore sembra essere causato da problemi con le operazioni di rollback che coinvolgono vincoli di chiave esterna.
Vedere anche:
- ZBX-26060 per la segnalazione del problema correlato.
- MySQL Bug #96758 "Rollbacks with Foreign Keys on single node" per il problema upstream.