problema di improvviso picco della CPU se si utilizza il plugin MySQL di Zabbix agent 2 (vedere ZBX-27156)
grafico per gli item di Zabbix active agent che mostra un avviso "Undefined array key" a causa di un errore di indice non definito (vedere ZBX-27153)

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 negli ambienti dual-stack (IPv4/IPv6)

Negli ambienti dual-stack (sistemi configurati per supportare sia IPv4 sia IPv6), il nome host localhost in genere si risolve sia in indirizzi IPv4 sia in indirizzi 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 non 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 nel verificare che i servizi (Nginx, Apache, PostgreSQL, ecc.) siano configurati per ascoltare sia sugli indirizzi IPv4 sia su quelli IPv6, e che a server/agent di Zabbix sia consentito l'accesso tramite IPv6. Inoltre, nei template e nelle configurazioni di Zabbix, usare esplicitamente localhost invece di 127.0.0.1 per garantire la compatibilità con IPv4 e 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 per l'utente zbx_monitor. Se l'ambiente dual-stack dà 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 fallirà 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 usando sia indirizzi IPv4 sia IPv6 con metodi di autenticazione diversi:

# 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 usare direttamente l'indirizzo IPv4 (127.0.0.1) quando si configura il 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 in ambienti Red Hat UBI

Quando si installa Zabbix dai pacchetti di Red Hat Enterprise Linux in ambienti Red Hat Universal Base Image, assicurarsi di avere accesso ai repository e alle dipendenze richiesti. I pacchetti Zabbix dipendono dalle librerie libOpenIPMI.so e libOpenIPMIposix.so, che non sono fornite da alcun pacchetto nei repository del gestore pacchetti predefiniti abilitati sui sistemi UBI e causeranno 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 è gestito tramite sottoscrizioni che, nel caso degli ambienti UBI, vengono propagate montando nel namespace del file system del container le directory di configurazione dei repository e dei secret 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 genereranno un errore che indica che il certificato o la chiave non sono più validi. Ad 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 il pacchetto zabbix-release più recente per la tua specifica variante di RHEL (sostituisci il link seguente con quello corretto dal repository Zabbix).

Ad esempio, su RHEL 9, esegui:

rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpm

Quindi, aggiorna le informazioni del repository:

dnf update

Per ulteriori informazioni, vedi ZBX-24761.

Connessione TLS al database con MariaDB

La connessione TLS al database non è supportata con l'opzione 'verify_ca' per il parametro 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.

Intervallo del tipo di dato numerico (float) con PostgreSQL 11 e versioni precedenti

Le versioni di PostgreSQL 11 e precedenti supportano solo un intervallo di valori in virgola mobile di circa -1.34E-154 a 1.34E+154.

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 causare il crash di OpenIPMI

Esiste un bug nella libreria OpenIPMI utilizzata da Zabbix per il polling dei dati IPMI che può essere attivato da risposte appositamente create provenienti da un dispositivo non attendibile.
Un dispositivo IPMI non attendibile può inviare dati manipolati che causano il crash della libreria OpenIPMI, il che a sua volta può causare la terminazione del processo del server Zabbix 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 usato con Zabbix server o Zabbix proxy compilati contro la libreria 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

Vedere ZBX-7665 per ulteriori informazioni e workaround disponibili.
I dati XML interrogati da Microsoft SQL Server possono essere troncati in vari modi su sistemi Linux e UNIX.
È stato osservato che l'uso dei controlli ODBC per monitorare database Oracle tramite varie versioni di Oracle Instant Client per Linux causa il crash 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, l'item di monitoraggio del database in Zabbix non riuscirà a recuperare le informazioni e restituirà l'errore "SQL query returned empty result".
Vedere ZBX-19917 per ulteriori informazioni.

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 bcdiv delle 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.

Sincronizzazione lenta della configurazione con Oracle

La sincronizzazione della configurazione può essere lenta nelle installazioni Zabbix con database Oracle che hanno un numero elevato di item e di fasi di preprocessing degli item. Ciò è causato dalla velocità del motore del database Oracle nell'elaborazione dei campi di tipo nclob.

Per migliorare le prestazioni, è possibile convertire i tipi di campo da nclob a nvarchar2 applicando manualmente la patch del database items_nvarchar_prepare.sql. Si noti che questa conversione ridurrà il limite massimo della dimensione del campo da 65535 byte a 4000 byte per i parametri di preprocessing degli item e per i parametri degli item, come Description, il campo Script dell'item Script, i campi Request body e Headers dell'item HTTP agent, e il campo SQL query dell'item Database monitor. Le query per determinare i nomi dei template che devono essere eliminati prima di applicare la patch sono fornite nella patch come commento. In alternativa, se MAX_STRING_SIZE è impostato, è possibile modificare nvarchar2(4000) in nvarchar2(32767) nelle query della patch per impostare il limite della dimensione del campo a 32767 byte.

Per una discussione più approfondita, vedere ZBX-22363.

Impostazioni del filtro persistenti dai link

Quando si apre un link a una pagina del frontend di Zabbix che contiene impostazioni del filtro, incluso il selettore temporale, il filtro viene automaticamente salvato nel database per l'utente, sostituendo il filtro e/o le impostazioni del selettore temporale precedentemente salvati 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 Zabbix API o servizi di single sign-on (SSO), come SAML con Okta.

Per risolvere il problema, aggiorna la configurazione del tuo web server.

Per Apache, se lo stai usando come reverse proxy (configurazione non CGI), aggiungi la seguente direttiva a /etc/httpd/conf/httpd.conf (nei sistemi basati su RHEL) oppure a /etc/apache2/apache2.conf (su Debian/Ubuntu):

SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1

Se Apache esegue direttamente gli script per gestire le richieste (ad esempio, usando 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 ulteriori dettagli, consulta:

ZBX-22952
Apache 2.4 + PHP-FPM and Authorization headers
Le 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.

Le mappe nel widget Geomap potrebbero non caricarsi correttamente se hai eseguito l'upgrade da una versione precedente di Zabbix con NGINX e non sei passato al nuovo file di configurazione NGINX durante l'aggiornamento.

Per risolvere il problema, puoi eliminare il vecchio file di configurazione, usare 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, puoi modificare manualmente un file di configurazione NGINX esistente (in genere, /etc/zabbix/nginx.conf). Per farlo, apri il file e individua il seguente blocco:

location ~ /(api\/|conf[^\.]|include|locale|vendor) {
        deny            all;
        return          404;
}

Quindi, sostituisci 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 JavaScript di preprocessing viene eseguito per ogni richiesta, ma le assegnazioni a identificatori non dichiarati (ad esempio secret = value) creano globali implicite che possono persistere oltre l'esecuzione corrente. Memorizzare dati sensibili (token, password, ecc.) in globali implicite aumenta il rischio di esposizione accidentale o di riutilizzo da parte di esecuzioni di preprocessing successive o di altre integrazioni che operano nello stesso ambiente.

Non fare affidamento sulle globali implicite. Dichiara sempre le variabili con var o const e evita di associare segreti a oggetti globali (ad esempio globalThis o window). Non esiste un 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 });

Crash del server con TimescaleDB dopo l'aggiornamento da 7.0

L'aggiornamento a Zabbix 7.0.1 (o versioni successive) da Zabbix 7.0.0 con TimescaleDB provoca il crash del server. Questo problema è causato da una soluzione temporanea a un problema del job di compressione nella tabella auditlog in Zabbix 7.0, che ha modificato in modo irreversibile la policy di compressione della tabella auditlog.

Per risolvere il problema, eseguire una ricostruzione manuale della tabella auditlog. La tabella auditlog difettosa può essere rilevata con questa query:

SELECT config FROM timescaledb_information.jobs WHERE application_name LIKE 'Compression%' AND hypertable_schema='public' AND hypertable_name='auditlog';.

Se restituisce un oggetto JSON contenente la proprietà compress_after (ad esempio {"hypertable_id": 14, "compress_after": 612000}) allora è necessario ricostruire la tabella.

Assicurarsi che Zabbix server sia almeno alla versione 7.0.1rc2 (o successiva); in caso contrario, imposterà di nuovo la policy di compressione errata. Inoltre, arrestare Zabbix server prima di eseguire lo script e verificare che auditlog sia di proprietà dell'utente zabbix.

Il modo più semplice per ricostruire la tabella auditlog è:

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;

Vedere anche la documentazione di TimescaleDB per modi più ottimizzati di migrare i dati.

Poiché il timestamp richiesto per la partizione viene estratto dal campo auditid con una funzione personalizzata, le procedure di supporto usate per la migrazione dei dati da timescaledb-extras non funzioneranno.

Errore di ripristino del database con PostgreSQL/TimescaleDB dopo l'aggiornamento da 7.0.0-7.0.4

L'uso di pg_restore per ripristinare un backup PostgreSQL o TimescaleDB creato in Zabbix 7.0.0-7.0.4 comporterà un errore relativo alla funzione base36_decode mancante, causando il fallimento del ripristino:

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.

Questo errore si verifica durante il ripristino di un backup creato con pg_dump.

Per risolvere il problema, sostituire la funzione cuid_timestamp nel database Zabbix prima di creare il backup (si consiglia di arrestare PostgreSQL/TimescaleDB prima di eseguire lo 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);

Vedi anche ZBX-24955 (per ulteriori dettagli sull'errore) e la documentazione di TimescaleDB (per ulteriori opzioni di backup e ripristino).

Gruppi di processori su Windows

La documentazione Microsoft indica che i sistemi con meno di 64 processori logici hanno sempre un singolo gruppo di processori, Group 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. Ciò ha comportato la presenza dei contatori di 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 la causa principale in quel caso era nell'interoperabilità tra BIOS e Windows.

Limiti del filtraggio con le collazioni utf8mb4

I filtri (ad esempio, in Raccolta dati > Manutenzione) potrebbero non funzionare correttamente quando vengono applicati a entità contenenti determinati caratteri Unicode (ad esempio, ȼ, ɇ). Questo problema deriva dal modo in cui la collazione 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 collazione delle colonne del database con alternative come utf8mb4_0900_bin, utf8mb4_0900_ai_ci o utf8mb4_unicode_520_ci. Si noti, tuttavia, che la modifica della collazione può causare un comportamento imprevisto nella gestione degli spazi vuoti, oltre che nell'ordinamento e nel filtraggio di altri caratteri.

Per ulteriori informazioni sulla modifica delle collazioni, vedere la documentazione MySQL o la documentazione MariaDB. Per i dettagli sulle differenze tra collazioni, vedere Unicode Character Sets nella documentazione MySQL.

Informazioni errate dai gruppi host nidificati nelle mappe

Le informazioni provenienti dai gruppi host nidificati vengono visualizzate in modo errato nelle mappe, ad esempio:

L'etichetta del gruppo host mostra il riepilogo del problema senza includere tutti gli host nei gruppi host nidificati;
La vista "Host group elements" non mostra un elemento mappa separato per ciascun host nei gruppi host nidificati;
L'etichetta della mappa mostra il riepilogo di tutti i problemi senza includere quelli nei gruppi host nidificati.

Override delle regole LLD danneggiate in 7.0.7

Nella versione 7.0.7, il server Zabbix si arresta in modo anomalo durante l'elaborazione delle override della regola di discovery a basso livello. Come soluzione temporanea, disabilitare le regole LLD che contengono override. Il problema è stato corretto in Zabbix 7.0.8rc2.

Problema di prestazioni del manager di preprocessing in Zabbix 7.0.14

Nella versione 7.0.14, il manager di preprocessing di Zabbix preprocessing può causare un elevato utilizzo della CPU quando vengono ricevuti contemporaneamente più valori per un singolo item (ad esempio durante il monitoraggio dei log) e sono configurati più worker di preprocessing. Come soluzione temporanea, impostare il parametro di configurazione StartPreprocessors di server/proxy su 1. Il problema è stato risolto in Zabbix 7.0.15.

Funzioni macro

Le funzioni macro non funzionano nei parametri degli item script e nei parametri degli script degli item browser. Corretto in Zabbix 7.0.7.

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ò causare il messaggio: "System error occurred. Please contact Zabbix administrator.". Questo problema interessa le installazioni che utilizzano versioni di MariaDB dalla 10.5.1 alla 10.5.9.

Per evitare questo problema, aggiorna MariaDB a una versione successiva alla 10.5.9. Per ulteriori dettagli, consulta ZBX-25746.

Profilazione dell'uso eccessivo di memoria con tcmalloc

Se sospetti che la tua installazione di Zabbix stia usando troppa memoria, puoi utilizzare la funzionalità di profilazione della memoria di tcmalloc per analizzare il consumo di memoria di Zabbix server/proxy.

1. Quando installi 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 la profilazione di tcmalloc.

2. Imposta le seguenti variabili d'ambiente prima di avviare Zabbix server. Queste variabili indicano a tcmalloc come tracciare e segnalare 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. Genera un dump del profilo inviando il segnale 5 al processo di destinazione. Sostituisci 1234 con l'ID reale del processo (PID):

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 i relativi report del problema.
GCC Option Summary per le opzioni di compilazione (-std=gnu99, -g, -O0, ecc.).
la documentazione di Gperftools Heap Profiler sulle variabili d'ambiente per la profilazione di tcmalloc.

MySQL 8.0 Group Replication in modalità multi-primary

Quando si utilizza MySQL 8.0 Group Replication in modalità multi-primary, durante il commit delle transazioni si può riscontrare un errore 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 nelle operazioni di rollback che coinvolgono vincoli di chiave esterna.