Streaming verso sistemi esterni

Panoramica

È possibile trasmettere in streaming i valori degli item e gli eventi da Zabbix a sistemi esterni tramite HTTP (vedere i dettagli del protocollo).

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.

Configurazione

Per configurare lo streaming dei dati verso un sistema esterno, sono necessari i seguenti passaggi:

1. Configurare un sistema remoto per ricevere i dati da Zabbix. A questo scopo sono disponibili i seguenti strumenti:

• Un esempio di semplice receiver che registra le informazioni ricevute nei file events.ndjson e history.ndjson.
• Kafka connector for Zabbix server - 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 in Zabbix il numero richiesto di processi worker del connector modificando il parametro StartConnectors in zabbix_server.conf. Il numero di processi worker del connector deve corrispondere al numero di connector configurato nel frontend di Zabbix (o essere superiore se il numero di sessioni simultanee è maggiore di 1). Quindi, riavviare Zabbix server.

3. Configurare un nuovo connector nel frontend di Zabbix (Administration > General > Connectors) e ricaricare la cache del server con il comando zabbix_server -R config_cache_reload.

I campi obbligatori sono contrassegnati da un asterisco.

Quando il connector Kafka è configurato con un elenco separato da virgole di indirizzi dei broker bootstrap (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 appartenenti a cluster Kafka diversi, verrà utilizzato solo il cluster che risponde più rapidamente e gli altri indirizzi verranno registrati come non disponibili; di conseguenza, potrebbero comparire avvisi all'avvio come il seguente anche se il connector è connesso:

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 indirizzi IP possono risolversi in indirizzi di loopback (ad esempio, 127.0.0.1/localhost) oppure essere normalizzati dal client, rendendo 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 valori advertised.listeners dei broker, e preferire gli indirizzi che si risolvono nell'indirizzo pubblicizzato del broker.

Protocollo

La comunicazione tra il server e il receiver avviene tramite HTTP usando REST API, NDJSON, "Content-Type: application/x-ndjson".

Per ulteriori dettagli, vedere Newline-delimited JSON export protocol.

Richiesta del server

Esempio di streaming dei valori degli item:

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:

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}

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:

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:

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"}