2 Comprobaciones pasivas y activas del agente

Descripción general

Esta sección proporciona detalles sobre las comprobaciones pasivas y activas realizadas por el agente Zabbix y el agente Zabbix 2.

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

Los protocolos del agente Zabbix y del agente Zabbix 2 se han unificado desde Zabbix 7.0. La diferencia entre las solicitudes/respuestas del agente Zabbix y del agente Zabbix 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 devuelve 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 poller del agent intentará conectarse a todas las direcciones devueltas por la búsqueda DNS. Esto garantiza que, si una dirección IP no es accesible, el poller probará la siguiente dirección disponible, aumentando 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 pollers asíncronos del agent se define mediante el parámetro StartAgentPollers.

Solicitud del server

Para la definición de la longitud del encabezado y 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. Se cierra la conexión TCP

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. Se cierra la conexión TCP

Conmutación por error al protocolo antiguo

Para asegurarse de que el servidor o proxy de Zabbix pueda trabajar con agentes de versiones anteriores a la 7.2, que utilizan el protocolo en texto plano, se implementa una conmutación por error al protocolo antiguo.

Las comprobaciones pasivas se realizan utilizando 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 un JSON válido en respuesta (el agente envió "ZBX_NOTSUPPORTED"), Zabbix almacenará en caché la interfaz como protocolo antiguo y reintentará la comprobación enviando solo la clave de la métrica.

Tenga en cuenta que cada hora el servidor/proxy de Zabbix volverá a intentar trabajar con el nuevo protocolo en todas las interfaces, volviendo 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 agente luego envía periódicamente los nuevos valores al/los servidor(es). Si el agente recibió algún comando remoto para ejecutar, el resultado de la ejecución también se enviará. Tenga en cuenta que la ejecución de comandos remotos en un agente 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

El agent envía

La solicitud de datos del agent contiene los valores de los 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
}

Se asigna un ID virtual a cada valor. El ID de valor es un contador ascendente simple, único dentro de una sesión de datos (identificada por el token de sesión). Este ID se utiliza para descartar valores duplicados que puedan enviarse en entornos con mala conectividad.

Respuesta del server

La respuesta de datos del agent es enviada por el server de vuelta 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 envía el estado de vuelta
4. La conexión TCP se cierra

Mensaje de heartbeat

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 un host ha sido reasignado, 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 antiguo