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 e alta disponibilità dei proxy

Il bilanciamento del carico dei proxy viene 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 relativi host vengono immediatamente distribuiti tra gli altri proxy del gruppo.

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

Buffer di memoria del proxy

È stato sviluppato un buffer di memoria per il proxy Zabbix. Il buffer di memoria consente di archiviare nel buffer i nuovi dati (valori degli item, rilevamento della rete, registrazione automatica degli host) e di caricarli nel server Zabbix senza accedere al database.

Nelle installazioni precedenti a Zabbix 7.0, i dati raccolti venivano archiviati nel database prima di essere caricati nel server Zabbix. Per queste installazioni, questo comportamento rimane quello predefinito dopo l'aggiornamento.

Per ottenere prestazioni ottimizzate, è consigliabile configurare l'uso del buffer di memoria sul proxy. A tale scopo, modificare il valore di ProxyBufferMode da "disk" (valore predefinito codificato per le installazioni esistenti) a "hybrid" (consigliato) o "memory". È inoltre necessario impostare la dimensione del buffer di memoria (parametro ProxyMemoryBufferSize).

In modalità ibrida, il buffer è protetto dalla perdita di dati: i dati non inviati vengono scaricati nel database se il proxy viene arrestato, il buffer è pieno o 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à memoria, viene utilizzato il buffer di memoria, ma non è disponibile alcuna protezione contro la perdita di dati. Se il proxy viene arrestato o la memoria si riempie, i dati non inviati vengono eliminati.

La modalità ibrida (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.

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

Provisionamento JIT degli utenti

In precedenza, gli utenti sottoposti a provisioning erano limitati esclusivamente ai media creati durante il provisioning, senza la possibilità di modificare proprietà quali gli orari di attività o le gravità.

Ora in Zabbix sono disponibili maggiori possibilità di gestione per gli utenti sottoposti a provisioning:

i media degli utenti sottoposti a provisioning possono essere disabilitati/abilitati;
i campi dei media degli utenti sottoposti a provisioning, come Quando attivo, Usa se la gravità e Abilitato, possono essere modificati manualmente;
è possibile aggiungere manualmente ulteriori media degli utenti (ad esempio, indirizzi email aggiuntivi) per gli utenti sottoposti a provisioning;
i media degli utenti aggiunti manualmente possono essere eliminati (i media degli utenti sottoposti a provisioning non possono essere eliminati).

Inoltre, durante la configurazione della mappatura dei media degli utenti per il provisioning, sono ora disponibili campi quali Quando attivo, Usa se la gravità e Abilitato. Si noti che le modifiche al modulo di mappatura dei tipi di media degli utenti 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 garantire la compatibilità con gli agent meno recenti, è stato aggiunto un fallback al precedente protocollo in testo semplice. Se l'agent restituisce "ZBX_NOTSUPPORTED", Zabbix memorizzerà nella cache l'interfaccia come appartenente al protocollo precedente e riproverà il controllo inviando solo la chiave dell'item in testo semplice.

Ora Zabbix get può essere eseguito con la nuova opzione -P --protocol <value>, dove "value" può essere:

auto - connessione tramite protocollo JSON, con fallback e nuovo tentativo tramite protocollo in testo semplice (impostazione predefinita);
json - connessione tramite la chiave del protocollo JSON;
plaintext - connessione tramite il 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 unificati di agent/agent2

I protocolli di Zabbix agent e 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).

Vedere anche: Controlli passivi e attivi dell'agent.

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 non più disponibili

Le risorse che non vengono più rilevate dal 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 non più disponibili (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 opzioni per eliminare le risorse immediatamente, dopo un periodo di tempo specificato oppure mai.

Invio di dati al server Zabbix tramite l'API Zabbix

In precedenza, l'invio di dati specifici al server Zabbix era possibile utilizzando l'utilità Zabbix sender oppure implementando un protocollo di comunicazione personalizzato basato su JSON, simile a quello utilizzato da Zabbix sender.

Ora è anche possibile inviare dati al server Zabbix tramite il protocollo HTTP utilizzando il metodo API history.push. Per ricevere i dati inviati è necessario disporre di un item trapper configurato oppure di un item HTTP agent (con il trapping abilitato).

Inoltre, le operazioni history.push corrette vengono registrate in Report → Registro di audit, che dispone di ulteriori opzioni di filtraggio (una nuova azione Push e la risorsa History). Il metodo API history.push è inoltre disponibile nell'elenco Consenti/Blocca dei metodi API durante la configurazione di un ruolo utente.

Script

Esecuzione di script sugli agent attivi

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

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

Gli agent attivi meno recenti ignorano tutti i 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 nel parametro.

Ad esempio, durante l'esecuzione è possibile fornire allo script un intero diverso o un URL diverso.

Per abilitare l'input manuale dell'utente:

utilizzare la macro {MANUALINPUT} nello script (comandi, script, parametro dello script) dove necessario; oppure nel campo URL degli script URL;
nella configurazione avanzata dello script, abilitare l'input manuale dell'utente e configurare le opzioni di input:

Con l'input dell'utente abilitato, prima dell'esecuzione dello script verrà visualizzato all'utente un popup Input manuale, che chiederà 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 elenco a discesa di opzioni predefinite.

Prestazioni

Reazione più rapida agli aggiornamenti dei periodi di manutenzione degli host

In precedenza, i periodi di manutenzione venivano ricalcolati solo ogni minuto, causando una possibile latenza fino a 60 secondi nell'avvio o nell'interruzione di un periodo di manutenzione.

Ora i periodi di manutenzione vengono ancora ricalcolati ogni minuto oppure non appena la cache di configurazione viene ricaricata, se sono presenti modifiche al periodo di manutenzione.

Ogni secondo, il processo timer verifica se è necessario avviare/interrompere un periodo di manutenzione in base alla presenza di modifiche ai periodi di manutenzione dopo l'aggiornamento della configurazione. Pertanto, la velocità di avvio/interruzione dei periodi di manutenzione dipende dall'intervallo di aggiornamento della configurazione (10 secondi per impostazione predefinita). Le modifiche al periodo di manutenzione non includono le impostazioni Attivo da/Attivo fino a. Inoltre, se un host o un 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 delle autorizzazioni più veloci

I controlli delle autorizzazioni sono stati resi molto più veloci introducendo diverse tabelle intermedie per verificare le autorizzazioni degli utenti non privilegiati.

Queste tabelle memorizzano gli hash (SHA-256) degli insiemi di gruppi di utenti e degli insiemi di gruppi di host per ogni utente/host rispettivamente. Inoltre, è presente una tabella delle autorizzazioni che memorizza solo le combinazioni accessibili di utenti e host, specificate dagli ID degli hash.

Questo miglioramento rende molto più veloce il caricamento delle pagine del frontend che richiedono numerosi controlli delle autorizzazioni (ad esempio, host e problemi). Si noti che gli hash e le autorizzazioni 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 le funzionalità disponibili in altri sono state ampliate. Inoltre, ora i widget del dashboard possono connettersi e comunicare tra loro, rendendo i widget e i 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

Un widget Trigger principali è stato aggiunto ai widget del dashboard e consente di visualizzare i trigger con il maggior numero di problemi.

Per ulteriori informazioni, vedere: Trigger principali.

Cronologia degli item e testo semplice

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

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

Per ulteriori informazioni, vedere Cronologia degli item. Per informazioni dettagliate sulla sostituzione del widget Testo semplice, vedere Note sull'aggiornamento alla versione 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 del dashboard possono ora connettersi e comunicare tra loro, rendendo i widget e i dashboard più dinamici. Diversi widget dispongono di parametri che consentono loro di condividere i dati di configurazione tra widget compatibili o con il dashboard.

Questa funzionalità introduce le seguenti modifiche:

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

A seconda del widget e dei relativi parametri, la fonte dati può essere un widget compatibile dello stesso dashboard oppure il dashboard stesso. Per ulteriori informazioni, vedere Dashboard widgets.

Per le modifiche ai template predefiniti distribuiti con Zabbix, vedere Template changes.

Ora è possibile configurare i periodi di tempo nei widget Valore dell'item e Host principali.

Ora è inoltre possibile visualizzare un valore aggregato nel widget Valore dell'item per il periodo selezionato. 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 il valore più recente, mentre in un altro il valore medio relativo a un periodo più lungo. In alternativa, è possibile utilizzare diversi widget per confrontare affiancati i valori aggregati di vari periodi passati.

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 Valore dell'item, è possibile impostare anche la colonna Nome host o Testo come colonna di ordinamento nel widget Top hosts.

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

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 aggregate ora supportano anche i tipi non numerici per i calcoli. Questo può essere utile, ad esempio, con le funzioni count e count_foreach.
Le funzioni aggregate count e count_foreach supportano i parametri opzionali operator e pattern, che possono essere utilizzati per perfezionare 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, precedentemente configurata per ignorare l'argomento relativo al 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 dati 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 predefinito coerente per la conservazione della cronologia

Il periodo predefinito di conservazione della cronologia degli item è stato uniformato a 31 giorni nel frontend e nel database. Questa modifica riguarda i moduli di configurazione di item, item dei template e prototipi di item, nonché l'override del periodo di conservazione della cronologia nel low-level discovery.

Valori a virgola mobile troncati per gli item interi

Ora, se per un item intero senza segno viene ricevuto un valore a virgola mobile, la parte decimale viene troncata e il valore viene salvato come intero. In precedenza, un valore a 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 item dell'agent e item aggiornati

Sono stati aggiunti nuovi item all'agent Zabbix/agent 2:

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

Sono stati aggiornati i seguenti item dell'agent Zabbix/agent 2:

gli item net.dns e net.dns.record ora accettano il nome DNS in formato inverso e non inverso 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 può ora restituire un Fully Qualified Domain Name, se la nuova opzione fqdn è specificata nel parametro type;
gli item wmi.get e wmi.getall utilizzati con l'agent Zabbix 2 ora restituiscono JSON con i 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 sull'agent Zabbix;
l'item oracle.ts.discovery dell'agent Zabbix 2 ora restituisce una nuova macro LLD {#CON_NAME} con il nome del container;
l'item oracle.ts.stats dell'agent Zabbix 2 dispone di un nuovo parametro conname per specificare il nome del container di destinazione.

Il formato JSON dei dati restituiti è stato aggiornato. Quando nei parametri della chiave non viene specificato alcun valore tablespace, type o conname, i dati restituiti includeranno un livello JSON aggiuntivo con il nome del container, consentendo di distinguere i container.

Controlli semplici

L'item vmware.eventlog ora supporta il filtraggio facoltativo per gravità nel terzo parametro.

L'item vmware.vm.discovery ora restituisce anche i dati sulle interfacce di rete delle macchine virtuali. Questi dati possono essere utilizzati per configurare interfacce host 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 utilizzato per specificare se le risposte reindirizzate devono essere trattate come se il target host fosse attivo o inattivo. Per ulteriori informazioni, vedere controlli semplici.

Registrazione di Engine ID SNMPv3 duplicati

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

Per facilitare la risoluzione di questi problemi, le informazioni sui dispositivi SNMPv3 che condividono lo stesso Engine ID verranno ora registrate periodicamente dal server Zabbix. Si noti che il rilevamento degli Engine ID duplicati funziona separatamente in ogni 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 della causa principale per lo stato non supportato dell'item

La gestione degli errori in caso di mancato recupero del valore di un item, che ne comporta lo stato non supportato, in precedenza non consentiva di distinguere la causa o la fase di runtime in cui si verificava l'errore. Tutti gli errori dovevano essere gestiti utilizzando un'unica opzione per la gestione degli errori: eliminare il valore, impostare un valore specifico oppure impostare un messaggio di errore specifico.

Ora è possibile confrontare il messaggio di errore con un'espressione regolare. Se l'errore corrisponde o non corrisponde all'espressione, è possibile specificare come elaborare il caso di errore. Ad esempio, un messaggio di errore specifico può essere "mappato" a un caso più generale da confrontare e gestire tramite un'ulteriore fase di pre-elaborazione, oppure un problema intermittente, ad esempio relativo alla connettività di rete, può essere gestito in modo diverso rispetto a un errore definitivo nell'acquisizione del valore dell'item.

Ora è possibile aggiungere più fasi di pre-elaborazione Verifica valore non supportato. Si noti che alla fine della pipeline che verifica lo stato non supportato dell'item può essere presente una sola fase di confronto "qualsiasi errore". Se presente, viene attivata se nessuna delle verifiche specifiche ha trovato o non ha trovato una corrispondenza con il modello appropriato, oppure se è stato trasferito un messaggio di errore modificato: in altre parole, se non è stata applicata alcuna sovrascrittura "Elimina valore" o "Imposta valore su".

Vedere anche: Verifica valore non supportato

Usabilità migliorata per l'aggiornamento di massa dei passaggi di pre-elaborazione

Il design precedente del modulo di aggiornamento di massa degli item non era sufficientemente chiaro riguardo al fatto che l'aggiornamento dei passaggi di pre-elaborazione avrebbe aggiunto o sostituito i passaggi di pre-elaborazione. Nel nuovo design sono stati aggiunti i pulsanti di opzione Replace e Remove all, rendendo chiaro agli utenti cosa aspettarsi come risultato dell'aggiornamento di massa dei passaggi di pre-elaborazione:

Macro

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

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

Si noti che il supporto per le macro utente è stato rimosso dai nomi degli item e dei prototipi di item in Zabbix 6.0. Ora è stato ripristinato. È inoltre ora possibile cercare il nome di un item con le macro risolte, funzionalità 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 items. Per ogni record nella tabella items viene creato un record corrispondente in 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 sezioni del frontend, ad eccezione della sezione Raccolta dati.

È 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. Ciò si applica a meno che non sia esplicitamente indicato che è prevista solo una macro (ad esempio, durante la configurazione delle macro dell'host o dei filtri delle regole di low-level discovery).

Report pianificati

La funzionalità report pianificati non è più sperimentale.

Report su più pagine

Per i dashboard composti da più pagine, i report ora vengono restituiti con tutte le pagine del dashboard; ogni pagina del PDF corrisponde 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 separata del database per i proxy

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

Anche i dati operativi dei proxy (come ultimo accesso, versione e compatibilità) sono stati spostati dalla tabella host_rtdata e ora sono archiviati 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 della pre-elaborazione ai worker di pre-elaborazione.

Hardening 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 degli utenti può essere disabilitata impostando $ALLOW_HTTP_AUTH=false nel file di configurazione del frontend (zabbix.conf.php).
Il modem GSM per le notifiche SMS può ora essere specificato nel nuovo parametro SMSDevices, limitando la possibilità di configurare erroneamente il percorso del modem GSM dal frontend.

Convalida del file di configurazione

La possibilità di convalidare il file di configurazione è stata aggiunta ai comandi di manutenzione di Zabbix server, proxy, agent, agent 2 e web service. La convalida può essere eseguita utilizzando l'opzione -T --test-config. In caso di convalida 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 durante la compilazione del server, del proxy o dell'agent Zabbix. Se le funzionalità di cURL venivano aggiornate, per poterle utilizzare era necessario ricompilare il componente Zabbix interessato.

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

Vedere anche le note sull'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 network discovery

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

Nella nuova versione, il processo di network discovery è 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 ogni regola, contenente le attività (controlli dei servizi). I controlli dei servizi vengono prelevati ed eseguiti dai discovery worker. Solo i controlli che hanno lo stesso IP e la stessa porta vengono pianificati in sequenza, poiché alcuni dispositivi potrebbero non consentire connessioni simultanee sulla stessa porta.

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

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

Inoltre:

Ora tutti i controlli dei servizi vengono eseguiti in modo asincrono, ad eccezione dei controlli LDAP;
Il numero di controlli asincroni simultanei per ogni tipo di controllo dei servizi (o il numero di worker disponibili per tutti i controlli dei servizi sincroni) è 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 è stato compilato senza libcurl, i controlli HTTP funzioneranno come in precedenza (ovvero come controlli TCP), ma i controlli HTTPS non funzioneranno.
Gli errori nel processo di network discovery verranno ora visualizzati nel frontend (in Data collection > Discovery), ad esempio:
- errori di fping;
- OID SNMP 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.

Finestre modali

Diverse form del frontend vengono ora aperte in finestre modali (pop-up):

configurazione della regola di network discovery;
configurazione dello script globale;
configurazione della correlazione degli eventi;
configurazione del modulo;
configurazione del tipo di media;
configurazione del template;
configurazione del trigger e del prototipo di trigger;
configurazione dell'item e del prototipo di item.

Configurazione avanzata comprimibile

Le caselle di controllo Configurazione avanzata, responsabili della visualizzazione delle opzioni di configurazione avanzate, sono state sostituite da blocchi comprimibili (vedere, ad esempio, Configurazione del connettore, Configurazione del servizio, Configurazione del widget Orologio, ecc.). Questo migliora l'esperienza utente, poiché comprimere questi blocchi e salvare la configurazione non ripristinerà più i valori predefiniti delle opzioni avanzate configurate.

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: URL del riquadro per le impostazioni relative alle mappe geografiche, URL frontend per la configurazione di vari parametri frontend, URL per le mappe di rete e gli elementi delle mappe di rete, URL A-C per i campi dell'inventario degli host, e URL per il widget dashboard URL.

Campi di autenticazione

Il limite di caratteri per i campi di autenticazione Utente/Nome utente e Password è ora di 255 caratteri. Questo si applica alla configurazione dell'autenticazione HTTP per gli item HTTP agent, gli scenari web e i connettori, nonché alla configurazione dell'autenticazione per i controlli semplici, il monitoraggio ODBC, i controlli SSH, i controlli Telnet e il monitoraggio JMX.

Troncamento dei risultati dei test degli item e della pre-elaborazione

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

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 Amministrazione > Registro di audit, ora è possibile abilitare/disabilitare la registrazione di audit delle attività di discovery di basso livello, network discovery e autoregistrazione eseguite dal server (utente System).

Il periodo predefinito di conservazione dei record del registro di audit prima della loro eliminazione da parte dell'housekeeper è stato modificato da 365 giorni a 31 giorni.

Filtro degli ultimi dati

In Monitoraggio > Ultimi dati, 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 sull'aggiornamento alla versione 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 i filtri non impostati (nei widget o nei filtri popup senza dati da visualizzare) sono stati aggiornati. Inoltre, il piè di pagina "Visualizzazione di 0 risultati su 0 trovati" è stato rimosso nei casi in cui non ci sono dati da visualizzare o quando il filtraggio (o l'utilizzo della ricerca globale) non restituisce risultati;
I numeri di versione del frontend Zabbix e del server Zabbix sono ora visualizzabili nella pagina Informazioni di sistema;
Tutte le azioni in cui viene utilizzato il tipo di supporto sono ora visualizzate nell'elenco dei tipi di supporto (colonna Utilizzato nelle azioni). In precedenza, le azioni in cui l'opzione Invia solo a nella configurazione dell'operazione dell'azione era impostata su "Tutti" non venivano incluse nella colonna Utilizzato nelle azioni del tipo di supporto;
È stata aggiunta una nuova opzione di filtraggio alla sezione Ultimi dati: ora consente di filtrare gli item in base al loro stato (supportato/non supportato);
È stata aggiunta una nuova opzione di filtraggio Stato di riconoscimento alla sezione Problemi: ora consente di filtrare i problemi in base al loro stato (non riconosciuto/riconosciuto/riconosciuto da me);
È stato aggiunto il pulsante standard di chiusura delle finestre popup destinate alla configurazione e all'aggiornamento di massa degli elementi e delle forme delle mappe;
La configurazione delle autorizzazioni dei gruppi di utenti e dei tag per filtrare i problemi visualizzabili è stata perfezionata. Ora è possibile selezionare contemporaneamente più gruppi di host/template per assegnare loro le stesse autorizzazioni;
Le notifiche globali posticipate in un browser verranno ora posticipate in tutti i browser/dispositivi in cui l'utente ha effettuato l'accesso;
Il parametro Sovrascrivi host nel widget Valore dell'item è stato spostato prima della sezione Configurazione avanzata per migliorarne l'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 unici per RHEL e le distribuzioni basate su RHEL. Ora vengono utilizzati pacchetti separati per RHEL e per ciascuno dei derivati sopra menzionati, al fine di 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.

Quali sono i prossimi passi?

6 Novità di Zabbix 7.0.1

Docs

5 Novità di Zabbix 7.0.0

Licenza AGPL-3.0

Controllo degli aggiornamenti software