Antecedentes
Las CDN y los proveedores de nube ofrecen grandes volúmenes de tráfico en Internet y emplean herramientas de monitoreo extensas para garantizar el rendimiento y la fiabilidad. Estos incluyen herramientas que cubren varias capas de distribución de tráfico, como red, servidor, aplicación, etc. TCP/IP representa la mayoría de este tráfico (mientras que el QUIC basado en UDP está en aumento a nivel mundial, sigue siendo una pequeña fracción del tráfico total en comparación con TCP).
Los sockets son abstracciones del sistema operativo que enlazan la conexión cliente-servidor a través de la cual se transmiten los datos. Los problemas de red, por lo tanto, se reflejan directamente en los datos almacenados con cada socket. Por ejemplo, la congestión en la red puede conducir a tiempos de respuesta lentos y un aumento en los tiempos de ida y vuelta (RTT). También es posible que el ancho de banda de la red esté disponible, pero la aplicación está abrumada con demasiadas solicitudes y no puede llenar el búfer con suficientes datos para utilizar completamente el ancho de banda disponible, lo que resulta en una anomalía limitada por la aplicación. A menudo, los servidores manejan múltiples sockets al mismo tiempo, lo que puede conducir a la contención de recursos, poniendo estrés en los recursos del sistema como la CPU y la memoria.
Por lo tanto, el monitoreo del rendimiento de los sockets TCP a escala puede proporcionar una comprensión crítica de los comportamientos del tráfico, como tiempos de respuesta lentos o conexiones perdidas, e identificar casos en los que se pueden hacer mejoras.
Herramientas existentes
La utilidad “ss” en Linux es una herramienta común utilizada para obtener estadísticas de socket. Al igual que “netstat”, ss proporciona un mecanismo más rápido y flexible para obtener información al permitir filtros en estados de socket, protocolos y direcciones. Comenzamos nuestro viaje de monitoreo de socket con ss también. Si bien es una herramienta poderosa para obtener rápidamente una lista de sockets y métricas relevantes, el principal desafío de ss es que puede consumir recursos significativos, especialmente cuando se utiliza en sistemas con un gran número de sockets. Esto puede afectar el rendimiento del sistema y ralentizar otros procesos. Además, la salida ss no es ideal para el análisis, debido al uso inconsistente de clave: Valor, y complica significativamente la capacidad de transmitir datos recopilados de miles de servidores.
Nuestra primera versión de la colección de sockets usando ss era un script bash que se ejecutaba en servidores de caché seleccionados y exportamos la salida de “ss –tcp –info” a un archivo. Este archivo sería entonces rsync-ed a un host bastión desde el cual un script python lo leería, lo analizaría e insertaría en ElasticSearch. Esto hizo el trabajo, pero no estaba cerca de la escala que necesitábamos. La siguiente iteración de este trabajo fue tener un script de python en vivo en los servidores de caché que se llamaría desde una interfaz HTTP y devolver las estadísticas agregadas para ser insertadas en el clúster de ElasticSearch. Este método escaló el cuello de botella de análisis de una ubicación central de back-office al servidor de caché individual, pero resultó en una gran utilización de memoria en servidores con un número significativamente alto de sockets. En última instancia, reconocimos la necesidad de un reemplazo ligero para la parte ss del sistema.
Nuestros requisitos clave para esta nueva herramienta eran que debería ser ligera y ajustarse a la gran cantidad de sockets que tienen nuestros servidores CDN y ser capaz de transmitir datos de vuelta utilizando un mecanismo eficiente, como búferes de protocolo. La herramienta TCP-INFO del MeasurementLab es una gran utilidad implementada en Golang. Sin embargo, está diseñado para rastrear los mismos sockets a lo largo del tiempo. Dado el gran volumen de nuestras conexiones de enchufe, tomamos una decisión de diseño para no rastrear enchufes individuales. En su lugar, haga que cada bucle de votación sea independiente, proporcionando una instantánea del estado actual de los sockets abiertos. El objetivo principal aquí es rastrear el rendimiento general del sistema y no los sockets individuales.
XTCP
Para resolver estos desafíos, presentamos un código abierto xTCP (Extract, export, Xray TCP). XTCP es una utilidad Golang para capturar y transmitir datos de socket a escala. XTCP utiliza Netlink para capturar información de socket, empaqueta los datos en protobufs y los envía a través de un puerto UDP (para ser enviado eventualmente a Kafka, etc) o escribir a NSQ.
Netlink proporciona una interfaz genérica para la comunicación entre el espacio de usuario y el espacio del kernel. Las herramientas de monitoreo de sockets ss, tcp-INFO utilizan NETLINK_INET_DIAG, parte de la familia de protocolos Netlink, para obtener información de sockets del kernel al espacio de usuario (nota de la página man: NETLINK_INET_DIAG fue introducido en Linux 2.6.14 y solo soportaba sockets AF_INET y AF_INET6.En Linux 3,3, fue renombrado a NETLINK_SOCK_DIAG y extendido para soportar sockets AF_UNIX.)
XTCP extrae los datos del kernel TCP INET_DIAG a altas tasas y exporta esos datos a través de protobufs. En una máquina con aproximadamente ~120k sockets, los mensajes de Netlink son aproximadamente ~5-6MB, sin embargo, la salida ASCII de ss es de aproximadamente ~60MB. Además, ss lee desde el kernel en trozos de ~3KB por defecto. XTCP lee fragmentos de 32KB y, por lo tanto, minimiza las llamadas al sistema. XTCP lee los datos del socket de Netlink simultáneamente utilizando varios trabajadores para drenar la cola lo más rápido posible y al mismo tiempo analiza los mensajes de Netlink para su transmisión. Todas estas optimizaciones hacen que la huella de xTCP sea más pequeña para ejecutarse en servidores de caché de producción.
Uso en Edgio
Utilizamos los datos xTCP en gran medida para analizar el rendimiento del cliente. Comúnmente rastreamos RTT y retransmitimos agregados por punto de presencia (POP) y ASN.
En contraste con Aging Rate, TTL nos permite cambiar la capacidad de caché de un elemento en particular. Durante la duración establecida con la función TTL, un elemento no envejece mientras está en el disco, por lo que es menos probable (incluso muy improbable) que sea desalojado. Después de que el TTL expire, el artículo puede comenzar a envejecer ya sea de la manera tradicional LRU o con envejecimiento rápido o envejecimiento lento (dependiendo de cómo lo configura el operador). En la figura siguiente, TTL con envejecimiento lento mantuvo un elemento en el disco hasta el punto en que no superó el umbral de desalojo de caché. En el extremo opuesto, TTL se aseguró de que una transmisión de video en vivo se almacenara en caché durante al menos la duración del evento, pero después de eso se eliminó rápidamente del disco usando el envejecimiento rápido.
Un ejemplo de panel xTCP que muestra RTT, retransmisiones y número de sockets muestreados para POP AGA y CHB para un gran proveedor de EE.UU..
En una publicación anterior del blog, presentamos nuestro pipeline para el ajuste dinámico del control de la congestión para habilitar automáticamente BBR para clientes que tienen un rendimiento inferior y donde sabemos que el mecanismo de BBR sería más útil. Los datos xTCP son la fuente principal para el análisis.
Constantemente estamos encontrando nuevas formas de utilizar los datos xTCP para responder preguntas complejas como el impacto de la congestión y el aprendizaje automático para predecir el rendimiento y detectar anomalías. Planeamos informar sobre dicho análisis de datos de socket en una publicación de blog futura.
Hoy xTCP se une a VFlow (sflow, netflow, ipfix collector) en nuestro conjunto de herramientas de monitoreo de red de código abierto. Esperamos que esto sirva a la comunidad de monitoreo del rendimiento de la infraestructura para la recopilación de datos de socket y esperamos participar activamente en llevar esta herramienta más allá.
Reconocimiento
El éxito y la amplia usabilidad de xTCP son el resultado de las contribuciones de individuos y equipos de todo Edgio. Nos gustaría agradecer especialmente a David Seddon que es el desarrollador inicial de xTCP. Un agradecimiento especial a todos los revisores de código internos y colaboradores por probar, ingerir, paneles y comentarios sobre xTCP.
