2 Verificacions dels agents actius i passius

Vista general

Aquesta secció detalla les verificacions actives i passives que fa l'agent Zabbix.

Zabbix empra un protocol de comunicacions basat en JSON per comunicar-se amb l'agent Zabbix.

Veieu també els detalls del protocol de l'Agent Zabbix 2.

Verificacions passives

Una verificació passiva és una petició simple de dades. El servidor o el proxy Zabbix demanen dades (per exemple, la càrrega del processador) i l'agent Zabbix retorna el resultat al sevidor.

Les comprovacions passives s'executen de manera asíncrona - no cal rebre la resposta a una petició abans que s'iniciïn altres comprovacions. La resolució de DNS també és asíncrona.

La concurrència màxima de comprovacions asíncrones és 1000 (definida per MaxConcurrentChecksPerPoller).

El nombre de pollers d'agents asíncrons el defineix el paràmetre StartAgentPollers.

Petició al servidor

Per la definició de l'encapçalament i la longitud de les dades, veieu els detalls del protocol.

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

Agent response

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

Per exemple, per elements admesos:

1. El servidor obre una connexió TCP
2. El servidor envia <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"agent.ping","timeout":3}]}
3. L'agent llegeix la petició i respon amb <HEADER><DATALEN>{"version":"7.0.0","variant":2,"data":[{"value":1}]}
4. El servidor tracta les dades per obtindre el valor, '1' en el nostre cas
5. Es tanca la connexió TCP

Per els elements no admesos:

1. El servidor obre una connexió TCP

2. El servidor envia <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"vfs.fs.size[/nono]","timeout":3}]}

3. L'agent llegeix la petició i respon amb

   <HEADER><DATALEN>{"version":"7.0.0","variant":2,"data":[{"error":"Unsupported item key."}]}

4. El servidor tracta les dades i modifica l'estat de l'element a no suportat, amb el missatge d'error especificat.

5. Es tanca la connexió TCP

Commuta per error al protocol antic

Per assegurar-vos que el servidor o el proxy Zabbix puguin funcionar amb agents de versions anteriors a la 7.0, que tenen protocol de text pla, s'implementa una migració per error al protocol antic.

Les comprovacions passives es realitzen mitjançant el protocol JSON (7.0 i posteriors) després del reinici o quan es canvia la configuració de la interfície. Si no es rep un JSON vàlid com a resposta (l'agent ha enviat "ZBX_NOTSUPPORTED"), Zabbix emmagatzemarà la interfície com a protocol antic i torna a provar la comprovació enviant només la clau de l'element.

Tingueu en compte que cada hora el servidor/proxy Zabbix tornarà a intentar executar amb el nou protocol amb totes les interfícies, tornant al protocol antic si és necessari.

Verificacions actives

Les verificacions actives tenen un tractament més complexe. L'agent primer ha de recuperar dels servidors una llista d'elements o comandes remotes for independent processingper un tractament independent.

Els servidors/proxys des d'on obtenim les verificacions actives són llistats al paràmetre 'ServerActive' de l'arxiu de configuració de l'agent. La freqüència de les peticions per les verificacions es defineix amb el paràmetre 'RefreshActiveChecks' del mateix arxiu de configuració. Tanmateix, si el refresc de les verificacions actives falla, es tornarà a provar després de 60 segons.

L'agent envia periòdicament els nous valors als servidors. Si l'agent rep qualsevol comanda remota per executar, també enviarà el resultat de l'execució. Tingueu en compte que l'execució de comandes remotes en un agent actiu és compatible des de l'agent Zabbix 7.0.

Obtindre la llista d'elements

Petició de l'agent

La petició de les verificacions actives s'empra per obtindre les verificacions actives a tractar per l'agent. Aquesta petició s'envia per l'agent a l'iniciar, i després amb els intervals RefreshActiveChecks.

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

Resposta del servidor

La resposta de les verificacions actives s'envien per el servidor a l'agent després del tractament de la petició de verificacions 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
           }
         ]
       }

El servidor ha de respondre amb èxit.

Per exemple:

1. L'agent obre una connexió TCP
2. L'agent demana la llista de verificacions
3. El servidor contesta amb una llista d'elements (clau d'element, retard)
4. L'agent analitza la resposta
5. Es tanca la connexió TCP
6. L'agent comença la recollida periòdica de dades i executa comandes remotes (admès des de l'agent de Zabbix 7.0).

Enviament de les dades recollides

Enviament de l'agent

La petició de dades de l'agent conté els valors recollits de l'element.

{
         "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": "1234456akdsjhfoui",
         "host": "Zabbix server",
         "version": "7.0.0",
         "variant": 2
       }

S'assigna un identificador virtual a cada valor. El valor ID és un comptador ascendent simple, únic dins d'una sessió de dades (identificat per el token de la sessió). Aquest identificador s'empra per descartar els valors duplicats que es poden enviar a entorns de connectivitat pobra.

Resposta del servidor

El servidor torna a enviar la resposta de dades de l'agent a l'agent després de processar la petició de dades de l'agent.

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

::: noteimportant Si l'enviament d'alguns valors falla al servidor (per exemple, perquè l'equip o l'element s'ha desactivat o suprimit), l'agent no tornarà a provar d'enviar aquests valors. :::

Per exemple:

1. L'agent obre una connexió TCP
2. L'agent envia una llista de valors
3. El servidor processa les dades i torna a enviar l'estat
4. La connexió TCP es tanca

Tingueu en compte com a l'exemple anterior l'estat no compatible per vfs.fs.size[/nono] s'indica amb el valor "estat" 1 i el missatge d'error a la propietat "valor".

Missatge de Heartbeat

El missatge de heartbeat l'envia un agent actiu al servidor/proxy de Zabbix cada segons de HeartbeatFrequency (configurat a l'arxiu de configuració de l'agent de Zabbix/agent 2).

S'empra per controlar la disponibilitat de controls actius.

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

Antic protocol XML