This is a translation of the original English documentation page. Help us make it better.

3 Vérifications passives et actives des agents

Aperçu

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.

Voir aussi les détails de protocole de l'Agent Zabbix 2.

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.

<item key>

Réponse de l'agent

<DATA>[\0<ERROR>]

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 <HEADER><DATALEN>agent.ping
  3. L'agent lit la requête et répond avec <HEADER><DATALEN>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 <HEADER><DATALEN>vfs.fs.size[/nono]
  3. L'agent lit la demande et répond avec <HEADER><DATALEN>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

Vérifications actives

Les vérifications actives nécessitent un traitement plus complexe. L'agent doit d'abord récupérer sur le(s) serveur(s) une liste d'éléments pour un traitement indépendant.

Les serveurs à partir desquels obtenir les vérifications actives sont répertoriés dans le paramètre 'ServerActive' du fichier de configuration de l'agent. La fréquence des demandes pour ces vérifications est défini par le paramètre 'RefreshActiveChecks' dans le même fichier de configuration. Cependant, si le rafraîchissement des vérifications actives échoue, il sera réessayé après 60 secondes (codées en dur).

L'agent envoie alors périodiquement les nouvelles valeurs au(x) serveur(s).

Si un agent se trouve derrière le pare-feu, vous pouvez envisager d'utiliser uniquement les vérifications actives, car dans ce cas, vous n'auriez pas besoin de modifier le pare-feu pour autoriser les connexions entrantes initiales.

Obtenir la liste des éléments

Requête de l'agent

La requête des vérifications actives est utilisée pour obtenir les vérifications actives à traiter par l'agent. Cette requête est envoyée par l'agent au démarrage, puis avec des intervalles de RefreshActiveChecks.

{
         "request": "active checks",
         "host": "Zabbix server",
         "host_metadata": "mysql,nginx",
         "hostinterface": "zabbix.server.lan",
         "ip": "159.168.1.1",
         "port": 12050
       }
Champ Type Obligatoire Valeur
request string oui active checks
host string oui Nom d'hôte.
host_metadata string non Le paramètre de configuration HostMetadata ou la valeur de métrique HostMetadataItem.
hostinterface string non La valeur métrique du paramètre de configuration HostInterface ou HostInterfaceItem.
ip string non Le paramètre de configuration ListenIP first IP s'il est défini.
port number non La valeur du paramètre de configuration ListenPort si définie et non le port d'écoute par défaut de l'agent.

Réponse du serveur

La réponse des vérifications actives est renvoyée par le serveur à l'agent après le traitement de la requête de vérifications actives.

{
         "response": "success",
         "data": [
           {
             "key": "log[/home/zabbix/logs/zabbix_agentd.log]",
             "key_orig": "log[/home/zabbix/logs/zabbix_agentd.log]",
             "itemid": 1234,
             "delay": "30s",
             "lastlogsize": 0,
             "mtime": 0
           },
           {
             "key": "agent.version",
             "key_orig": "agent.version",
             "itemid": 5678,
             "delay": "10m",
             "lastlogsize": 0,
             "mtime": 0
           }
         ]
       }
Champ Type Obligatoire Valeur
response string oui success | failed
info string non Informations d'erreur en cas d'échec.
data array of objects non Éléments de vérifications actives.
key string non Clé d'élément avec macros étendues.
key_orig string non Clé d'élément sans macro étendue.
itemid number non Identificateur d'élément.
delay string non Intervalle de mise à jour de l'élément.
lastlogsize number non Dernière taille du journal de l'élément.
mtime number non Mtime de l'élément.
refresh_unsupported number non Intervalle d'actualisation des éléments non pris en charge.
regexp array of objects non Expressions régulières globales.
name string non Nom de l'expression régulière globale.
expression string non Expression régulière globale.
expression_type number non Type de l'expression régulière globale.
exp_delimiter string non Délimiteur de l'expression régulière globale.
case_sensitive number non Paramètre global de sensibilité à la casse des expressions régulières.

Le serveur doit répondre avec succès.

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

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.

Envoi des données collectées

Envois de l'agent

La demande de données d'agent contient les valeurs d'élément collectées.

{
         "request": "agent data",
         "data": [
           {
             "host": "Zabbix server",
             "key": "agent.version",
             "value": "2.4.0",
             "clock": 1400675595,
             "ns": 76808644
           },
           {
             "host": "Zabbix server",
             "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).",
             "clock": 1400675595,
             "ns": 77053975
           }
         ],
         "session": "1234456akdsjhfoui"
       }
Champ Type Obligatoire Valeur
request string oui données des agents
session string oui Identifiant de session unique généré à chaque démarrage de l'agent.
data array of objects oui Valeurs des éléments.
id number oui L'identifiant de la valeur (compteur incrémental utilisé pour vérifier les valeurs dupliquées en cas de problèmes réseaux).
host string oui Nom d'hôte.
key string oui La clé de l'élément.
value string non La valeur de l'élément.
lastlogsize number non La dernière taille de journal de l'élément.
mtime number non Le mtime de l'élément.
state number non L'état de l'élément.
source string non Valeur de la source du journal des événements.
eventid number non La valeur eventid du journal des événements.
severity number non La valeur de la sévérité du journal des événements.
timestamp number non La valeur de l'horodatage du journal des événements.
clock number oui La valeur d'horodatage (secondes depuis Epoch).
ns number oui La valeur d'horodatage en nanosecondes.

Un identifiant virtuel est attribué à chaque valeur. L'ID de valeur est un simple compteur croissant, unique au sein d'une session de données (identifié par le jeton de session). Cet ID est utilisé pour supprimer les valeurs en double qui pourraient être envoyées dans des environnements de mauvaise connectivité.

Réponse du serveur

La réponse de données d'agent est renvoyée par le serveur à l'agent après le traitement de la demande de données d'agent.

{
         "response": "success",
         "info": "processed: 2; failed: 0; total: 2; seconds spent: 0.003534"
       }
Champ Type Obligatoire Valeur
response string oui success | failed
info string oui Résultats du traitement des éléments.

::: 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 le statut
  4. La connexion TCP est fermée

Notez que dans l'exemple ci-dessus, le statut non pris en charge pour vfs.fs.size[/nono] est indiqué par la valeur "state" de 1 et le message d'erreur dans la propriété "value".

Le message d'erreur sera réduit à 2048 symboles côté serveur.

Ancien protocole XML

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.