2 Diffusion en continu 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 processus du serveur Zabbix sont responsables de la diffusion des données : connector manager et connector worker. Un élément interne Zabbix zabbix[connector_queue] permet de surveiller le nombre de valeurs mises en file d’attente dans la file du connecteur.

Configuration

Les étapes suivantes sont nécessaires pour configurer le streaming de données vers un système externe :

1. Disposer d’un système distant configuré pour recevoir les données de Zabbix. À cette fin, les outils suivants sont disponibles :

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

2. Définissez le nombre requis de workers de connecteur dans Zabbix en ajustant le paramètre StartConnectors dans zabbix_server.conf. Le nombre de workers de connecteur doit correspondre (ou être supérieur si le nombre de sessions simultanées est supérieur à 1) au nombre de connecteurs configuré dans le frontend Zabbix. Redémarrez ensuite Zabbix server.

3. Configurez un nouveau connecteur dans le frontend Zabbix (Administration > General > Connectors) et rechargez 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 bootstrap 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 IP peuvent être résolus vers des adresses de bouclage (par exemple 127.0.0.1/localhost) ou être normalisés par le client, ce qui peut rendre ces avertissements trompeurs. Pour réduire toute confusion, assurez-vous 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 récepteur s’effectue via HTTP en utilisant l’API REST, NDJSON, « Content-Type: application/x-ndjson ».

Pour plus de détails, voir Protocole d’export JSON délimité par des sauts de ligne.

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, toute autre valeur indiquant des requêtes en échec.

Exemple de réussite :

localhost:8080/v1/history": HTTP/1.1 200 OK
Date: Wed, 11 Jan 2023 16:40:30 GMT
Content-Length: 0

Exemple avec des erreurs :

localhost:8080/v1/history": HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json
Date: Wed, 11 Jan 2023 17:07:36 GMT
Content-Length: 55

{"error":"invalid character '{' after top-level value"}