[comment]: # ({cdb0d4ea-b45624e8}) # 2 Diffusion en continu vers des systèmes externes [comment]: # ({/cdb0d4ea-b45624e8}) [comment]: # ({fa81590c-c479d2fd}) #### 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](#protocol)). 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. [comment]: # ({/fa81590c-c479d2fd}) [comment]: # ({695ba0a3-cfad3c2f}) #### Configuration Les étapes suivantes sont nécessaires pour configurer le streaming de données vers un système externe : 1\. Préparez un système distant pour recevoir des données de Zabbix. À cette fin, les outils suivants sont disponibles : - Un exemple de simple [receiver](https://git.zabbix.com/projects/ZT/repos/receiver/browse) qui consigne les informations reçues dans les fichiers `events.ndjson` et `history.ndjson`. - [Kafka connector for Zabbix server](https://git.zabbix.com/projects/ZT/repos/kafka-connector/browse) - un serveur léger écrit en Go, conçu pour transférer les valeurs d'éléments et les événements d'un serveur Zabbix vers un broker Kafka. 2\. Définissez dans Zabbix le nombre requis de workers du connecteur en ajustant le paramètre [`StartConnectors`](/manual/appendix/config/zabbix_server#startconnectors) dans `zabbix_server.conf`. Le nombre de workers du connecteur doit correspondre au nombre de connecteurs configuré dans l'interface Zabbix (ou le dépasser si le nombre de sessions simultanées est supérieur à 1). Ensuite, redémarrez le serveur Zabbix. 3\. Configurez un nouveau connecteur dans l'interface Zabbix (*Administration* > *General* > *Connectors*) et rechargez le cache du serveur avec la commande `zabbix_server -R config_cache_reload`. ![](../../../../assets/en/manual/config/connector.png){width="600"} Les champs obligatoires sont marqués d'un astérisque. |Parameter|Description| |--|--------| |*Name*|Saisissez le nom du connecteur.| |*Data type*|Sélectionnez le type de données à diffuser :
**Item values** - diffuser les valeurs d'éléments de Zabbix vers des systèmes externes ;
**Events** - diffuser les événements de Zabbix vers des systèmes externes.| |*URL*|Saisissez l'URL du receiver. Les macros utilisateur sont prises en charge.| |*Tag filter*|N'exportez que les valeurs d'éléments ou les événements correspondant au filtre de tags. Si aucun filtre n'est défini, tout est exporté.
Il est possible d'inclure ou d'exclure des tags et des valeurs de tags spécifiques. Plusieurs conditions peuvent être définies. La correspondance du nom du tag est toujours sensible à la casse.

Plusieurs opérateurs sont disponibles pour chaque condition :
**Exists** - inclure les noms de tags spécifiés ;
**Equals** - inclure les noms et valeurs de tags spécifiés (sensible à la casse) ;
**Contains** - inclure les noms de tags spécifiés dont les valeurs de tag contiennent la chaîne saisie (correspondance de sous-chaîne, insensible à la casse) ;
**Does not exist** - exclure les noms de tags spécifiés ;
**Does not equal** - exclure les noms et valeurs de tags spécifiés (sensible à la casse) ;
**Does not contain** - exclure les noms de tags spécifiés dont les valeurs de tag contiennent la chaîne saisie (correspondance de sous-chaîne, insensible à la casse).

Il existe deux types de calcul pour les conditions :
**And/Or** - toutes les conditions doivent être remplies, les conditions ayant le même nom de tag seront regroupées par la condition Or ;
**Or** - une seule condition suffit.| |*Type of information*|Sélectionnez le type d'information (numérique (non signé), numérique (flottant), caractère, etc.) permettant de filtrer les valeurs d'éléments que le connecteur doit diffuser.
Ce champ est disponible si *Data type* est défini sur "Item values".| |*HTTP authentication*|Sélectionnez l'option d'authentification :
**None** - aucune authentification n'est utilisée ;
**Basic** - authentification de base utilisée ;
**NTLM** - authentification NTLM ([Windows NT LAN Manager](http://en.wikipedia.org/wiki/NTLM)) utilisée ;
**Kerberos** - authentification Kerberos utilisée (voir aussi : [Configuring Kerberos with Zabbix](/manual/appendix/items/kerberos)) ;
**Digest** - authentification Digest utilisée ;
**Bearer** - authentification Bearer utilisée.| |*Username*|Saisissez le nom d'utilisateur (jusqu'à 255 caractères). Les macros utilisateur sont prises en charge.
Ce champ est disponible si *HTTP authentication* est défini sur "Basic", "NTLM", "Kerberos" ou "Digest".| |*Password*|Saisissez le mot de passe de l'utilisateur (jusqu'à 255 caractères). Les macros utilisateur sont prises en charge.
Ce champ est disponible si *HTTP authentication* est défini sur "Basic", "NTLM", "Kerberos" ou "Digest".| |*Bearer token*|Saisissez le jeton Bearer. Les macros utilisateur sont prises en charge.
Ce champ est disponible et obligatoire si *HTTP authentication* est défini sur "Bearer".| |*Advanced configuration*|Cliquez sur l'en-tête *Advanced configuration* pour afficher les options de configuration avancées (voir ci-dessous).| |*Max records per message*|Spécifiez le nombre maximal de valeurs ou d'événements pouvant être diffusés dans un seul message.| |*Concurrent sessions*|Sélectionnez le nombre de processus d'envoi à exécuter pour ce connecteur. Jusqu'à 100 sessions peuvent être spécifiées ; la valeur par défaut est "1".| |*Attempts*|Nombre de tentatives de diffusion des données. Jusqu'à 5 tentatives peuvent être spécifiées ; la valeur par défaut est "1".| |*Attempt interval*|Spécifiez combien de temps le connecteur doit attendre après une tentative infructueuse de diffusion des données. Jusqu'à 10 s peuvent être spécifiées ; la valeur par défaut est "5s".
Ce champ est disponible si *Attempts* est défini sur "2" ou plus.
Les tentatives infructueuses sont celles où l'établissement d'une connexion a échoué, ou lorsque le code de réponse HTTP n'est pas 200, 201, 202, 203, 204. Les nouvelles tentatives sont **déclenchées** en cas d'erreurs de communication ou lorsque le code de réponse HTTP n'est pas 200, 201, 202, 203, 204, 400, 401, 403, 404, 405, 415, 422. Les redirections sont suivies, donc 302 -> 200 est une réponse positive ; tandis que 302 -> 503 déclenchera une nouvelle tentative.| |*Timeout*|Spécifiez le délai d'attente du message (1 à 60 secondes, valeur par défaut - 5 secondes).
Les suffixes de temps sont pris en charge, par exemple 30s, 1m. Les macros utilisateur sont prises en charge.| |*HTTP proxy*|Vous pouvez spécifier un proxy HTTP à utiliser au format suivant :
`[protocol://][username[:password]@]proxy.example.com[:port]`
Les macros utilisateur sont prises en charge.

Le préfixe facultatif `protocol://` peut être utilisé pour spécifier des protocoles de proxy alternatifs (la prise en charge du préfixe de protocole a été ajoutée dans cURL 7.21.7). Sans protocole spécifié, le proxy sera traité comme un proxy HTTP. Par défaut, le port 1080 sera utilisé.

Si *HTTP proxy* est spécifié, le proxy remplacera les variables d'environnement liées au proxy, telles que `http_proxy`, `HTTPS_PROXY`. S'il n'est pas spécifié, le proxy ne remplacera pas les variables d'environnement liées au proxy. La valeur saisie est transmise telle quelle, sans vérification de cohérence.
Vous pouvez également saisir une adresse de proxy SOCKS. Si vous spécifiez le mauvais protocole, le connecteur ne pourra pas diffuser les valeurs d'éléments ou les événements depuis Zabbix.

Notez que seule l'authentification simple est prise en charge avec le proxy HTTP.| |*SSL verify peer*|Cochez la case pour vérifier le certificat SSL du serveur web.
Le certificat du serveur sera automatiquement pris à partir de l'emplacement système de l'autorité de certification (CA). Vous pouvez remplacer l'emplacement des fichiers CA à l'aide du paramètre de configuration du serveur Zabbix ou du proxy [`SSLCALocation`](/manual/appendix/config/zabbix_server#sslcalocation).| |*SSL verify host*|Cochez la case pour vérifier que le champ *Common Name* ou le champ *Subject Alternate Name* du certificat du serveur web correspond.
Cela définit l'option cURL [`CURLOPT_SSL_VERIFYHOST`](http://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYHOST.html).| |*SSL certificate file*|Nom du fichier de certificat SSL utilisé pour l'authentification du client. Le fichier de certificat doit être au format PEM^1^. Les macros utilisateur sont prises en charge.
Si le fichier de certificat contient également la clé privée, laissez le champ *SSL key file* vide. Si la clé est chiffrée, indiquez le mot de passe dans le champ *SSL key password*. Le répertoire contenant ce fichier est spécifié par le paramètre de configuration du serveur Zabbix ou du proxy [`SSLCertLocation`](/manual/appendix/config/zabbix_server#sslcertlocation).| |*SSL key file*|Nom du fichier de clé privée SSL utilisé pour l'authentification du client. Le fichier de clé privée doit être au format PEM^1^. Les macros utilisateur sont prises en charge.
Le répertoire contenant ce fichier est spécifié par le paramètre de configuration du serveur Zabbix ou du proxy [`SSLKeyLocation`](/manual/appendix/config/zabbix_server#sslkeylocation).| |*SSL key password*|Mot de passe du fichier de clé privée SSL. Les macros utilisateur sont prises en charge.| |*Description*|Saisissez la description du connecteur.| |*Enabled*|Cochez la case pour activer le connecteur.| 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é : ```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 ``` 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 en adresses loopback (par exemple `127.0.0.1`/`localhost`) ou être normalisés par le client, ce qui peut rendre ces avertissements trompeurs. Pour réduire la 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 et les `advertised.listeners` des brokers, et privilégiez les adresses qui se résolvent vers l'adresse annoncée du broker. [comment]: # ({/695ba0a3-cfad3c2f}) [comment]: # ({3208b284-b67df609}) #### 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](/manual/appendix/protocols/real_time_export). [comment]: # ({/3208b284-b67df609}) [comment]: # ({fd0d393d-ae5d9204}) ##### Requête du serveur Exemple de diffusion en continu des valeurs d'élément : ```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} ``` Exemple de diffusion en continu des événements : ```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}) ##### 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 : ```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"} ``` Exemple avec des erreurs : ```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})