Un controllo degli aggiornamenti software viene ora aggiunto per impostazione predefinita alle nuove installazioni e a quelle esistenti - il frontend di Zabbix comunicherà con l'endpoint pubblico di Zabbix per verificare la disponibilità di aggiornamenti.

Le notizie sugli aggiornamenti software di Zabbix disponibili vengono visualizzate in Reports -> System information e, facoltativamente, nel widget System Information della dashboard.

È possibile disabilitare il controllo degli aggiornamenti software impostando AllowSoftwareUpdateCheck=0 nella configurazione del server.

Poller asincroni

Sono stati aggiunti nuovi processi poller in grado di eseguire più controlli contemporaneamente:

agent poller
http agent poller
snmp poller (per gli item walk[OID] e get[OID])

Questi poller sono asincroni: sono in grado di avviare nuovi controlli senza dover attendere una risposta, con una concorrenza configurabile fino a 1000 controlli simultanei.

I poller asincroni sono stati sviluppati perché, in confronto, i processi poller sincroni possono eseguire solo un controllo alla volta e trascorrono la maggior parte del tempo in attesa della risposta. Di conseguenza, l'efficienza può essere aumentata avviando nuovi controlli in parallelo mentre si attende la risposta di rete, ed è proprio ciò che fanno i nuovi poller.

È possibile avviare i poller asincroni per agent modificando il valore di StartAgentPollers - un nuovo parametro di server/proxy. I poller HTTP agent possono essere avviati modificando rispettivamente StartHTTPAgentPollers. I poller SNMP possono essere avviati modificando rispettivamente StartSNMPPollers.

La concorrenza massima per i poller asincroni (agent, HTTP agent e SNMP) è definita da MaxConcurrentChecksPerPoller.

Si noti che dopo l'aggiornamento tutti i controlli agent, HTTP agent e SNMP walk[OID] verranno spostati sui poller asincroni.

Come parte dello sviluppo, la funzionalità delle connessioni persistenti di cURL è stata aggiunta ai controlli HTTP agent.

Monitoraggio del browser

È stato aggiunto a Zabbix un nuovo tipo di item - Browser item - che consente il monitoraggio di siti web e applicazioni web complesse tramite un browser. Gli item Browser consentono l'esecuzione di codice JavaScript definito dall'utente per simulare azioni correlate al browser, come fare clic, inserire testo, navigare tra le pagine web, ecc.

Questo item raccoglie dati tramite HTTP/HTTPS e implementa parzialmente lo standard W3C WebDriver con Selenium Server o un semplice WebDriver (ad esempio, ChromeDriver) come endpoint di test.

Si noti che il supporto per gli item Browser è attualmente sperimentale.

Inoltre, questa funzionalità aggiunge il template Website by Browser e nuovi elementi all'esportazione/importazione della configurazione, ai file di configurazione di Zabbix server/proxy, ai timeout e all'utilità da riga di comando zabbix_js. Per ulteriori informazioni, vedere Note di aggiornamento alla 7.0.0.

Bilanciamento del carico dei proxy e alta disponibilità

Il bilanciamento del carico dei proxy è implementato introducendo i gruppi di proxy in Zabbix. I gruppi di proxy forniscono la distribuzione automatica degli host tra i proxy, il ribilanciamento del carico dei proxy e l'alta disponibilità: quando un proxy va offline, i suoi host vengono immediatamente distribuiti tra gli altri proxy del gruppo.

Per ulteriori informazioni, vedere bilanciamento del carico dei proxy e alta disponibilità.

Buffer di memoria del proxy

È stato sviluppato un buffer di memoria per il proxy di Zabbix. Il buffer di memoria consente di memorizzare nuovi dati (valori degli item, network discovery, autoregistrazione degli host) nel buffer e di caricarli su Zabbix server senza accedere al database.

Nelle installazioni precedenti a Zabbix 7.0, i dati raccolti venivano memorizzati nel database prima del caricamento su Zabbix server. Per queste installazioni, questo rimane il comportamento predefinito dopo l'aggiornamento.

Per prestazioni ottimizzate, si consiglia di configurare l'uso del buffer di memoria sul proxy. È possibile farlo modificando il valore di ProxyBufferMode da "disk" (impostazione predefinita hardcoded per le installazioni esistenti) a "hybrid" (consigliato) o "memory". È inoltre necessario impostare la dimensione del buffer di memoria (parametro ProxyMemoryBufferSize).

In modalità hybrid, il buffer è protetto dalla perdita di dati scaricando nel database i dati non inviati se il proxy viene arrestato, se il buffer è pieno o se i dati sono troppo vecchi. Quando tutti i valori sono stati scaricati nel database, il proxy torna a utilizzare il buffer di memoria.

In modalità memory, verrà utilizzato il buffer di memoria; tuttavia, non esiste alcuna protezione contro la perdita di dati. Se il proxy viene arrestato o la memoria viene sovraccaricata, i dati non inviati verranno eliminati.

La modalità hybrid (ProxyBufferMode=hybrid) viene applicata a tutte le nuove installazioni a partire da Zabbix 7.0.

Parametri aggiuntivi come ProxyMemoryBufferSize e ProxyMemoryBufferAge definiscono rispettivamente la dimensione del buffer di memoria e l'età massima dei dati nel buffer.

Nuovi item interni sono stati aggiunti per monitorare il buffer di memoria del proxy.

Provisioning JIT degli utenti

In precedenza, gli utenti provisionati erano limitati solo ai media creati durante il provisioning, senza la flessibilità di modificare proprietà come l'orario di lavoro o le severità.

Ora in Zabbix è disponibile una maggiore flessibilità per gli utenti provisionati:

i media utente provisionati possono essere disabilitati/abilitati;
i campi media dell'utente provisionato, come When active, Use if severity e Enabled, possono essere modificati manualmente;
è possibile aggiungere manualmente media utente aggiuntivi (ad esempio, indirizzi email aggiuntivi) per gli utenti provisionati;
i media utente aggiunti manualmente possono essere eliminati (i media utente provisionati non possono esserlo).

Inoltre, durante la configurazione del mapping dei media utente per il provisioning, campi come When active, Use if severity e Enabled sono ora disponibili. Nota che le modifiche al form di mapping del tipo di media utente avranno effetto solo sui nuovi media creati durante il provisioning.

Timeout configurabili per item

La configurazione del timeout per singolo item è ora disponibile per più tipi di item (vedere i tipi di item supportati). Oltre a impostare i valori di timeout a livello di item, è possibile definire timeout globali e di proxy per vari tipi di item.

I timeout configurati a livello di item hanno la priorità più alta. Per impostazione predefinita, i timeout globali vengono applicati a tutti gli item; tuttavia, se sono impostati timeout di proxy, questi sostituiranno quelli globali.

Oracle DB deprecato

Il supporto per Oracle come database backend è stato deprecato e si prevede che venga completamente rimosso nelle versioni future.

Protocollo JSON per i controlli passivi dell'agent

È stato implementato un protocollo basato su JSON per i controlli passivi dell'agent.

Per la compatibilità con gli agent più datati, è stato aggiunto un fallback al vecchio protocollo in testo semplice. Se l'agent restituisce "ZBX_NOTSUPPORTED", Zabbix memorizzerà l'interfaccia come protocollo precedente e ritenterà il controllo inviando solo la chiave dell'item in testo semplice.

Zabbix get può ora essere eseguito con una nuova opzione -P --protocol <value> in cui "value" è uno dei seguenti:

auto - connessione tramite protocollo JSON, con fallback e nuovo tentativo tramite protocollo in testo semplice (predefinito);
json - connessione tramite chiave del protocollo JSON;
plaintext - connessione tramite protocollo in testo semplice, in cui viene inviata solo la chiave dell'item.

Se una chiave dell'item non è supportata, Zabbix get restituirà il codice di uscita 1.

Protocolli di Unified agent/agent2

I protocolli di Zabbix agent e Zabbix agent 2 sono stati unificati passando Zabbix agent al protocollo di Zabbix agent 2. La differenza tra le richieste/risposte di Zabbix agent e Zabbix agent 2 è espressa dal valore del tag "variant" ("1" - Zabbix agent, "2" - Zabbix agent 2).

Vedi anche: Controlli agent passivi e attivi.

Supporto degli intervalli flessibili/pianificati nei controlli attivi

Gli intervalli flessibili/pianificati sono ora supportati nei controlli attivi sia da Zabbix agent sia da Zabbix agent 2 (in precedenza solo da Zabbix agent 2).

Disabilitazione automatica delle risorse perse

Le risorse che non vengono più rilevate dalla low-level discovery ora possono essere disabilitate automaticamente. Possono essere disabilitate immediatamente, dopo un periodo di tempo specificato oppure mai (vedere il nuovo parametro Disable lost resources nella configurazione della regola di discovery).

Le risorse perse (host, item, trigger) sono contrassegnate da un'icona nella colonna delle informazioni. Il testo del tooltip fornisce dettagli sul loro stato.

Nello stesso sviluppo, il parametro Keep lost resources period è stato rinominato in Delete lost resources con le opzioni per eliminare immediatamente, dopo un periodo di tempo specificato oppure mai.

Invio dei dati a Zabbix server tramite Zabbix API

In precedenza, l'invio di dati specifici a Zabbix server era possibile usando l'utility Zabbix sender oppure implementando un protocollo di comunicazione JSON personalizzato simile a quello usato in Zabbix sender.

Ora è anche possibile inviare dati a Zabbix server tramite protocollo HTTP usando il metodo API history.push. Si noti che la ricezione dei dati inviati richiede un item trapper configurato oppure un item HTTP agent (con trapping abilitato).

Inoltre, le operazioni history.push corrette vengono registrate in Reports → Audit log, che dispone di ulteriori opzioni di filtro (una nuova azione Push e la risorsa History), e il metodo API history.push è disponibile anche nella Allow/Deny list dei metodi API quando si configura un ruolo utente.

Script

Esecuzione di script su agent attivi

Ora è possibile eseguire script sugli agent che operano in modalità attiva. Una volta che l'esecuzione dello script viene attivata da un operazione dell'azione o dall'esecuzione manuale dello script, il comando viene incluso nella configurazione dei controlli attivi ed eseguito quando l'agent attivo lo riceve.

Gli script manuali vengono inviati all'agent attivo insieme al timeout di server/proxy per l'esecuzione dello script. Aumentare il timeout predefinito di server/proxy per l'esecuzione dello script. Il timeout deve essere superiore alla frequenza di aggiornamento dei controlli attivi; in caso contrario, il timeout viene superato prima che l'agent attivo riceva lo script e sia in grado di restituire il risultato.

Si noti che i vecchi agent attivi ignorano eventuali comandi remoti inclusi nella configurazione dei controlli attivi. Per ulteriori informazioni, vedere Controlli passivi e attivi dell'agent.

Input manuale dell'utente per gli script

L'input manuale dell'utente per gli script del frontend consente di fornire un parametro personalizzato a ogni esecuzione dello script. In questo modo non è necessario creare più script utente simili con una sola differenza di parametro.

Ad esempio, potresti voler fornire allo script un numero intero diverso oppure un indirizzo URL diverso durante l'esecuzione.

Per abilitare l'input manuale dell'utente:

usa la macro {MANUALINPUT} nello script (comandi, script, parametro dello script) dove richiesto; oppure nel campo URL degli script URL;
in configurazione avanzata dello script, abilita l'input manuale dell'utente e configura le opzioni di input:

Con l'input utente abilitato, prima dell'esecuzione dello script, all'utente verrà mostrato un popup Input manuale che richiederà di fornire un valore personalizzato. Il valore fornito sostituirà {MANUALINPUT} nello script.

A seconda della configurazione, all'utente verrà chiesto di inserire un valore stringa oppure di selezionare il valore da un menu a discesa con opzioni predefinite.

Prestazioni

Reazione più rapida all'aggiornamento del periodo di manutenzione dell'host

In precedenza le manutenzioni venivano ricalcolate solo ogni minuto, causando una possibile latenza fino a 60 secondi per l'avvio o l'arresto di un periodo di manutenzione.

Ora le manutenzioni vengono ancora ricalcolate ogni minuto oppure non appena la cache di configurazione viene ricaricata, se ci sono modifiche al periodo di manutenzione.

Ogni secondo il processo timer verifica se eventuali manutenzioni devono essere avviate/interrotte in base alla presenza di modifiche ai periodi di manutenzione dopo l'aggiornamento della configurazione. Pertanto la velocità di avvio/arresto dei periodi di manutenzione dipende dall'intervallo di aggiornamento della configurazione (10 secondi per impostazione predefinita). Nota che le modifiche al periodo di manutenzione non includono le impostazioni Active since/Active till. Inoltre, se un host/gruppo di host viene aggiunto a un periodo di manutenzione attivo esistente, le modifiche verranno attivate dal processo timer solo all'inizio del minuto successivo.

Controlli dei permessi più rapidi

I controlli dei permessi sono stati resi molto più veloci introducendo diverse tabelle intermedie per verificare i permessi degli utenti non privilegiati.

Queste tabelle conservano gli hash (SHA-256) dei set di gruppi di utenti e dei set di gruppi di host per ciascun utente/host rispettivamente. Inoltre, è presente una tabella dei permessi che memorizza solo le combinazioni accessibili di utenti e host, specificate tramite gli ID hash.

Questo miglioramento rende molto più rapido il caricamento delle pagine frontend con molti controlli dei permessi (ad esempio host, problemi). Si noti che hash e permessi non vengono calcolati per gli utenti Super-admin.

Esecuzione più rapida delle azioni dei trigger

L'esecuzione dell'operazione di trigger action, dell'operazione di ripristino e dell'operazione di aggiornamento sul server Zabbix avviene ora immediatamente (meno di 100 millisecondi) dopo una modifica dello stato del trigger, mentre in precedenza gli utenti potevano riscontrare una latenza fino a 4 secondi.

La riduzione della latenza è resa possibile dall'implementazione di meccanismi di comunicazione interprocesso (IPC) tra più processes (escalator e il relativo modulo di dispatch delle escalation, escalator e alerter, manager di preprocessing e history syncer).

Nella nuova versione sono stati aggiunti diversi nuovi widget, mentre la funzionalità disponibile in altri è stata migliorata. Inoltre, i widget della dashboard ora possono connettersi e comunicare tra loro, rendendo widget e dashboard più dinamici.

Gauge

È stato aggiunto il widget Gauge ai widget della dashboard, consentendo di visualizzare il valore di un singolo item come un indicatore a quadrante. Per ulteriori informazioni, vedere Gauge.

Grafico a torta

È stato aggiunto un widget Grafico a torta ai widget della dashboard, che consente di visualizzare i valori degli item selezionati come:

grafico a torta;
grafico a ciambella.


Grafico a torta.	Grafico a ciambella.

Per ulteriori informazioni, vedere Grafico a torta.

Nell'ambito di questo sviluppo, è stata aggiunta la casella di controllo Mostra funzione di aggregazione alla configurazione del widget grafico (nella scheda Legenda).

Honeycomb

È stato aggiunto un widget Honeycomb ai widget della dashboard, che offre una panoramica dinamica e vivace dell'infrastruttura di rete e delle risorse monitorate, in cui i gruppi di host, come macchine virtuali e dispositivi di rete, insieme ai rispettivi item, sono rappresentati visivamente come celle esagonali interattive. Per ulteriori informazioni, vedere Honeycomb.

Trigger principali

È stato aggiunto un widget Trigger principali ai widget della dashboard, che consente di visualizzare i trigger con il numero più elevato di problemi.

Per ulteriori informazioni, vedere: Trigger principali.

Cronologia degli item e testo semplice

Il nuovo widget della dashboard Cronologia degli item ha sostituito il widget Testo semplice, offrendo diversi miglioramenti.

A differenza del widget Testo semplice, che mostrava solo i dati più recenti dell'item in testo semplice, il widget Cronologia degli item supporta varie opzioni di visualizzazione per più tipi di item (numerico, carattere, log, testo e binario). Ad esempio, può mostrare barre di avanzamento o indicatori, immagini per i tipi di dati binari (utili per gli item del browser) e evidenziare i valori di testo (utile per il monitoraggio dei file di log).

Per ulteriori informazioni, vedere Cronologia degli item. Per i dettagli sulla sostituzione del widget Testo semplice, vedere Note di aggiornamento per la 7.0.0.

Host navigator e Item navigator

Sono stati aggiunti i widget Host navigator e Item navigator ai widget della dashboard. Questi widget visualizzano rispettivamente host o item, in base a varie opzioni di filtro e raggruppamento, e consentono di controllare le informazioni visualizzate in altri widget in base all'host o all'item selezionato. Per ulteriori informazioni, vedere Host navigator e Item navigator.

I widget della dashboard possono ora connettersi e comunicare tra loro, rendendo i widget e le dashboard più dinamici. Più widget dispongono di parametri che consentono di condividere dati di configurazione tra widget compatibili o con la dashboard.

Questa funzionalità introduce le seguenti modifiche:

I parametri Host groups, Hosts e Item consentono di selezionare le rispettive entità oppure una sorgente dati che le fornisce.
Il parametro Enable host selection è stato sostituito dal parametro Override host, che consente di selezionare una sorgente dati che fornisce host.
Il parametro Time period è stato aggiunto a più widget e consente di selezionare una sorgente dati che fornisce un periodo di tempo.
Il parametro Map nel widget Map consente di selezionare una mappa oppure un altro widget come sorgente dati per le mappe.
Il parametro Graph nel widget Graph (classic) consente di selezionare un grafico oppure un altro widget come sorgente dati per i grafici.

A seconda del widget e dei relativi parametri, la sorgente dati può essere un widget compatibile della stessa dashboard oppure la dashboard stessa. Per ulteriori informazioni, vedere Dashboard widgets.

Per le modifiche ai template standard forniti con Zabbix, vedere Template changes.

Ora i periodi di tempo possono essere configurati nei widget Item value e Top hosts.

Ora è anche possibile visualizzare un valore aggregato nel widget item value per il periodo scelto. Il valore aggregato può essere visualizzato come:

minimo
massimo
media
conteggio
somma
primo
ultimo

Queste funzionalità aggiuntive sono utili per creare widget di confronto dei dati. Ad esempio, in un widget è possibile visualizzare l'ultimo valore, mentre in un altro il valore medio per un periodo più lungo. Oppure è possibile usare più widget per confrontare affiancati i valori aggregati di vari periodi nel passato.

In precedenza, in una dashboard del template, era possibile creare solo i seguenti widget:
Clock, Graph (classic), Graph prototype, Item value, Plain text, URL.

Ora le dashboard dei template supportano la creazione di tutti i widget.

Ora, oltre all'ordinamento per Item value, è anche possibile impostare la colonna Host name o Text come colonna di ordinamento nel widget Top hosts.

Il widget Disponibilità host ora consente di visualizzare gli host con interfaccia Zabbix agent (active checks). È stato aggiunto un ulteriore stato di disponibilità, ovvero Mixed, che corrisponde alla situazione in cui almeno un'interfaccia non è disponibile e almeno un'altra è disponibile oppure sconosciuta. Inoltre, è stata introdotta la possibilità di visualizzare solo il totale degli host, senza la suddivisione per interfacce.

Il widget Graph ora supporta la configurazione di un numero variabile di righe della legenda, determinato dal numero di item configurati.

Funzioni

Nuove funzioni

Sono state aggiunte nuove funzioni da usare nelle espressioni dei trigger e negli item calcolati:

jsonpath() - restituisce il risultato JSONPath;
xmlxpath() - restituisce il risultato XPath XML.

Vedi anche: Funzioni di stringa

Funzioni aggiornate

Sono state aggiornate diverse funzioni:

Le funzioni di aggregazione ora supportano anche tipi non numerici per il calcolo. Questo può essere utile, ad esempio, con le funzioni count e count_foreach.
Le funzioni di aggregazione count e count_foreach supportano i parametri opzionali operator e pattern, che possono essere usati per affinare il filtraggio degli item e contare solo i valori che corrispondono ai criteri specificati.
Tutte le funzioni foreach non includono più gli item non supportati nel conteggio.
La funzione last_foreach, in precedenza configurata per ignorare l'argomento del periodo di tempo, lo accetta come parametro opzionale.
L'intervallo supportato per i valori restituiti dalle funzioni di previsione è stato ampliato per corrispondere all'intervallo del tipo di dato double. Ora la funzione timeleft() può accettare valori fino a 1.7976931348623158E+308 e la funzione forecast() può accettare valori compresi tra -1.7976931348623158E+308 e 1.7976931348623158E+308.

Item

Periodo di archiviazione predefinito della history coerente

Il periodo predefinito per la conservazione della history degli item è stato reso coerente a 31 giorni nel frontend e nel database. Questa modifica interessa i moduli di configurazione di item, item di template e prototipi di item, nonché l'override del periodo di archiviazione della history nella low-level discovery.

Valori in virgola mobile troncati per gli item interi

Ora, se viene ricevuto un valore in virgola mobile per un item intero senza segno, il valore verrà troncato della parte decimale e salvato come intero. In precedenza, un valore in virgola mobile rendeva un item intero non supportato.

Conteggio delle righe nel registro eventi di Windows

È stato aggiunto a Zabbix agent/agent 2 su Windows un nuovo item eventlog.count. Questo item restituisce un valore intero con il conteggio delle righe nel registro eventi di Windows in base ai parametri specificati.

Richieste SNMP asincrone a singolo OID

È stato aggiunto un nuovo item SNMP get[OID] che consente di interrogare in modo asincrono un singolo valore OID.

Item interni

I controlli interni sono ora gestiti da un nuovo processo internal poller di Zabbix server/proxy.

Sono stati aggiunti item interni per monitorare il buffer di memoria del proxy:

zabbix[proxy_buffer,buffer,<mode>] - restituisce le statistiche di utilizzo del buffer di memoria del proxy;
zabbix[proxy_buffer,state,changes] - restituisce il numero di cambi di stato tra le modalità buffer su disco/memoria dall'avvio;
zabbix[proxy_buffer,state,current] - restituisce lo stato operativo corrente in cui vengono memorizzati i nuovi dati.

Sono stati aggiunti anche i seguenti item interni:

zabbix[discovery_queue] - consente di monitorare il numero di controlli di discovery in coda;
zabbix[vps,written] - consente di monitorare il numero totale di valori di history scritti nel database.

Nuovi e aggiornati item dell'agent

Sono stati aggiunti nuovi item a Zabbix agent/agent 2:

net.dns.perf item restituisce il numero di secondi trascorsi in attesa di una risposta da un servizio, misurando l'esecuzione dell'item net.dns.
net.dns.get item di Zabbix agent 2 restituisce informazioni dettagliate sui record DNS.

I seguenti item di Zabbix agent/agent 2 sono stati aggiornati:

Gli item net.dns e net.dns.record ora accettano il nome DNS in formato invertito e non invertito quando eseguono ricerche DNS inverse;
Gli item proc.get in modalità "process" e "summary" ora restituiscono anche la memoria PSS (proportional set size) su Linux;
Gli item system.sw.packages e system.sw.packages.get sono ora supportati su Gentoo Linux;
L'item system.hostname ora può restituire un Fully Qualified Domain Name, se la nuova opzione fqdn è specificata nel parametro type;
Gli item wmi.get e wmi.getall usati con Zabbix agent 2 ora restituiscono JSON con valori booleani rappresentati come stringhe (ad esempio, "RealTimeProtectionEnabled": "True" invece di "RealTimeProtectionEnabled": true restituito in precedenza) per corrispondere al formato di output di questi item su Zabbix agent;
L'item oracle.ts.discovery di Zabbix agent 2 ora restituisce una nuova macro LLD {#CON_NAME} con il nome del container;
L'item oracle.ts.stats di Zabbix agent 2 ha un nuovo parametro conname per specificare il nome del container di destinazione. Il formato JSON dei dati restituiti è stato aggiornato. Quando nel parametro della chiave non viene specificato tablespace, type o conname, i dati restituiti includeranno un livello JSON aggiuntivo con il nome del container, consentendo di distinguere tra i container.

Simple checks

L'item vmware.eventlog ora supporta il filtraggio opzionale per severità nel terzo parametro.

L'item vmware.vm.discovery ora restituisce anche i dati sulle interfacce di rete delle macchine virtuali. Questi dati possono essere usati per configurare host interfaces personalizzate.

L'item vmware.vm.net.if.discovery ora restituisce anche un array di indirizzi delle interfacce di rete.

È stato aggiunto un nuovo parametro options ai seguenti item:

Questo parametro può essere usato per specificare se le risposte reindirizzate debbano essere considerate come host di destinazione attivo o host di destinazione non attivo. Per ulteriori dettagli, vedere simple checks.

Registrazione degli ID Engine SNMPv3 duplicati

Gli ID Engine in SNMPv3 vengono usati come identificatori univoci del dispositivo. A volte gli ID Engine sono uguali su più dispositivi a causa di una configurazione errata o delle impostazioni di fabbrica. Poiché gli standard SNMP richiedono che gli ID Engine siano univoci, gli item che condividono lo stesso ID Engine diventano non supportati in Zabbix, causando problemi di disponibilità per questi dispositivi.

Per aiutare a risolvere questi problemi, le informazioni sui dispositivi SNMPv3 che condividono lo stesso ID Engine verranno ora registrate periodicamente da Zabbix server. Si noti che il rilevamento degli ID Engine duplicati funziona separatamente in ciascun poller SNMP.

Collegamento alla documentazione per ciascun item standard

Ogni item standard ora dispone di un collegamento diretto dal frontend alla relativa pagina di documentazione.

I collegamenti si trovano sotto l'icona del punto interrogativo, quando si apre la finestra di aiuto dell'item dalla maschera di configurazione dell'item (fare clic su Seleziona accanto al campo della chiave dell'item).

Pre-elaborazione

Gestione avanzata delle cause alla radice per lo stato non supportato dell'item

La gestione degli errori in caso di mancato recupero del valore di un item (e quindi del suo passaggio allo stato non supportato) in precedenza non consentiva di distinguere il motivo o la fase di esecuzione in cui il processo era fallito. Tutti gli errori dovevano essere gestiti usando una sola e medesima opzione di gestione degli errori: scartare il valore, impostare un valore specificato oppure impostare un messaggio di errore specificato.

Ora è possibile confrontare il messaggio di errore con un'espressione regolare. Se l'errore corrisponde (o non corrisponde), è possibile specificare come deve essere elaborato il caso di errore. Ad esempio, un messaggio di errore specifico può essere "mappato" a un caso più generale da cercare e gestire in un ulteriore passaggio di preprocessing, oppure un problema intermittente (ad esempio, di connettività di rete) può essere gestito in modo diverso rispetto a un fallimento definitivo nell'acquisizione del valore dell'item.

Ora è possibile aggiungere più passaggi di preprocessing Check for not supported value. Nota che può esserci un solo passaggio di corrispondenza "any error" alla fine della pipeline che verifica lo stato non supportato dell'item. Se presente, viene attivato se nessuno dei controlli specifici ha (o non ha) corrisposto al pattern corrispondente, oppure se è stato trasportato un messaggio di errore (modificato), cioè non è entrato in vigore alcun override "Discard value" o "Set value to".

Vedi anche: Check for not supported value

Migliore usabilità per l'aggiornamento massivo del passo di preprocessing

Il precedente design del modulo di aggiornamento massivo degli item non era sufficientemente chiaro nel caso in cui l'aggiornamento del passo di preprocessing avrebbe aggiunto o sostituito i passi di preprocessing. Nel nuovo design sono stati aggiunti i pulsanti di opzione Replace e Remove all, rendendo chiaro agli utenti cosa aspettarsi come risultato dell'aggiornamento massivo dei passi di preprocessing:

Macro

Macro utente supportate nei nomi di item e dei prototipi di item

Le macro utente sono ora supportate nei nomi di item e nei nomi dei prototipi di item.

Si noti che il supporto alle macro utente è stato rimosso dai nomi di item/prototipi di item in Zabbix 6.0.
Ora è stato ripristinato. È inoltre ora supportata la ricerca del nome dell'item con le macro risolte, cosa che in precedenza non era supportata.

Il nome dell'item con le macro risolte viene memorizzato in una tabella separata del database (item_rtname), che è un'estensione della tabella degli item. Per ogni record nella tabella degli item, viene creato un record corrispondente item_rtname (ad eccezione dei prototipi di item, degli item delle regole di discovery e degli item dei template). Il nome con le macro risolte è limitato a 2048 caratteri.

Il nome dell'item con le macro risolte viene visualizzato in tutte le posizioni del frontend, ad eccezione della sezione Data collection.

È stato aggiunto un nuovo processo del server configuration syncer worker responsabile della risoluzione e della sincronizzazione dei valori delle macro utente nei nomi degli item.

Supporto esteso delle funzioni macro

Le funzioni macro sono ora supportate con tutti i tipi di macro:

Le funzioni macro possono essere utilizzate in tutte le posizioni che supportano le macro elencate. Questo vale salvo che sia esplicitamente indicato che è prevista solo una macro (ad esempio, durante la configurazione delle macro dell'host o dei filtri delle regole di discovery a basso livello).

Report pianificati

La funzionalità report pianificati non è più sperimentale.

Reporting multi-pagina

Per i dashboard multipagina, i report vengono ora restituiti con tutte le pagine del dashboard, con ogni pagina PDF corrispondente a una pagina del dashboard. In precedenza, questa funzionalità era limitata alla restituzione della sola prima pagina del dashboard.

Notifiche

Supporto per l'elaborazione dei tag per gli eventi interni

L'elaborazione dei tag restituiti dallo script webhook è ora supportata anche per gli eventi interni.

Inoltre, le macro {EVENT.TAGS.<tag name>}, {EVENT.TAGS}, {EVENT.TAGSJSON}, {EVENT.RECOVERY.TAGS}, {EVENT.RECOVERY.TAGSJSON} sono ora supportate per le notifiche degli eventi interni.

Queste modifiche consentono di usare i webhook per aggiornare o chiudere un ticket di supporto/problema esterno tramite la notifica di recupero di un evento interno.

Database

Auditlog convertito in hypertable su TimescaleDB

La tabella auditlog è stata convertita in hypertable su TimescaleDB nelle nuove installazioni per beneficiare della partizione automatica in base al tempo (7 giorni per impostazione predefinita) e di prestazioni migliori.

Per aggiornare correttamente le installazioni esistenti, vedere Aggiornamento dello schema di TimescaleDB.

Vedi anche: Versioni di TimescaleDB supportate

Tabella del database separata per i proxy

I record dei proxy sono stati spostati dalla tabella hosts e ora sono memorizzati nella nuova tabella proxy.

Inoltre, i dati operativi dei proxy (come ultimo accesso, versione, compatibilità) sono stati spostati dalla tabella host_rtdata e ora sono memorizzati nella nuova tabella proxy_rtdata.

Processi

Multithreading

Sono state apportate diverse modifiche nell'ambito della transizione a un'architettura multithread:

È stato aggiunto un nuovo parametro di configurazione: --with-stacksize. Questo parametro consente di sovrascrivere la dimensione predefinita dello stack dei thread utilizzata dal sistema (in kilobyte).
La risoluzione delle macro utente è stata spostata dal gestore di preprocessing ai worker di preprocessing.

Rafforzamento dell'ambiente del server

Ora è possibile limitare alcune funzioni di Zabbix per rafforzare la sicurezza dell'ambiente del server:

l'esecuzione globale degli script sul server Zabbix può essere disabilitata impostando EnableGlobalScripts=0 nella configurazione del server. Per le nuove installazioni, l'esecuzione globale degli script sul server Zabbix è disabilitata per impostazione predefinita.
l'autenticazione HTTP dell'utente può essere disabilitata impostando $ALLOW_HTTP_AUTH=false nel file di configurazione del frontend (zabbix.conf.php).
il modem GSM per le notifiche SMS ora può essere specificato nel nuovo parametro SMSDevices, limitando la possibilità di configurare in modo errato il percorso del modem GSM dal frontend.

Validazione del file di configurazione

La possibilità di validare il file di configurazione è stata aggiunta ai comandi di manutenzione di Zabbix server, proxy, agent, agent 2 e web service. La validazione può essere eseguita utilizzando l'opzione -T --test-config. In caso di validazione riuscita, il codice di uscita sarà "0"; in caso contrario, il componente terminerà con un codice di uscita diverso da zero e un messaggio di errore corrispondente. Gli avvisi (ad esempio, nel caso di un parametro deprecato) non influiranno sul codice di uscita positivo.

Rilevamento delle funzionalità della libreria cURL in fase di esecuzione

In precedenza, le funzionalità della libreria cURL venivano rilevate al momento della compilazione di Zabbix server, proxy o agent. Se le funzionalità di cURL venivano aggiornate, per poterle utilizzare era necessario ricompilare il relativo componente Zabbix.

Ora è sufficiente un riavvio affinché le funzionalità aggiornate della libreria cURL diventino disponibili in Zabbix. La ricompilazione non è più necessaria. Questo vale per Zabbix server, proxy o agent.

Vedi anche le note di aggiornamento.

Configurazione di Agent 2

Dimensione del buffer

Il valore predefinito del parametro di configurazione BufferSize per Zabbix agent 2 è stato aumentato da 100 a 1000.

Valori vuoti consentiti

I valori vuoti sono ora consentiti nei parametri di configurazione relativi ai plugin su Zabbix agent 2.

Impostazione del tipo di avvio del servizio agent Windows

È stata aggiunta l'opzione per impostare il tipo di avvio del servizio Windows di Zabbix agent/agent 2 (-S --startup-type). Questa opzione consente di configurare il servizio agent/agent 2 in modo che si avvii automaticamente all'avvio di Windows (automatic), dopo il completamento dell'avvio dei servizi avviati automaticamente (delayed), quando viene avviato manualmente da un utente o da un'applicazione (manual) oppure di disabilitare completamente il servizio (disabled).

Quando si esegue l'installazione di agent Windows da MSI, il tipo di avvio predefinito su Windows Server 2008/Vista e versioni successive è ora delayed se non specificato diversamente nel parametro della riga di comando STARTUPTYPE. Questo migliora l'affidabilità e le prestazioni del servizio Windows di Zabbix agent/agent 2, in particolare durante i riavvii del sistema.

Supporto per il vecchio tipo numerico rimosso

Il vecchio formato dei valori in virgola mobile, precedentemente deprecato, non è più supportato, poiché vengono utilizzati valori numerici di intervallo esteso.

Aggiunto il parametro Vault prefix ai file di configurazione

I file di configurazione zabbix_server.conf e zabbix_proxy.conf sono stati integrati con un nuovo parametro opzionale Vault Prefix; zabbix.conf.php è stato integrato con l'opzione opzionale $DB['VAULT_PREFIX'], e setup.php è stato aggiornato di conseguenza.

I percorsi del vault per CyberArk e HashiCorp non sono quindi più codificati in modo fisso, per consentire distribuzioni del vault con percorsi non standard.

Discovery

Concorrenza nella discovery di rete

In precedenza, ogni regola di discovery di rete veniva elaborata da un processo discoverer. Di conseguenza, tutti i controlli dei servizi all'interno della regola potevano essere eseguiti solo in sequenza.

Nella nuova versione, il processo di discovery di rete è stato rielaborato per consentire la concorrenza tra i controlli dei servizi. È stato aggiunto un nuovo processo discovery manager, insieme a un numero configurabile di discovery worker (o thread).

Il discovery manager elabora le regole di discovery e crea un job di discovery per ciascuna regola con le relative attività (controlli dei servizi). I controlli dei servizi vengono presi in carico ed eseguiti dai discovery worker. Solo i controlli che hanno lo stesso IP e la stessa porta vengono pianificati in sequenza, perché alcuni dispositivi potrebbero non consentire connessioni concorrenti sulla stessa porta.

Un nuovo item interno zabbix[discovery_queue] consente di monitorare il numero di controlli di discovery in coda.

Il parametro StartDiscoverers ora determina il numero totale di discovery worker disponibili per la discovery. Il valore predefinito di StartDiscoverers è stato aumentato da 1 a 5, e l'intervallo da 0-250 a 0-1000. I processi discoverer delle versioni precedenti di Zabbix sono stati rimossi.

Inoltre:

Tutti i controlli dei servizi vengono ora eseguiti asincronamente, ad eccezione dei controlli LDAP;
Il numero di controlli asincroni simultanei per ciascun tipo di controllo dei servizi (o il numero di worker disponibili per tutti i controlli sincroni dei servizi) è ora configurabile nel frontend (vedere Maximum concurrent checks per type). Questo parametro è facoltativo.
In precedenza, il controllo del servizio HTTP era uguale al controllo TCP. Ora il controllo HTTP/HTTPS viene eseguito tramite libcurl. Se Zabbix server/proxy è compilato senza libcurl, i controlli HTTP funzioneranno come in precedenza (cioè come controlli TCP), ma i controlli HTTPS non funzioneranno.
Gli errori nel processo di discovery di rete verranno ora visualizzati nel frontend (in Data collection -> Discovery), ad esempio:
- errori fping;
- SNMP OID non corretto;
- macro non corretta per il timeout dell'item;
- errori nell'intervallo di indirizzi.

Aggiunta di tag host durante discovery/autoregistrazione

Sono ora disponibili operazioni aggiuntive per gli eventi di discovery e autoregistrazione:

Aggiungi tag host
Rimuovi tag host

Condivisione dei gruppi host scoperti

Le regole di discovery a basso livello possono ora collegare ai host creati dalle stesse regole di discovery a basso livello i gruppi host già scoperti ed esistenti. Questo riguarda i gruppi host precedentemente scoperti e creati da altre regole di discovery a basso livello basate sui group prototypes specificati.

Connettori

La funzionalità di data streaming non è più sperimentale.

Trasmettere dati selettivi e configurare gli intervalli di tentativo

Quando si trasmettono i valori degli item da Zabbix a sistemi esterni, ora è possibile configurare quali valori degli item il connettore deve trasmettere in base al loro tipo di informazione (numerico (senza segno), numerico (float), carattere, ecc.).

Inoltre, per evitare tentativi non riusciti di trasmettere valori degli item o eventi (ad esempio, se l'endpoint HTTP è occupato o soggetto a limitazioni di velocità), ora è possibile configurare anche l'intervallo di tentativo: per quanto tempo il connettore deve attendere dopo un tentativo non riuscito di trasmettere i dati.

I codici di risposta HTTP 201, 202, 203 e 204 sono ora accettati anche dai connettori come esito positivo (in precedenza solo 200).

Trasmettere dati in streaming ad Apache Kafka

È ora disponibile un nuovo strumento per lo streaming dei dati verso sistemi esterni: il Kafka connector per Zabbix server.

Il Kafka connector è un server leggero scritto in Go, progettato per inoltrare i valori degli item e gli eventi da un Zabbix server a un broker Kafka.

Template

Per i nuovi template e le modifiche ai template esistenti, vedere Modifiche ai template.

frontend

Autenticazione a più fattori

L'autenticazione a più fattori (MFA) con il metodo di autenticazione Time-Based One-Time Password (TOTP) o Duo Universal Prompt può ora essere utilizzata per accedere a Zabbix, fornendo un ulteriore livello di sicurezza oltre al solo nome utente e password.

Formato orario statunitense

Le visualizzazioni di data e ora nel frontend ora sono conformi al formato standard statunitense di data/ora quando viene utilizzata la lingua predefinita del frontend (en_US).

Prima	Ora

Clonazione semplificata

In precedenza era possibile eseguire Clone e Full clone di host, template e mappe.

Ora l'opzione Clone è stata rimossa e l'opzione Full clone è stata rinominata in Clone, mantenendo comunque tutte le funzionalità precedenti di Full clone.

Icone sostituite dai font

Tutte le icone nel frontend sono state convertite da fogli di immagini di icone a font.

Moduli in finestra modale

Diversi moduli del frontend vengono ora aperti in finestre modali (popup):

configurazione della regola di discovery di rete;
configurazione dello script globale;
configurazione della correlazione degli eventi;
configurazione del modulo
configurazione del tipo di media;
configurazione del template;
configurazione di trigger e trigger prototype;
configurazione di item e item prototype.

Configurazione avanzata comprimibile

Le caselle di controllo Advanced configuration, responsabili della visualizzazione delle opzioni di configurazione avanzate, sono state sostituite da blocchi comprimibili (vedi, ad esempio, Connector configuration, Service configuration, Clock widget configuration, ecc.). Questo migliora l'esperienza utente, poiché comprimere questi blocchi e salvare la configurazione non reimposterà più le opzioni avanzate configurate ai valori predefiniti.

La sezione di menu per la visualizzazione dei trigger principali ora si chiama Top 100 triggers. È stata aggiunta la possibilità di filtrare i trigger per nome del problema e tag. Inoltre, per ogni trigger viene ora visualizzato il numero di problemi rilevati invece del numero di cambi di stato.

Limite di caratteri aumentato per i campi di configurazione

Campi URL

Il limite di caratteri per tutti i campi URL è ora di 2048 caratteri. Questo include ora: Tile URL per le impostazioni relative alle mappe geografiche, Frontend URL per la configurazione di vari parametri frontend, URLs per mappe di rete ed elementi della mappa di rete, URL A-C per i campi di inventario host, e URL per il widget dashboard URL.

Campi di autenticazione

Il limite di caratteri per i campi di autenticazione User/User name e Password è ora di 255 caratteri. Questo vale per la configurazione dell'autenticazione HTTP per gli item HTTP agent, web scenarios e connectors, nonché per la configurazione dell'autenticazione per simple checks, ODBC monitoring, SSH checks, Telnet checks, e JMX monitoring.

Troncamento del risultato del test di item e preprocessing

Quando si testano gli item o si testano i passaggi di preprocessing, i valori recuperati da un host e i risultati dei test vengono ora troncati a una dimensione massima di 512KB quando vengono inviati al frontend. Si noti che i dati superiori a 512KB vengono comunque elaborati integralmente da Zabbix server.

Schede delle dashboard dell'host

Tutte le dashboard dell'host configurate per l'host selezionato sono ora visualizzate come schede sotto l'intestazione della pagina delle dashboard dell'host, sostituendo il precedente menu a discesa nell'angolo in alto a destra. Questo consente di passare facilmente da una dashboard dell'host all'altra e migliora la navigazione tra i dati di monitoraggio.

Registro di audit

In Administration → Registro di audit, ora è possibile abilitare/disabilitare la registrazione di audit delle attività di low-level discovery, network discovery e autoregistrazione eseguite dal server (System user).

Il periodo predefinito di conservazione dei record del registro di audit prima che vengano eliminati dall'housekeeper è stato modificato da 365 giorni a 31 giorni.

Filtro dei dati più recenti

In Monitoring → Dati più recenti, il sottofiltro e i dati non vengono più visualizzati per impostazione predefinita se il filtro non è impostato.

Se si esegue l'aggiornamento da versioni precedenti di Zabbix, vedere anche: Note di aggiornamento per 7.0.0.

Versione minima richiesta di PHP

La versione minima richiesta di PHP è stata aumentata da 7.4.0 a 8.0.0.

Elementi rinominati

Alcuni parametri dei widget della dashboard con l'etichetta Tags sono stati rinominati per maggiore chiarezza: Item tags (per il widget Data overview), Scenario tags (per il widget Web monitoring); Problem tags (per i widget Graph, Problem hosts, Problems, Problems by severity e Trigger overview);
Il collegamento dell'azione per la modifica del contenuto della mappa, disponibile dall'elenco delle mappe nella sezione Monitoring → Maps, è stato rinominato da Constructor a Edit;
I campi per impostare i periodi di conservazione della history e dei trend nei moduli di configurazione di item e item prototype sono stati rinominati;
Nella configurazione del widget Top hosts, i campi Order column e Host count sono stati rinominati in Order by e Host limit per descriverne meglio le funzioni.
Nella configurazione del widget Graph, il campo legend Display min/max/avg è stato rinominato in Display min/avg/max, e i campi del data set host pattern e item pattern sono stati rinominati in host patterns e item patterns.
Nelle impostazioni del User profile, la scheda Messaging è stata rinominata in Frontend notifications, e anche l'opzione Frontend messaging è stata rinominata in Frontend notifications.

Varie

Le icone del menu principale sono state aggiornate;
I messaggi che indicano l'assenza di dati o filtri non impostati (nei widget o nei filtri popup senza dati da visualizzare) sono stati aggiornati. Inoltre, il piè di pagina "Displaying 0 of 0 found" è stato rimosso nei casi in cui non ci sono dati da visualizzare o quando il filtraggio (o l'uso della ricerca globale) non produce alcuna corrispondenza.
I numeri di versione di Zabbix frontend e Zabbix server sono ora visibili nella pagina delle informazioni di sistema;
Tutte le azioni in cui viene utilizzato il media type sono ora visualizzate nell'elenco dei media type (colonna Used in actions). In precedenza, le azioni in cui l'opzione Send only to opzione nella configurazione dell'operazione dell'azione era "All" non erano incluse nella colonna Used in actions del media type;
È stata aggiunta una nuova opzione di filtro alla sezione Latest data: ora consente di filtrare gli item in base al loro stato (supportato/non supportato);
È stata aggiunta una nuova opzione di filtro Acknowledgement status alla sezione Problems: ora consente di filtrare i problemi in base al loro stato (non riconosciuto/riconosciuto/riconosciuto da me);
È stato aggiunto il pulsante standard di chiusura della finestra alle finestre popup destinate alla configurazione e all'aggiornamento massivo degli elementi e delle forme della mappa;
La configurazione delle autorizzazioni dei user group e dei tag per filtrare i problemi visualizzabili è stata perfezionata. Ora è possibile selezionare più gruppi host/template contemporaneamente per assegnare loro le stesse autorizzazioni.
Le notifiche globali Snoozing in un browser le sospenderanno ora in tutti i browser/dispositivi in cui l'utente ha effettuato l'accesso.
Il parametro Override host nel widget Item value è stato spostato prima della sezione Advanced configuration per una migliore usabilità.

Plugin

Ember+

È stato aggiunto un nuovo plugin per il monitoraggio diretto di Ember+ da parte di agent 2 di Zabbix.

Per ulteriori informazioni, vedere:

Installazione

Pacchetti di installazione separati per i derivati di RHEL

Sono disponibili pacchetti di installazione dedicati per le versioni 8 e 9 di AlmaLinux, CentOS Stream, Oracle Linux e Rocky Linux. In precedenza, venivano forniti pacchetti di installazione singoli per RHEL e per le distribuzioni basate su RHEL. Ora vengono utilizzati pacchetti separati per RHEL e per ciascuno dei suoi derivati sopra menzionati per evitare potenziali problemi di incompatibilità binaria.

Supporto per ARM64/AArch64

I pacchetti di installazione ARM64/AArch64 sono ora disponibili per Debian, RHEL 8, 9 e le relative derivate, nonché per SLES/OpenSUSE Leap 15.

What’s next?

6 Novità di Zabbix 7.0.1

Docs

5 Novità di Zabbix 7.0.0

Licenza AGPL-3.0

Controllo degli aggiornamenti software