[comment]: # ({66ceb30e-a5d505ed}) # 3 Vérifications actives et passives des agents [comment]: # ({/66ceb30e-a5d505ed}) [comment]: # ({55d7f0bb-7bd0dd61}) #### Aperçu Cette section fournit des détails sur les vérifications passives et actives effectuées par l'[agent Zabbix](/fr/manual/config/items/itemtypes/zabbix_agent). Zabbix utilise un protocole de communication basé sur JSON pour communiquer avec l'agent Zabbix. [comment]: # ({/55d7f0bb-7bd0dd61}) [comment]: # ({9952fd35-e6db8dd6}) #### Vérifications passives Une vérification passive est une simple demande de données. Le serveur ou le proxy Zabbix demande des données (par exemple, la charge du processeur) et l'agent Zabbix renvoie le résultat au serveur. \*\*Requête du serveur \*\* Pour la définition de l'en-tête et de la longueur des données, veuillez vous reporter aux [détails du protocole](/fr/manual/appendix/protocols/header_datalen). **Réponse de l'agent** [\0] Ci-dessus, la partie entre crochets est facultative et n'est envoyée que pour les éléments non supportés. Par exemple, pour les éléments supportés : 1. Le serveur ouvre une connexion TCP 2. Le serveur envoie **
agent.ping** 3. L'agent lit la requête et répond avec **
1** 4. Le serveur traite les données pour obtenir la valeur, '1' dans notre cas 5. La connexion TCP est fermée Pour les éléments non supportés : 1. Le serveur ouvre une connexion TCP 2. Le serveur envoie **
vfs.fs.size\[/nono\]** 3. L'agent lit la demande et répond avec **
ZBX\_NOTSUPPORTED\\0Cannot obtain filesystem information: \[2\] No such file or directory** 4. Le serveur traite les données et modifie l'état de l'élément à non supporté avec le message d'erreur spécifié. 5. La connexion TCP est fermée [comment]: # ({/9952fd35-e6db8dd6}) [comment]: # ({ec9d3408-91741d89}) #### Vérifications actives Les vérifications actives nécessitent un traitement plus complexe. L'agent doit d'abord extraire du ou des serveurs une liste d'éléments pour un traitement indépendant. Les serveurs à partir desquels les vérifications actives sont effectuées sont répertoriés dans le paramètre 'ServerActive' du [fichier de configuration](/fr/manual/appendix/config/zabbix_agentd) de l'agent. La fréquence à laquelle ces vérifications sont demandées est définie par le paramètre 'RefreshActiveChecks' dans le même fichier de configuration. Cependant, si l'actualisation des vérifications actives échoue, la vérification est réessayée après 60 secondes (codées en dur). L'agent envoie ensuite périodiquement les nouvelles valeurs au(x) serveur(s). [comment]: # ({/ec9d3408-91741d89}) [comment]: # ({7609bbaf-d898e135}) ##### Obtenir la liste des éléments **Requête de l'agent** ``` {.javascript} { "request":"active checks", "host":"" } ``` **Réponse du serveur** ``` {.javascript} { "response":"success", "data":[ { "key":"log[/home/zabbix/logs/zabbix_agentd.log]", "delay":30, "lastlogsize":0, "mtime":0 }, { "key":"agent.version", "delay":600, "lastlogsize":0, "mtime":0 }, { "key":"vfs.fs.size[/nono]", "delay":600, "lastlogsize":0, "mtime":0 } ] } ``` Le serveur doit répondre avec succès. Pour chaque élément renvoyé, toutes les propriétés **clés**, **delay**, **lastlogsize** et **mtime** doivent exister, qu’il s’agisse ou non d’un élément de journal. Par exemple : 1. L'agent ouvre une connexion TCP 2. L'agent demande la liste des vérifications 3. Le serveur répond avec une liste d'éléments (clé d'élément, délai) 4. L'agent analyse la réponse 5. La connexion TCP est fermée 6. L'agent commence la collecte périodique des données ::: noteimportant Notez que des données de configuration (sensibles) peuvent devenir disponibles pour les parties ayant accès au port du trapper du serveur Zabbix lors de l'utilisation d'une vérification active. Cela est possible car tout le monde peut prétendre être un agent actif et demander des données de configuration d'élément. L'authentification n'a pas lieu sauf si vous utilisez les options de [chiffrement](/fr/manual/encryption). ::: [comment]: # ({/7609bbaf-d898e135}) [comment]: # ({79ef2c40-8c5ecfe1}) ##### Envoi des données collectées **L'agent envoie** ``` {.javascript} { "request":"agent data", "session": "12345678901234567890123456789012", "data":[ { "host":"", "key":"agent.version", "value":"2.4.0", "id": 1, "clock":1400675595, "ns":76808644 }, { "host":"", "key":"log[/home/zabbix/logs/zabbix_agentd.log]", "lastlogsize":112, "value":" 19845:20140621:141708.521 Starting Zabbix Agent []. Zabbix 2.4.0 (revision 50000).", "id": 2, "clock":1400675595, "ns":77053975 }, { "host":"", "key":"vfs.fs.size[/nono]", "state":1, "value":"Cannot obtain filesystem information: [2] No such file or directory", "id": 3, "clock":1400675595, "ns":78154128 } ], "clock": 1400675595, "ns": 78211329 } ``` Un identifiant virtuel est attribué à chaque valeur. La valeur ID est un simple compteur croissant unique dans une session de données (identifiée par le jeton de session). Cet ID est utilisé pour supprimer les doublons pouvant être envoyés dans des environnements où la connectivité est médiocre. **Réponse du serveur** ``` {.javascript} { "response":"success", "info":"processed: 3; failed: 0; total: 3; seconds spent: 0.003534" } ``` ::: noteimportant Si l'envoi de certaines valeurs échoue sur le serveur (par exemple, parce que l'hôte ou l'élément a été désactivé ou supprimé), l'agent ne réessayera pas d'envoyer ces valeurs. ::: Par exemple : 1. L'agent ouvre une connexion TCP 2. L'agent envoie une liste de valeurs 3. Le serveur traite les données et renvoie l'état 4. La connexion TCP est fermée Notez que, dans l'exemple ci-dessus, le statut non supporté pour vfs.fs.size\[/nono\] est indiqué par la valeur "state" à 1 et le message d'erreur dans la propriété "value". ::: noteimportant Le message d'erreur sera tronqué à 2 048 symboles côté serveur. ::: [comment]: # ({/79ef2c40-8c5ecfe1}) [comment]: # ({dcc49754-e66043c4}) #### Ancien protocole XML ::: noteclassic Zabbix prendra jusqu'à 16 Mo de données codées en XML Base64, mais une seule valeur décodée ne devrait pas dépasser 64 Ko, sinon elle sera tronquée à 64 Ko lors du décodage. ::: [comment]: # ({/dcc49754-e66043c4})