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 2 Zabbix.

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

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

Chequeos pasivos

Un chequeo pasivo es una simple solicitud de datos. El server o proxy de Zabbix solicita algunos datos (por ejemplo, la carga de la CPU) y el agent de Zabbix envía el resultado de vuelta al server.

Los chequeos pasivos se ejecutan de forma asíncrona: no es necesario recibir la respuesta a una solicitud antes de que se inicien otros chequeos. La resolución de DNS también es asíncrona.

El agent poller intentará conectarse a todas las direcciones devueltas por la búsqueda de DNS. Esto garantiza que si una dirección IP no es accesible, el poller intentará la siguiente dirección disponible, aumentando la probabilidad de una conexión exitosa. Esta mejora se aplica tanto al server como al proxy de Zabbix.

La concurrencia máxima de chequeos asíncronos 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 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": "7.0.0",
  "variant": 2,
  "data": [
    {
      "value": "7.0.0"
    }
  ]
}

Por ejemplo, para items soportados:

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":"7.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 soportados:

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":"7.0.0","variant":2,"data":[{"error":"Unsupported item key."}]}
4. El server procesa los datos, cambia el estado del item a no soportado con el mensaje de error especificado
5. La conexión TCP se cierra

Conmutación por error al protocolo anterior

Para asegurarse de que el servidor o proxy de Zabbix pueda funcionar con agentes de versiones anteriores a la 7.0, que tienen protocolo de texto sin formato, se implementa una conmutación por error al protocolo anterior.

Las comprobaciones pasivas se realizan utilizando el protocolo JSON (7.0 y posteriores) después del reinicio o cuando se cambia la configuración de la interfaz. Si no se recibe un JSON válido como respuesta (el agente envió "ZBX_NOTSUPPORTED"), Zabbix almacenará en caché la interfaz como protocolo anterior y reintenta la comprobación enviando solo la clave de la métrica.

Tenga en cuenta que cada hora el servidor/proxy Zabbix volverá a intentar trabajar con el nuevo protocolo con todas las interfaces, recurriendo al protocolo anterior si es necesario.

Comprobaciones activas

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

Los servidores/proxies de los que obtener las comprobaciones activas se enumeran en el parámetro 'ServerActive' del archivo de configuración del agente. La frecuencia con la que se solicitan estas comprobaciones la establece el parámetro 'RefreshActiveChecks' en el mismo archivo de configuración. Sin embargo, si falla la actualización de las comprobaciones activas, se vuelve a intentar después de 60 segundos prefijados.

Luego, el agente envía periódicamente los nuevos valores a los servidores. Si el agente recibió algún comando remoto para ejecutar, también se enviará el resultado de la ejecución. Tenga en cuenta que la ejecución remota de comandos en un agente activo se admite desde el agente Zabbix 7.0.

Obtener la lista de items

Solicitud del agent

La solicitud de comprobaciones activas se utiliza para obtener las comprobaciones activas que deben ser procesadas por el agent. Esta solicitud es enviada por el agent al iniciar y luego con los 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.0.0",
  "variant": 2,
  "config_revision": 1,
  "session": "e3dcbd9ace2c9694e1d7bbd030eeef6e"
}

Respuesta del server

La respuesta de comprobaciones activas es enviada por el server de vuelta al agent después de procesar la solicitud de comprobaciones activas.

{
  "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 éxito.

Por ejemplo:

1. El agent abre una conexión TCP
2. El agent solicita la lista de comprobaciones
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 comienza la recopilación periódica de datos y ejecuta los 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 items 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.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 latido

El agente envía

El mensaje de latido es enviado por un agente activo al servidor/proxy de Zabbix cada HeartbeatFrequency segundos (configurado en el archivo de configuración del agente Zabbix/ agente 2).

Se utiliza para monitorizar la disponibilidad de las comprobaciones activas.

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

Respuesta de redirección

Cuando un equipo ha sido reasignado, el servidor puede indicar al agente que redirija su latido (y las comprobaciones activas posteriores) a otra instancia de proxy o servidor.

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

Protocolo XML más antiguo