2 Vérifications passives et actives de l'agent

Aperçu

Cette section fournit des détails sur les contrôles passifs et actifs effectués par Zabbix agent et Zabbix agent 2.

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

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

Contrôles passifs

Un contrôle passif est une simple requête de données. Le serveur Zabbix ou le proxy demande certaines données (par exemple, la charge CPU) et l'agent Zabbix renvoie le résultat au serveur.

Les contrôles passifs sont exécutés de manière asynchrone - il n'est pas nécessaire de recevoir la réponse à une requête avant que d'autres contrôles ne soient lancés. La résolution DNS est également asynchrone.

Le collecteur de l'agent tentera de se connecter à toutes les adresses renvoyées par la recherche DNS. Cela garantit que si une adresse IP est inaccessible, le collecteur essaiera l'adresse disponible suivante, augmentant ainsi la probabilité d'une connexion réussie. Cette amélioration s'applique à la fois au serveur Zabbix et au proxy.

La concurrence maximale des contrôles asynchrones est de 1000 (définie par MaxConcurrentChecksPerPoller).

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

Requête du serveur

Pour la définition de l'en-tête et de la longueur des données, veuillez vous référer aux détails du protocole.

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

Réponse de l'agent

{
  "version": "7.4.0",
  "variant": 2,
  "data": [
    {
      "value": "7.4.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 requête et répond avec <HEADER><DATALEN>{"version":"7.4.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 requête et répond avec <HEADER><DATALEN>{"version":"7.4.0","variant":2,"data":[{"error":"Unsupported item key."}]}
4. Le serveur traite les données, change l'état de l'élément en 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 ou le proxy Zabbix puisse fonctionner avec des agents des versions antérieures à 7.2, qui utilisent un protocole en texte brut, un basculement vers l’ancien protocole a été mis en place.

Les contrôles passifs sont effectués à l’aide du protocole JSON (7.0 et versions ultérieures) après un redémarrage ou lorsqu’une configuration d’interface est modifiée. Si aucune réponse JSON valide n’est reçue (l’agent a envoyé « ZBX_NOTSUPPORTED »), Zabbix mettra l’interface en cache comme utilisant l’ancien protocole et réessaiera le contrôle en envoyant uniquement la clé de l’élément.

Notez que toutes les heures, le serveur/proxy Zabbix essaiera de nouveau d’utiliser le nouveau protocole avec toutes les interfaces, en revenant à 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 depuis le 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 listés dans le paramètre 'ServerActive' du fichier de configuration de l'agent. La fréquence de demande de ces vérifications est définie par le paramètre 'RefreshActiveChecks' dans ce 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 distantes à exécuter, le résultat de l'exécution sera également envoyé. Notez que l'exécution de commandes distantes 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 de 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 à intervalles définis par RefreshActiveChecks.

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

Réponse du serveur

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

{
  "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 par success.

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 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 (pris en charge depuis Zabbix agent 7.0)

Envoi des données collectées

L'agent envoie

La requête de données de l'agent contient les valeurs des éléments collectées et les valeurs 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.4.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 pourraient être envoyées dans des environnements où la connectivité est médiocre.

Réponse du serveur

La réponse aux données de l'agent est renvoyée par le serveur à l'agent après le traitement de la requête 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 heartbeat

Envoi par l'agent

Le message de heartbeat est envoyé par un agent actif au serveur/proxy Zabbix toutes les HeartbeatFrequency secondes (configurées dans le fichier de configuration Zabbix agent/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.4.0",
  "variant": 2
}

Réponse de redirection

Lorsqu'un hôte a été réaffecté, le serveur peut demander à l'agent de rediriger son heartbeat (et 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