2 Vérifications passives et actives de l'agent

Présentation générale

Cette section fournit des informations détaillées sur les vérifications passives et actives effectuées par l'agent Zabbix et Zabbix agent 2.

Zabbix utilise un protocole de communication basé sur JSON pour communiquer avec les agents.

Les protocoles de l'agent Zabbix et de Zabbix agent 2 sont unifiés depuis Zabbix 7.0. La différence entre les requêtes/réponses de l'agent Zabbix et de Zabbix agent 2 est exprimée par la valeur de la balise « variant ».

Vérifications passives

Une vérification passive est une simple demande de données. Le serveur ou le proxy Zabbix demande certaines données (par exemple, la charge du processeur) et l'agent Zabbix renvoie le résultat au serveur.

Les vérifications passives sont exécutées de manière asynchrone : il n'est pas nécessaire de recevoir la réponse à une demande avant de démarrer d'autres vérifications. La résolution DNS est également asynchrone.

Le poller de l'agent tentera de se connecter à toutes les adresses renvoyées par la recherche DNS. Ainsi, si une adresse IP est inaccessible, le poller essaiera l'adresse disponible suivante, ce qui augmente les chances d'établir une connexion. Cette amélioration s'applique au serveur et au proxy Zabbix.

Le nombre maximal de vérifications asynchrones simultanées est de 1000 (défini par MaxConcurrentChecksPerPoller).

Le nombre de pollers d'agent asynchrones est défini par le paramètre StartAgentPollers.

Demande du serveur

Pour la définition de l'en-tête et de la longueur des données, consultez les détails du protocole.

{
  "request": "passive checks",
  "data": [
    {
      "key": "agent.version",
      "timeout": 3
    }
  ]
}

Réponse de l'agent

{
  "version": "7.0.0",
  "variant": 2,
  "data": [
    {
      "value": "7.0.0"
    }
  ]
}

Par exemple, pour les éléments pris en charge :

1. Le serveur ouvre une connexion TCP
2. Le serveur envoie <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"agent.ping","timeout":3}]}
3. L'agent lit la demande et répond avec <HEADER><DATALEN>{"version":"7.0.0","variant":2,"data":[{"value":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 pris en charge :

1. Le serveur ouvre une connexion TCP
2. Le serveur envoie <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"vfs.fs.size[/nono]","timeout":3}]}
3. L'agent lit la demande et répond avec <HEADER><DATALEN>{"version":"7.0.0","variant":2,"data":[{"error":"Unsupported item key."}]}
4. Le serveur traite les données et définit l'état de l'élément sur « non pris en charge » avec le message d'erreur spécifié
5. La connexion TCP est fermée

Basculement vers l'ancien protocole

Pour garantir que le serveur Zabbix ou le proxy puisse fonctionner avec des agents des versions antérieures à la version 7.0, qui utilisent un protocole en texte brut, un basculement vers l'ancien protocole est implémenté.

Les vérifications passives sont effectuées à l'aide du protocole JSON (version 7.0 et ultérieure) après un redémarrage ou lorsque la configuration de l'interface est modifiée. Si aucune réponse JSON valide n'est reçue (l'agent a envoyé « ZBX_NOTSUPPORTED »), Zabbix met en cache l'interface en tant qu'interface utilisant l'ancien protocole et réessaie la vérification en envoyant uniquement la clé de l'élément.

Notez que toutes les heures, le serveur Zabbix/proxy essaie à nouveau d'utiliser le nouveau protocole avec toutes les interfaces et revient à l'ancien protocole si nécessaire.

Vérifications actives

Les vérifications actives nécessitent un traitement plus complexe. L'agent doit d'abord récupérer auprès du serveur/proxy une liste d'éléments et/ou de commandes distantes pour un traitement indépendant.

Les serveurs/proxys à partir desquels obtenir les vérifications actives sont indiqués dans le paramètre 'ServerActive' du fichier de configuration de l'agent. La fréquence d'interrogation pour ces vérifications est définie par le paramètre 'RefreshActiveChecks' dans le même fichier de configuration. Cependant, si l'actualisation des vérifications actives échoue, une nouvelle tentative est effectuée après 60 secondes codées en dur.

L'agent envoie ensuite périodiquement les nouvelles valeurs au(x) serveur(s). Si l'agent a reçu des commandes à distance à exécuter, le résultat de leur exécution sera également envoyé. Notez que l'exécution de commandes à distance sur un agent actif est prise en charge depuis Zabbix agent 7.0.

Obtention de la liste des éléments

Requête de l’agent

La requête des contrôles actifs est utilisée pour obtenir les contrôles actifs à traiter par l’agent. Cette requête est envoyée par l’agent au démarrage, puis selon les intervalles RefreshActiveChecks.

{
  "request": "active checks",
  "host": "Zabbix server",
  "host_metadata": "mysql,nginx",
  "interface": "zabbix.server.lan",
  "ip": "159.168.1.1",
  "port": 12050,
  "version": "7.0.0",
  "variant": 2,
  "config_revision": 1,
  "session": "e3dcbd9ace2c9694e1d7bbd030eeef6e"
}

Réponse du serveur

La réponse des contrôles actifs est envoyée par le serveur à l’agent après le traitement de la requête des contrôles actifs.

{
  "response": "success",
  "config_revision": 2,
  "data": [
    {
      "key": "system.uptime",
      "itemid": 1234,
      "delay": "10s",
      "lastlogsize": 0,
      "mtime": 0
    },
    {
      "key": "agent.version",
      "itemid": 5678,
      "delay": "10m",
      "lastlogsize": 0,
      "mtime": 0,
      "timeout": "30s"
    }
  ],
  "commands": [
    {
      "command": "df -h --output=source,size / | awk 'NR>1 {print $2}'",
      "id": 1324,
      "wait": 1
    }
  ]
}

Le serveur doit répondre avec succès.

Par exemple :

1. L’agent ouvre une connexion TCP
2. L’agent demande la liste des contrôles
3. Le serveur répond avec une liste d’éléments et de commandes distantes à exécuter
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 et exécute les commandes distantes (prises en charge depuis Zabbix agent 7.0)

Envoi des données collectées

Envoi par l'agent

La demande de données de l'agent contient les valeurs collectées des éléments ainsi que les résultats des commandes distantes exécutées (le cas échéant).

{
  "request": "agent data",
  "data": [
    {
      "id": 1,
      "itemid": 5678,
      "value": "7.0.0",
      "clock": 1712830783,
      "ns": 76808644
    },
    {
      "id": 2,
      "itemid": 1234,
      "value": "69672",
      "clock": 1712830783,
      "ns": 77053975
    }
  ],
  "commands": [
    {
      "id": 1324,
      "value": "16G"
    }
  ],
  "session": "8495cd52070e6ca52b371f29c8574165",
  "host": "Zabbix server",
  "version": "7.0.0",
  "variant": 2
}

Un ID virtuel est attribué à chaque valeur. L'ID de valeur est un simple compteur croissant, unique au sein d'une session de données (identifiée par le jeton de session). Cet ID est utilisé pour ignorer les valeurs dupliquées qui peuvent être envoyées dans des environnements où la connectivité est mauvaise.

Réponse du serveur

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

{
  "response": "success",
  "info": "processed: 2; failed: 0; total: 2; seconds spent: 0.003534"
}

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

Message de pulsation

L'agent envoie

Le message de pulsation est envoyé par un agent actif au serveur/proxy Zabbix toutes les HeartbeatFrequency secondes (configurées dans le fichier de configuration de l'agent Zabbix/l'agent 2).

Il est utilisé pour surveiller la disponibilité des vérifications actives.

{
  "request": "active check heartbeat",
  "host": "Zabbix server",
  "heartbeat_freq": 60,
  "version": "7.0.0",
  "variant": 2
}

Réponse de redirection

Lorsqu'un hôte a été réaffecté, le serveur peut demander à l'agent de rediriger sa pulsation (ainsi que les vérifications actives suivantes) vers une autre instance de proxy ou de serveur.

  {
    "response": "failed",
    "redirect": {
      "revision": 2,
      "address": "192.0.2.1:10055"
    }
  }

Ancien protocole XML