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 ».

Vérifications passives

Une vérification passive est une simple requête de données. Le serveur ou le proxy Zabbix demande certaines données (par exemple, la charge CPU) 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 requête avant de démarrer d'autres vérifications. La résolution DNS est également asynchrone.

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

La concurrence maximale des vérifications asynchrones est de 1000 (définie par MaxConcurrentChecksPerPoller).

Le nombre d'agent pollers 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 consulter les détails du protocole.

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

Réponse de l'agent

{
  "version": "8.0.0",
  "variant": 2,
  "data": [
    {
      "value": "8.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 requête et répond avec <HEADER><DATALEN>{"version":"8.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 requête et répond avec <HEADER><DATALEN>{"version":"8.0.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 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 de RefreshActiveChecks.

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

Réponse du serveur

La réponse des contrôles actifs est renvoyée par le serveur à l’agent après traitement de la requête de 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 success.

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 démarre 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

Envoi par l’agent

La requête de données de l’agent contient les valeurs d’éléments collectées ainsi que 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": "8.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 à connectivité dégradée.

Réponse du serveur

La réponse de données de l’agent est renvoyée par le serveur à l’agent après 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 pulsation

L'agent envoie

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

Il est utilisé pour surveiller la disponibilité des contrôles actifs.

{
  "request": "active check heartbeat",
  "host": "Zabbix server",
  "heartbeat_freq": 60,
  "version": "8.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 contrôles actifs suivants) vers une autre instance de proxy ou de serveur.

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

Ancien protocole XML