Diffusion vers des systèmes externes

Aperçu

Il est possible de diffuser en continu les valeurs des éléments et les événements de Zabbix vers des systèmes externes via HTTP (voir les détails du protocole).

Le filtre de tags peut être utilisé pour diffuser en continu des sous-ensembles de valeurs d'éléments ou d'événements.

Deux types de processus du serveur Zabbix sont responsables de la diffusion des données : connector manager et connector worker. Un élément interne de Zabbix zabbix[connector_queue] permet de surveiller le nombre de valeurs mises en file d'attente dans la file d'attente du connecteur.

Configuration

Les étapes suivantes sont nécessaires pour configurer la diffusion des données vers un système externe :

1. Disposer d’un système distant configuré pour recevoir les données de Zabbix. Les outils suivants sont disponibles à cet effet :

• Un exemple de récepteur simple qui consigne les informations reçues dans les fichiers events.ndjson et history.ndjson.
• Connecteur Kafka pour le serveur Zabbix - un serveur léger écrit en Go, conçu pour transférer les valeurs des éléments et les événements d’un serveur Zabbix vers un broker Kafka.

2. Définir le nombre requis de processus workers de connecteur dans Zabbix en ajustant le paramètre StartConnectors dans zabbix_server.conf. Le nombre de processus workers de connecteur doit correspondre au nombre de connecteurs configuré dans l’interface Zabbix (ou lui être supérieur si le nombre de sessions simultanées est supérieur à 1). Redémarrer ensuite le serveur Zabbix.

3. Configurer un nouveau connecteur dans l’interface Zabbix (Administration > Général > Connecteurs), puis recharger le cache du serveur avec la commande zabbix_server -R config_cache_reload.

Les champs obligatoires sont marqués d’un astérisque.

Lorsque le connecteur Kafka est configuré avec une liste d’adresses de brokers d’amorçage séparées par des virgules (par exemple, Kafka.URL=kafka1.example.com:9093,kafka2.example.com:9093), le client Kafka se connecte au(x) broker(s) qui répond(ent) en premier et utilise leurs métadonnées de cluster. Si la liste contient des adresses provenant de différents clusters Kafka, seul le cluster répondant le plus rapidement sera utilisé et les autres adresses seront consignées comme indisponibles ; par conséquent, des avertissements au démarrage tels que le suivant peuvent apparaître même si le connecteur est connecté :

kafka cluster connected, but broker(s) "kafka1.example.com:9093, kafka2.example.com:9093" unavailable; will retry on message send if active brokers fail 

Dans certains environnements (réseaux privés, réseaux de conteneurs ou configurations DNS/hosts non standard), les noms d’hôte ou les adresses IP peuvent être résolus vers des adresses de bouclage (par exemple, 127.0.0.1/localhost) ou normalisés par le client, ce qui peut rendre ces avertissements trompeurs. Pour réduire la confusion, vérifiez que toutes les adresses Kafka.URL appartiennent au même cluster Kafka, vérifiez la résolution DNS depuis l’hôte du connecteur ainsi que les advertised.listeners des brokers, et privilégiez les adresses qui se résolvent vers l’adresse annoncée du broker.

Protocole

La communication entre le serveur et le receiver s'effectue via HTTP en utilisant l'API REST, NDJSON, "Content-Type: application/x-ndjson".

Pour plus de détails, consultez Newline-delimited JSON export protocol.

Requête du serveur

Exemple de diffusion en continu des valeurs d'élément :

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}

Exemple de diffusion en continu des événements :

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}

Réponse du récepteur

La réponse se compose du code d'état de la réponse HTTP et de la charge utile JSON. Le code d'état de la réponse HTTP doit être "200", "201", "202", "203" ou "204" pour les requêtes traitées avec succès, sinon il indique un échec de la requête.

Exemple de réussite :

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

Exemple avec des erreurs :

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