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. Zabbix server o proxy solicita algunos datos (por ejemplo, la carga de CPU) y Zabbix agent 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 agente poller intentará conectarse a todas las direcciones devueltas por la búsqueda DNS. Esto garantiza que, si una dirección IP no está disponible, el poller intentará la siguiente dirección disponible, lo que aumenta la probabilidad de una conexión correcta. Esta mejora se aplica tanto a Zabbix server como a proxy.

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

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

Solicitud del server

Para la definición de la longitud de la cabecera y de los datos, consulte protocol details.

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

Respuesta del agent

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

Por ejemplo, para items compatibles:

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

Para items no compatibles:

1. Server abre una conexión TCP
2. Server envía <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"vfs.fs.size[/nono]","timeout":3}]}
3. Agent lee la solicitud y responde con <HEADER><DATALEN>{"version":"7.4.0","variant":2,"data":[{"error":"Unsupported item key."}]}
4. 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 debe recuperar primero del server/proxy una lista de items y/o comandos remotos para su procesamiento independiente.

Los servers/proxies desde 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 fijos.

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 la envía 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": "7.4.0",
  "variant": 2,
  "config_revision": 1,
  "session": "e3dcbd9ace2c9694e1d7bbd030eeef6e"
}

Respuesta del server

La respuesta de active checks la envía el server de vuelta 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": "7.4.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. Agent abre una conexión TCP
2. Agent envía una lista de valores
3. 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": "7.4.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