Cette section fournit des détails sur les vérifications passives et actives effectuées par l'agent Zabbix.
Zabbix utilise un protocole de communication basé sur JSON pour communiquer avec l'agent Zabbix.
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.
Réponse de l'agent
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 :
Pour les éléments non supportés :
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 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).
Requête de l'agent
Réponse du serveur
{
"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 :
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.
L'agent envoie
{
"request":"agent data",
"session": "12345678901234567890123456789012",
"data":[
{
"host":"<hostname>",
"key":"agent.version",
"value":"2.4.0",
"id": 1,
"clock":1400675595,
"ns":76808644
},
{
"host":"<hostname>",
"key":"log[/home/zabbix/logs/zabbix_agentd.log]",
"lastlogsize":112,
"value":" 19845:20140621:141708.521 Starting Zabbix Agent [<hostname>]. Zabbix 2.4.0 (revision 50000).",
"id": 2,
"clock":1400675595,
"ns":77053975
},
{
"host":"<hostname>",
"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
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 :
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".
Le message d'erreur sera tronqué à 2 048 symboles côté serveur.
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.