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

Sidebar

Zabbix Summit 2022
Register for Zabbix Summit 2022

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

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

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

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 l'état
  4. La connexion TCP est fermée

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.

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.