Recientemente, revisé el lado del agente zabbix y descubrí que hay muchas conexiones tcp en el estado TIME_WAIT
Actualmente zabbix usa modo pasivo, pasivo
Es decir, zabbix-server toma la iniciativa para obtener datos de zabbix-agent,
Flujo de trabajo del modo pasivo
Proceso de trabajo:
- Zabbix-Server abre una conexión TCP.
- Zabbix-Server envía una solicitud con clave agent.ping\n.
- Zabbix-Agent acepta esta solicitud y luego responde con datos <HEADER> <DATALEN>.
- Zabbix-Server procesa los datos recibidos.
- Zabbix-Server procesa los datos recibidos
Cuatro procesos de reciclaje:
De acuerdo con las cuatro manos agitadas, después de que zabbix-server reciba el mensaje FIN enviado por zabbix-agent, debe enviar un mensaje ACK a zabbix-agent para confirmar el cierre de la conexión, y luego zabbix-server ingresa al estado TIME_WAIT, esperando para cerrar la conexión, pero aquí Un pozo enorme: ¡el modo pasivo de zabbix no tiene una última ola! Y el modo pasivo de zabbix no admite conexiones largas, es decir, zabbix-agent entrará en un estado TIME_WAIT de 2MSL después de enviar el último mensaje FIN. Esta conexión no se puede reutilizar en dos minutos, lo que significa que habrá una gran cantidad de conexiones en su servidor ¡TIME_WAIT para conexiones tcp!
Solución:
Cambiar el modo zabbix al modo activo:
O active el reciclaje TIME_WAIT del kernel de Linux.
Flujo de trabajo en modo activo:
(1) Zabbix-Agent establece una conexión TCP con Zabbix-Server
(2) Zabbix-Agent solicita una lista de datos para ser monitoreados
(3) Zabbix-Server responde a Zabbix-Agent y envía una lista de elementos
(4) Zabbix-Agent responde a la solicitud
(5) Cierre la conexión TCP después de completar esta sesión
(6) Zabbix-Agent comienza a recopilar datos periódicamente
Establezca los elementos de monitoreo del servidor en modo activo y reemplace la plantilla con una plantilla de modo activo
problema resuelto:
[root@zabbix ipv4]# netstat -anplut| grep 10050|wc -l
4