[comment]: # ({cdb0d4ea-b45624e8}) # 2 Streaming verso sistemi esterni [comment]: # ({/cdb0d4ea-b45624e8}) [comment]: # ({fa81590c-c479d2fd}) #### Panoramica È possibile trasmettere in streaming i valori degli item e gli eventi da Zabbix a sistemi esterni tramite HTTP (vedere i [dettagli del protocollo](#protocol)). Il filtro dei tag può essere utilizzato per trasmettere in streaming sottoinsiemi di valori degli item o eventi. Due tipi di processi del server Zabbix sono responsabili dello streaming dei dati: `connector manager` e `connector worker`. Un item interno di Zabbix `zabbix[connector_queue]` consente di monitorare il numero di valori accodati nella coda del connettore. [comment]: # ({/fa81590c-c479d2fd}) [comment]: # ({695ba0a3-cfad3c2f}) #### Configurazione Per configurare lo streaming dei dati verso un sistema esterno sono necessari i seguenti passaggi: 1\. Predisporre un sistema remoto per la ricezione dei dati da Zabbix. A questo scopo sono disponibili i seguenti strumenti: - Un esempio di semplice [receiver](https://git.zabbix.com/projects/ZT/repos/receiver/browse) che registra le informazioni ricevute nei file `events.ndjson` e `history.ndjson`. - [Kafka connector for Zabbix server](https://git.zabbix.com/projects/ZT/repos/kafka-connector/browse) - un server leggero scritto in Go, progettato per inoltrare i valori degli item e gli eventi da un server Zabbix a un broker Kafka. 2\. Impostare il numero richiesto di worker del connector in Zabbix regolando il parametro [`StartConnectors`](/manual/appendix/config/zabbix_server#startconnectors) in `zabbix_server.conf`. Il numero di worker del connector deve corrispondere al numero di connector configurati in Zabbix frontend (o essere superiore, se le sessioni concorrenti sono più di 1). Quindi, riavviare il server Zabbix. 3\. Configurare un nuovo connector in Zabbix frontend (*Administration* > *General* > *Connectors*) e ricaricare la cache del server con il comando `zabbix_server -R config_cache_reload`. ![](../../../../assets/en/manual/config/connector.png){width="600"} I campi obbligatori sono contrassegnati da un asterisco. |Parameter|Description| |--|--------| |*Name*|Immettere il nome del connector.| |*Data type*|Selezionare il tipo di dati da trasmettere:
**Item values** - trasmette i valori degli item da Zabbix ai sistemi esterni;
**Events** - trasmette gli eventi da Zabbix ai sistemi esterni.| |*URL*|Immettere l'URL del receiver. Sono supportate le macro utente.| |*Tag filter*|Esporta solo i valori degli item o gli eventi che corrispondono al filtro dei tag. Se non impostato, esporta tutto.
È possibile includere ed escludere tag e valori di tag specifici. È possibile impostare più condizioni. La corrispondenza del nome del tag è sempre sensibile alle maiuscole/minuscole.

Per ogni condizione sono disponibili diversi operatori:
**Exists** - include i nomi dei tag specificati;
**Equals** - include i nomi e i valori dei tag specificati (sensibile alle maiuscole/minuscole);
**Contains** - include i nomi dei tag specificati i cui valori contengono la stringa immessa (corrispondenza di sottostringa, non sensibile alle maiuscole/minuscole);
**Does not exist** - esclude i nomi dei tag specificati;
**Does not equal** - esclude i nomi e i valori dei tag specificati (sensibile alle maiuscole/minuscole);
**Does not contain** - esclude i nomi dei tag specificati i cui valori contengono la stringa immessa (corrispondenza di sottostringa, non sensibile alle maiuscole/minuscole).

Esistono due tipi di calcolo per le condizioni:
**And/Or** - tutte le condizioni devono essere soddisfatte, le condizioni con lo stesso nome di tag verranno raggruppate in base alla condizione Or;
**Or** - è sufficiente che una condizione sia soddisfatta.| |*Type of information*|Selezionare il tipo di informazione (numeric (unsigned), numeric (float), character, ecc.) in base al quale filtrare i valori degli item che il connector deve trasmettere.
Questo campo è disponibile se *Data type* è impostato su "Item values".| |*HTTP authentication*|Selezionare l'opzione di autenticazione:
**None** - nessuna autenticazione utilizzata;
**Basic** - viene utilizzata l'autenticazione basic;
**NTLM** - viene utilizzata l'autenticazione NTLM ([Windows NT LAN Manager](http://en.wikipedia.org/wiki/NTLM));
**Kerberos** - viene utilizzata l'autenticazione Kerberos (vedere anche: [Configurazione di Kerberos con Zabbix](/manual/appendix/items/kerberos));
**Digest** - viene utilizzata l'autenticazione Digest;
**Bearer** - viene utilizzata l'autenticazione Bearer.| |*Username*|Immettere il nome utente (fino a 255 caratteri). Sono supportate le macro utente.
Questo campo è disponibile se *HTTP authentication* è impostato su "Basic", "NTLM", "Kerberos" o "Digest".| |*Password*|Immettere la password dell'utente (fino a 255 caratteri). Sono supportate le macro utente.
Questo campo è disponibile se *HTTP authentication* è impostato su "Basic", "NTLM", "Kerberos" o "Digest".| |*Bearer token*|Immettere il token Bearer. Sono supportate le macro utente.
Questo campo è disponibile ed è obbligatorio se *HTTP authentication* è impostato su "Bearer".| |*Advanced configuration*|Fare clic sull'intestazione *Advanced configuration* per visualizzare le opzioni di configurazione avanzate (vedere sotto).| |*Max records per message*|Specificare il numero massimo di valori o eventi che possono essere trasmessi in un singolo messaggio.| |*Concurrent sessions*|Selezionare il numero di processi sender da eseguire per questo connector. È possibile specificare fino a 100 sessioni; il valore predefinito è "1".| |*Attempts*|Numero di tentativi per la trasmissione dei dati. È possibile specificare fino a 5 tentativi; il valore predefinito è "1".| |*Attempt interval*|Specificare per quanto tempo il connector deve attendere dopo un tentativo non riuscito di trasmettere i dati. È possibile specificare fino a 10s; il valore predefinito è "5s".
Questo campo è disponibile se *Attempts* è impostato su "2" o superiore.
I tentativi non riusciti sono quelli in cui la connessione non è stata stabilita oppure il codice di risposta HTTP non è 200, 201, 202, 203, 204. I retry vengono **trigger** in caso di errori di comunicazione o quando il codice di risposta HTTP non è 200, 201, 202, 203, 204, 400, 401, 403, 404, 405, 415, 422. I redirect vengono seguiti, quindi 302 -> 200 è una risposta positiva; mentre 302 -> 503 attiverà un retry.| |*Timeout*|Specificare il timeout del messaggio (1-60 secondi, predefinito - 5 secondi).
Sono supportati i suffissi temporali, ad esempio 30s, 1m. Sono supportate le macro utente.| |*HTTP proxy*|È possibile specificare un proxy HTTP da usare nel seguente formato:
`[protocol://][username[:password]@]proxy.example.com[:port]`
Sono supportate le macro utente.

Il prefisso opzionale `protocol://` può essere usato per specificare protocolli proxy alternativi (il supporto del prefisso del protocollo è stato aggiunto in cURL 7.21.7). Se non viene specificato alcun protocollo, il proxy verrà trattato come proxy HTTP. Per impostazione predefinita, verrà utilizzata la porta 1080.

Se *HTTP proxy* è specificato, il proxy sovrascriverà le variabili di ambiente relative al proxy, come `http_proxy`, `HTTPS_PROXY`. Se non specificato, il proxy non sovrascriverà le variabili di ambiente relative al proxy. Il valore immesso viene passato così com'è, senza alcun controllo di validità.
È inoltre possibile immettere un indirizzo proxy SOCKS. Se si specifica il protocollo errato, il connector non riuscirà a trasmettere i valori degli item o gli eventi da Zabbix.

Si noti che con il proxy HTTP è supportata solo l'autenticazione semplice.| |*SSL verify peer*|Selezionare la casella di controllo per verificare il certificato SSL del web server.
Il certificato del server verrà automaticamente prelevato dalla posizione dell'autorità di certificazione (CA) a livello di sistema. È possibile sovrascrivere la posizione dei file CA utilizzando il parametro di configurazione di Zabbix server o proxy [`SSLCALocation`](/manual/appendix/config/zabbix_server#sslcalocation).| |*SSL verify host*|Selezionare la casella di controllo per verificare che il campo *Common Name* o il campo *Subject Alternate Name* del certificato del web server corrisponda.
Questo imposta l'opzione cURL [`CURLOPT_SSL_VERIFYHOST`](http://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYHOST.html).| |*SSL certificate file*|Nome del file del certificato SSL utilizzato per l'autenticazione del client. Il file del certificato deve essere in formato PEM^1^. Sono supportate le macro utente.
Se il file del certificato contiene anche la chiave privata, lasciare vuoto il campo *SSL key file*. Se la chiave è crittografata, specificare la password nel campo *SSL key password*. La directory contenente questo file è specificata dal parametro di configurazione di Zabbix server o proxy [`SSLCertLocation`](/manual/appendix/config/zabbix_server#sslcertlocation).| |*SSL key file*|Nome del file della chiave privata SSL utilizzato per l'autenticazione del client. Il file della chiave privata deve essere in formato PEM^1^. Sono supportate le macro utente.
La directory contenente questo file è specificata dal parametro di configurazione di Zabbix server o proxy [`SSLKeyLocation`](/manual/appendix/config/zabbix_server#sslkeylocation).| |*SSL key password*|Password del file della chiave privata SSL. Sono supportate le macro utente.| |*Description*|Immettere la descrizione del connector.| |*Enabled*|Selezionare la casella di controllo per abilitare il connector.| Quando il Kafka connector è configurato con un elenco separato da virgole di indirizzi bootstrap broker (ad esempio `Kafka.URL=kafka1.example.com:9093,kafka2.example.com:9093`), il client Kafka si connette al broker o ai broker che rispondono per primi e utilizza i relativi metadati del cluster. Se l'elenco contiene indirizzi di cluster Kafka diversi, verrà utilizzato solo il cluster che risponde più velocemente e gli altri indirizzi verranno registrati come non disponibili; di conseguenza, potrebbero comparire avvisi all'avvio come il seguente, anche se il connector è connesso: ```default kafka cluster connected, but broker(s) "kafka1.example.com:9093, kafka2.example.com:9093" unavailable; will retry on message send if active brokers fail ``` In alcuni ambienti (reti private, reti di container o configurazioni DNS/hosts non standard) i nomi host o gli IP possono essere risolti in indirizzi loopback (ad esempio `127.0.0.1`/`localhost`) oppure essere normalizzati dal client, il che può rendere fuorvianti tali avvisi. Per ridurre la confusione, assicurarsi che tutti gli indirizzi `Kafka.URL` appartengano allo stesso cluster Kafka, verificare la risoluzione DNS dall'host del connector e i `advertised.listeners` dei broker, e preferire indirizzi che si risolvano nell'indirizzo pubblicizzato del broker. [comment]: # ({/695ba0a3-cfad3c2f}) [comment]: # ({3208b284-b67df609}) #### Protocollo La comunicazione tra il server e il receiver avviene tramite HTTP utilizzando REST API, NDJSON, "Content-Type: application/x-ndjson". Per maggiori dettagli, vedere [Protocollo di esportazione JSON delimitato da newline](/manual/appendix/protocols/real_time_export). [comment]: # ({/3208b284-b67df609}) [comment]: # ({fd0d393d-ae5d9204}) ##### Richiesta del server Esempio di streaming dei valori degli item: ```json POST /v1/history HTTP/1.1 Host: localhost:8080 Accept: */* Accept-Encoding: deflate, gzip, br, zstd Content-Length: 628 Content-Type: application/x-ndjson {"host":{"host":"Zabbix server","name":"Zabbix server"},"groups":["Zabbix servers"],"item_tags":[{"tag":"foo","value":"test"}],"itemid":44457,"name":"foo","clock":1673454303,"ns":800155804,"value":0,"type":3} {"host":{"host":"Zabbix server","name":"Zabbix server"},"groups":["Zabbix servers"],"item_tags":[{"tag":"foo","value":"test"}],"itemid":44457,"name":"foo","clock":1673454303,"ns":832290669,"value":1,"type":3} {"host":{"host":"Zabbix server","name":"Zabbix server"},"groups":["Zabbix servers"],"item_tags":[{"tag":"bar","value":"test"}],"itemid":44458,"name":"bar","clock":1673454303,"ns":867770366,"value":123,"type":3} ``` Esempio di streaming degli eventi: ```json POST /v1/events HTTP/1.1 Host: localhost:8080 Accept: */* Accept-Encoding: deflate, gzip, br, zstd Content-Length: 333 Content-Type: application/x-ndjson {"clock":1673454303,"ns":800155804,"value":1,"eventid":5,"name":"trigger for foo being 0","severity":0,"hosts":[{"host":"Zabbix server","name":"Zabbix server"}],"groups":["Zabbix servers"],"tags":[{"tag":"foo_trig","value":"test"},{"tag":"foo","value":"test"}]} {"clock":1673454303,"ns":832290669,"value":0,"eventid":6,"p_eventid":5} ``` [comment]: # ({/fd0d393d-ae5d9204}) [comment]: # ({d6988482-89101d44}) ##### Risposta del receiver La risposta è composta dal codice di stato della risposta HTTP e dal payload JSON. Il codice di stato della risposta HTTP deve essere "200", "201", "202", "203" o "204" per le richieste gestite correttamente, altri per le richieste non riuscite. Esempio di successo: ```json HTTP/1.1 200 OK Content-Type: application/json X-Content-Type-Options: nosniff Date: Tue, 21 Apr 2026 10:13:04 GMT Content-Length: 23 {"response":"success"} ``` Esempio con errori: ```json HTTP/1.1 422 Unprocessable Entity Content-Type: application/json X-Content-Type-Options: nosniff Date: Tue, 21 Apr 2026 12:15:01 GMT Content-Length: 55 {"error":"invalid character '{' after top-level value"} ``` [comment]: # ({/d6988482-89101d44})