Protocolos de comprobación pasiva y activa

Esta sección proporciona detalles del protocolo sobre las comprobaciones pasivas y activas realizadas por Zabbix agent y Zabbix agent 2.

Zabbix utiliza un protocolo de comunicación basado en JSON para comunicarse con los agents.

Los protocolos de Zabbix agent y Zabbix agent 2 se han unificado desde Zabbix 7.0. La diferencia entre las solicitudes/respuestas de Zabbix agent y Zabbix agent 2 se expresa mediante el valor de la etiqueta "variant".

Comprobaciones pasivas

Una comprobación pasiva es una simple solicitud de datos. El server o proxy de Zabbix solicita algunos datos (por ejemplo, la carga de CPU) y el agent de Zabbix envía el resultado al server.

Las comprobaciones pasivas se ejecutan de forma asíncrona: no es necesario recibir la respuesta a una solicitud antes de iniciar otras comprobaciones. La resolución DNS también es asíncrona.

El agente de sondeo intentará conectarse a todas las direcciones devueltas por la búsqueda DNS. Esto garantiza que, si una dirección IP no está disponible, el sondeador intentará la siguiente dirección disponible, lo que aumenta la probabilidad de una conexión correcta. Esta mejora se aplica tanto al server como al proxy de Zabbix.

La concurrencia máxima de las comprobaciones asíncronas es 1000 (definida por MaxConcurrentChecksPerPoller).

El número de sondeadores asíncronos de agent se define mediante el parámetro StartAgentPollers.

Solicitud del server

Para la definición de la cabecera y la longitud de los datos, consulte los detalles del protocolo.

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

Respuesta del agent

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

Por ejemplo, para items compatibles:

1. El server abre una conexión TCP
2. El server envía <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"agent.ping","timeout":3}]}
3. El agent lee la solicitud y responde con <HEADER><DATALEN>{"version":"8.0.0","variant":2,"data":[{"value":1}]}
4. El server procesa los datos para obtener el valor, '1' en nuestro caso
5. La conexión TCP se cierra

Para items no compatibles:

1. El server abre una conexión TCP
2. El server envía <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"vfs.fs.size[/nono]","timeout":3}]}
3. El agent lee la solicitud y responde con <HEADER><DATALEN>{"version":"8.0.0","variant":2,"data":[{"error":"Unsupported item key."}]}
4. El server procesa los datos, cambia el estado del item a no compatible con el mensaje de error especificado
5. La conexión TCP se cierra

Conmutación al protocolo antiguo

Para garantizar que Zabbix server o proxy puedan funcionar con agents de versiones anteriores a la 7.2, que utilizan el protocolo de texto plano, se implementa una conmutación al protocolo antiguo.

Las comprobaciones pasivas se realizan usando el protocolo JSON (7.0 y posteriores) después de reiniciar o cuando se cambia la configuración de la interfaz.
Si no se recibe una respuesta JSON válida (el agent envió "ZBX_NOTSUPPORTED"), Zabbix almacenará en caché la interfaz como protocolo antiguo y reintentará la comprobación enviando solo la clave del item.

Tenga en cuenta que cada hora Zabbix server/proxy volverá a intentar trabajar con el nuevo protocolo con todas las interfaces, y recurrirá al protocolo antiguo si es necesario.

Comprobaciones activas

Las comprobaciones activas requieren un procesamiento más complejo. El agent primero debe recuperar del server/proxy una lista de items y/o comandos remotos para su procesamiento independiente.

Los servers/proxies de los que se obtienen las comprobaciones activas se enumeran en el parámetro 'ServerActive' del archivo de configuración del agent. La frecuencia con la que se solicitan estas comprobaciones se establece mediante el parámetro 'RefreshActiveChecks' en el mismo archivo de configuración. Sin embargo, si la actualización de las comprobaciones activas falla, se reintenta después de 60 segundos codificados de forma fija.

El agent luego envía periódicamente los nuevos valores al server(s). Si el agent recibió algún remote commands para ejecutar, el resultado de la ejecución también se enviará. Tenga en cuenta que la ejecución de remote command en un agent activo es compatible desde Zabbix agent 7.0.

Obtención de la lista de items

Solicitud del agent

La solicitud de active checks se utiliza para obtener los active checks que deben ser procesados por el agent.
Esta solicitud es enviada por el agent al iniciarse y luego en intervalos 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"
}

Respuesta del server

La respuesta de active checks es enviada por el server al agent después de procesar la solicitud de active checks.

{
  "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 server debe responder con success.

Por ejemplo:

1. El agent abre una conexión TCP
2. El agent solicita la lista de checks
3. El server responde con una lista de items y comandos remotos a ejecutar
4. El agent analiza la respuesta
5. La conexión TCP se cierra
6. El agent inicia la recopilación periódica de datos y ejecuta comandos remotos (compatible desde Zabbix agent 7.0)

Envío de datos recopilados

Agent envía

La solicitud de datos del agent contiene los valores de item recopilados y los valores de los comandos remotos ejecutados (si los hay).

{
  "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
}

A cada valor se le asigna un ID virtual. El ID del valor es un contador simple ascendente, único dentro de una sesión de datos (identificada por el token de sesión). Este ID se usa para descartar valores duplicados que podrían enviarse en entornos con conectividad deficiente.

Respuesta del server

La respuesta de datos del agent es enviada por el server al agent después de procesar la solicitud de datos del agent.

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

Por ejemplo:

1. El agent abre una conexión TCP
2. El agent envía una lista de valores
3. El server procesa los datos y devuelve el estado
4. La conexión TCP se cierra

Mensaje de heartbeat

El agent envía

El mensaje de heartbeat es enviado por un agent activo al server/proxy de Zabbix cada HeartbeatFrequency segundos (configurado en el archivo de configuración de Zabbix agent/agent 2).

Se utiliza para supervisar la disponibilidad de las comprobaciones activas.

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

Respuesta de redirección

Cuando se ha reasignado un host, el server puede indicar al agent que redirija su heartbeat (y las comprobaciones activas posteriores) a otra instancia de proxy o server.

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

Protocolo XML anterior