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.

Zabbix utiliza un protocolo de comunicación basado en JSON para comunicarse con el Agente Zabbix.

Ver también: Detalles del protocolo del Agente Zabbix 2.

Comprobaciones pasivas

Una comprobación pasiva es una simple solicitud de datos. El servidor Zabbix o el proxy preguntan por algunos datos (por ejemplo, carga de CPU) y el agente Zabbix devuelve el resultado al servidor.

Solicitud de servidor

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

<clave de métrica>

Respuesta del agente

<DATOS>[\0<ERROR>]

Arriba, la parte entre corchetes es opcional y solo se envía para métricas no compatibles.

Por ejemplo, para métricas compatibles:

1. El servidor abre una conexión TCP
2. El servidor envía <HEADER><DATALEN>agent.ping
3. El agente lee la solicitud y responde con <ENCABEZADO><DATALEN>1
4. El servidor procesa los datos para obtener el valor, '1' en nuestro caso.
5. La conexión TCP se cierra

Para métricas no compatibles:

1. El servidor abre una conexión TCP
2. El servidor envía <HEADER><DATALEN>vfs.fs.size[/nono]
3. El agente lee la solicitud y responde con <HEADER><DATALEN>ZBX_NOTSUPPORTED\0No se puede obtener información del sistema de archivos: [2] No existe tal archivo o directorio
4. El servidor procesa datos, cambia el estado de la métrica a no compatible con el mensaje de error especificado
5. La conexión TCP se cierra

Failover to old protocol

To make sure that Zabbix server or proxy can work with agents from pre-7.0 versions, which have plaintext protocol, a failover to the old protocol is implemented.

Passive checks are performed using the JSON protocol (7.0 and later) after restart or when the interface configuration is changed. If no valid JSON is received in response (agent sent "ZBX_NOTSUPPORTED"), Zabbix will cache the interface as old protocol and retry the check by sending only the item key.

Note that every hour Zabbix server/proxy will again try working with the new protocol with all interfaces, falling back to the old protocol if required.

Comprobaciones activas

Las comprobaciones activas requieren un procesamiento más complejo. El agente primero debe recuperar del servidor(es) una lista de métricas para su procesamiento independiente.

Los servidores desde los que obtener las comprobaciones activas se enumeran en el parámetro 'ServerActive' del archivo de configuración del agente. La frecuencia de preguntar para estas comprobaciones se establece mediante 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 codificados.

Luego, el agente envía periódicamente los nuevos valores a los servidores.

Obteniendo la lista de métricas

Solicitud del agente

La solicitud de comprobaciones activas se utiliza para obtener las comprobaciones activas que procesará el agente. El agente envía esta solicitud al inicio y luego con intervalos de RefreshActiveChecks.

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

Respuesta del servidor

El servidor envía la respuesta de comprobaciones activas al agente después de procesar la solicitud de comprobaciones activas.

{
         "response": "success",
         "data": [
           {
             "key": "log[/home/zabbix/logs/zabbix_agentd.log]",
             "key_orig": "log[/home/zabbix/logs/zabbix_agentd.log]",
             "ítemid": 1234,
             "delay": "30s",
             "lastlogsize": 0,
             "mtime": 0
           },
           {
             "key": "agent.version",
             "key_orig": "agent.version",
             "ítemid": 5678,
             "retraso": "10 m",
             "lastlogsize": 0,
             "mtime": 0
           }
         ],
         "config_revision": 2
       }

El servidor debe responder con éxito.

Por ejemplo:

1. El agente abre una conexión TCP
2. El agente solicita la lista de comprobaciones.
3. El servidor responde con una lista de métricas (clave de métrica, retraso)
4. El agente analiza la respuesta.
5. La conexión TCP se cierra
6. El agente inicia la recopilación periódica de datos.

Envío de datos recopilados

El agente envía

La solicitud de datos del agente contiene los valores de las métricas recopiladas.

{
         "request": "agent data",
         "data": [
           {
             "host": "servidor Zabbix",
             "key": "agent.version",
             "value": "2.4.0",
             "clock": 1400675595,
             "ns": 76808644
           },
           {
             "host": "servidor Zabbix",
             "key": "log[/home/zabbix/logs/zabbix_agentd.log]",
             "lastlogsize": 112,
             "value": " 19845:20140621:141708.521 Iniciando el agente Zabbix [<nombre de host>]. Zabbix 2.4.0 (revisión 50000).",
             "clock": 1400675595,
             "ns": 77053975
           }
         ],
         "session": "1234456akdsjhfoui"
       }

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

Respuesta del servidor

El servidor envía la respuesta de datos del agente al agente después de procesar la solicitud de datos del agente.

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

Por ejemplo:

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

Observe cómo en el ejemplo anterior el estado no admitido para vfs.fs.size[/nono] se indica mediante el valor de "estado" de 1 y el mensaje de error en la propiedad "valor".

Mensaje de latido

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

Se utiliza para monitorear la disponibilidad de comprobaciones activas.

{
         "request": "active check heartbeat",
         "host": "servidor Zabbix",
         "heartbeat_freq": 60
       }

Protocolo XML más antiguo