Gracias al autor de este artículo, Tagawa, experto certificado intermedio de Zabbix .
Una característica del proxy Zabbix es la capacidad de almacenar en caché los datos de monitoreo recopilados si se pierde la conexión con el servidor Zabbix. En este artículo, se utilizará la captura y el análisis de paquetes para mostrar cómo sucede.
01
Configuración de Zabbix y captura del tráfico proxy de Zabbix
Esta es la configuración para esta demostración:
· Un servidor Zabbix en el sitio central (la dirección IPv6 es 2001:db8:1234::bebe, el nombre DNS es zabbixtest.lein.io)
· Un proxy Zabbix "proxy-1" en el sitio remoto (la dirección IPv6 es 2001:db8:9876::fafa, la dirección IPv4 es 10.0.41.65)
· Un cliente Zabbix "Testhost" en el sitio remoto, enviando datos a través del proxy
Para simplificar, el agente solo monitorea un elemento: el tiempo de ejecución del sistema (monitoreando el valor clave del elemento system.uptime, usando el modo activo de Zabbix), y el intervalo de consulta es de 20 segundos.
Este agente es un agente activo que utiliza una base de datos SQLite. El archivo de configuración tiene los siguientes parámetros de configuración no predeterminados:
Server=zabbixtest.lein.ioHostname=Proxy-1DBName=/var/lib/zabbix/zabbix_proxy
Agregue este proxy al front-end del servidor Zabbix y su nombre es "proxy-1".
La versión del servidor y agente Zabbix que se utiliza aquí es 6.4.0beta5. El cliente suele ser compatible con nuevas versiones de servidores y agentes, por lo que aquí se utiliza el cliente existente de la versión 4.0.44.
Después de ejecutar con éxito estas configuraciones, inicie una captura de paquetes en el servidor Zabbix para capturar solo los paquetes utilizados para la comunicación del agente:
sudo tcpdump host 2001:db8:9876::fafa -v -w proxybuffer.pcapDespués de ejecutarse durante unos minutos, los paquetes se eliminan del proxy, lo que crea una "corte de red":
sudo ip6tables -A INPUT -s 2001:db8:9876::fafa -j DROPDeje abierta esta regla de eliminación durante unos minutos, luego elimínela con un comando ip6tables apropiado (en esta demostración sudo ip6tables -D INPUT 1) y detenga la captura de datos de la red después de eso.
02
Análisis del tráfico capturado de Zabbix utilizando Wireshark
Descargue el archivo de captura (proxybuffer.pcap) a su computadora local. Es necesario instalar Wireshark en la computadora local y se debe instalar el disector Zabbix de Wireshark (https://github.com/markkuleinio/wireshark-zabbix-dissectors). Sin este analizador específico, el contenido de los paquetes de Zabbix son simplemente datos binarios ilegibles porque a partir de la versión 4.0 de Zabbix, la comunicación proxy está comprimida.
El mismo archivo de captura se puede descargar aquí:
https://github.com/markkuleinio/wireshark-zabbix-dissectors/raw/master/samples/proxybuffer.pcap
Después de abrir el archivo de captura en Wireshark, primero ingrese zabbix en el filtro de visualización y expanda el campo zabbix en el árbol de protocolo. El resultado es:
Dado que se trata de un proxy de tipo activo que se comunica con el servidor, siempre hay primero un paquete del proxy (solicitud de configuración o datos a enviar), seguido de una respuesta del servidor.
Miremos solo los paquetes provenientes del proxy, que se pueden obtener agregando la dirección IP del proxy en el filtro (arrastre la dirección IP de la columna de origen al filtro de visualización):
Básicamente se muestran dos tipos de paquetes:
· Datos del agente
· Solicitar configuración de proxy
Las solicitudes de configuración son más fáciles de explicar: en Zabbix proxy 6.4 hay un parámetro de configuración ProxyConfigFrequency (en versiones anteriores de Zabbix, este parámetro era ConfigFrequency):
El valor predeterminado es 10 segundos. El flujo que ocurre en cada solicitud de configuración es que el agente dirá "Mi revisión de configuración actual es 1234" y el servidor responderá a eso.
Nota: El concepto de solicitud de configuración en Zabbix 6.4 ha cambiado para usar configuraciones incrementales siempre que sea posible , por lo que los agentes se pueden obtener mucho más rápido en comparación con el valor predeterminado anterior de 3600 segundos o una hora en Zabbix 6.2 y versiones anteriores de configuración actualizada. Para obtener más información, consulte Novedades de Zabbix 6.4.0.
Otro tipo de paquete que se muestra arriba es el paquete proxy. En realidad, también se utiliza para otras cosas además de los datos. En la configuración del proxy, hay un parámetro DataSenderFrequency:
Su valor predeterminado es 1 segundo. Pero como se mencionó anteriormente, incluso después de aumentar el valor de configuración (reduciendo efectivamente la frecuencia de sincronización), el proxy de tipo activo se conectará al servidor cada segundo.
El primer paquete que se muestra arriba (JSON reformateado para una mejor legibilidad):
{"request": "proxy data","host": "Proxy-1","session": "38cca0391f7427d0ad487f75755e7166","version": "6.4.0beta5","clock": 1673190378,"ns": 360076308}
No hay "datos" en el paquete, solo el agente le dice al servidor "¡Oye, todavía estoy aquí!" De esta manera, si el servidor tiene algo que decir, como ejecutar un comando remoto en el agente o en cualquier host, el El agente monitorea, tiene la oportunidad de comunicarse con El agente conduce la conversación.
Como se mencionó anteriormente, la configuración de prueba consta de un solo elemento de monitoreo y se recopila cada 20 segundos, por lo que es natural que no todos los paquetes contengan datos de monitoreo.
Filtre aún más los paquetes agregando zabbix.proxy.data en el filtro de visualización (arrastre el campo "Proxy Data:True" al filtro de visualización) para mostrar solo paquetes proxy:
Ahora, se muestran aproximadamente 20 segundos de paquetes, por lo que debería haber un paquete real, el paquete número 176: es aproximadamente 50 bytes más grande que los otros paquetes, por lo que debe haber algo allí. El siguiente es el contenido del campo Datos del paquete:
{"request": "proxy data","host": "Proxy-1","session": "38cca0391f7427d0ad487f75755e7166","history data": [{"id": 31,"itemid": 44592,"clock": 1673190392,"ns": 299338333,"value": "1686"}],"version": "6.4.0beta5","clock": 1673190393,"ns": 429562969}
Además de los campos anteriores, ahora hay una lista llamada datos históricos que contiene un objeto. Este objeto contiene campos como itemid y valor. El campo itemid contiene la identificación real (ID del elemento) del elemento de monitoreo, que se puede ver en la dirección URL del navegador al editar el elemento de monitoreo en la interfaz de Zabbix. El valor 1686 es el valor real del elemento de monitoreo (tiempo de actividad del sistema en segundos, el host se reinició hace aproximadamente 28 minutos).
Ahora que está bastante seguro de que los paquetes TCP con longitudes de entre 136 y 138 bytes son simplemente paquetes vacíos sin datos del proyecto, puede obtener paquetes interesantes agregando TCP.len>140 al filtro de visualización:
Al observar las marcas de tiempo de los paquetes de red, puede ver que ha habido transmisiones de datos cada 20 segundos hasta las 17:08:30. Luego hay un intervalo de aproximadamente 3,5 minutos, la siguiente transmisión es a las 17:11:53 y luego los datos comienzan a transmitirse nuevamente en intervalos de 20 segundos. El intervalo de 3,5 minutos corresponde a la interrupción de la red provocada manualmente mediante el comando anterior. El paquete después del apagado es más grande que otros paquetes:
{"request": "proxy data","host": "Proxy-1","session": "38cca0391f7427d0ad487f75755e7166","history data": [{"id": 37,"itemid": 44592,"clock": 1673190512,"ns": 316923947,"value": "1806"},{"id": 38,"itemid": 44592,"clock": 1673190532,"ns": 319597379,"value": "1826"},--- JSON truncated ---{"id": 45,"itemid": 44592,"clock": 1673190672,"ns": 345132325,"value": "1966"},{"id": 46,"itemid": 44592,"clock": 1673190692,"ns": 348345312,"value": "1986"}],"auto registration": [{"clock": 1673190592,"host": "Testhost","ip": "10.0.41.66","port": "10050","tls_accepted": 1}],"version": "6.4.0beta5","clock": 1673190708,"ns": 108126335}
Puede ver varios objetos de datos históricos en el mismo paquete del agente. El campo itemid sigue siendo el mismo que antes (44592) y el campo de valor se incrementa en unidades de 20 segundos. Además, las marcas de tiempo (reloj y nanosegundos) se incrementan en consecuencia, por lo que es posible ver cuándo se recopilaron realmente estos valores, aunque el proxy los almacene en caché y los envíe al servidor unos minutos más tarde.
También se puede confirmar viendo los datos más recientes de este elemento de monitoreo en la página principal de Zabbix:
Un bonito gráfico incremental sin espacios ni bordes irregulares.
Para ampliar la explicación, la siguiente información es la situación de interrupción en el registro del proxy de Zabbix (/var/log/zabbix/zabbi_proxy.log en el servidor proxy):
738:20230108:170835.557 Unable to connect to [zabbixtest.lein.io]:10051 [cannot connect to [[zabbixtest.lein.io]:10051]: [4] Interrupted system call]738:20230108:170835.558 Will try to reconnect every 120 second(s)748:20230108:170835.970 Unable to connect to [zabbixtest.lein.io]:10051 [cannot connect to [[zabbixtest.lein.io]:10051]: [4] Interrupted system call]748:20230108:170835.970 Will try to reconnect every 1 second(s)748:20230108:170939.993 Still unable to connect...748:20230108:171040.015 Still unable to connect...738:20230108:171043.561 Still unable to connect...748:20230108:171140.068 Still unable to connect...748:20230108:171147.105 Connection restored.738:20230108:171243.563 Connection restored.
日志一开始看起来很混乱，因为它显示了两次消息。此外，正如前面的数据包列表所证明的那样，第二条“连接已恢复”消息在数据发送已恢复近一分钟后到达。对此的解释是（据我所知）configuration syncer和data sender是代理中的独立进程，如以下链接所述：https://www.zabbix.com/documentation/current/en/manual/concepts/proxy#proxy-process-types。
当查看数据包时，可以看到在17:12:43（即第二条“连接恢复”消息到达时），代理向服务器发送了一个代理配置请求，因此显然data sender每秒都会尝试重新连接（以便于快速恢复监控数据），而config syncer仅2两分钟尝试一次（基于“将尝试每120秒重新连接一次”消息，这对应于停机开始时间17:08:35加上2 x 2分钟，再加上一些额外的秒，可能是因为TCP超时）。
Zabbix服务器日志（/var/log/zabbix/zabbix _server.log）中没有关于此次中断的消息，因为中断不是在TCP会话期间发生的，并且代理处于主动模式（即连接始终由代理启动，而不是由服务器启动），所以在Zabbix服务器进程日志中没有什么特别的记录。
03
代理数据缓存的配置
在Zabbix proxy 6.4的配置文件中，有两个控制缓存的配置参数：
ProxyLocalBuffer
ProxyOfflineBuffer
Proxy Offline Buffer是一个重要参数。如果需要容忍代理服务器和Zabbix服务器之间超过1小时的停机时间（并且代理上有足够的磁盘存储空间），则可以增加该值。因为代理使用单独的数据库（安装代理时进行配置）来存储缓存数据，所以没有单独的文件名或路径可供配置。
Proxy Local Buffer对大多数人来说是无需关注的（默认情况下此参数也是禁用的），因为只有计划将收集的数据直接从代理数据库中提取到其它外部应用程序时，该参数才有用处，并且需要通过一定的灵活性来合理安排从数据库中检索数据以避免影响数据库效能。
延伸阅读
扫一扫｜加入技术交流群
微信号｜17502189550
备注“使用Zabbix年限+企业+姓名”
5000+用户已加入！
一个人走得快，一群人走得远！
本文分享自微信公众号 - Zabbix开源社区（china_zabbix）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。