Home Artigos técnicos Monitoramento de desempenho de soquete em grande escala com xTCP
Applications

Monitoramento de desempenho de soquete em grande escala com xTCP

About The Author

Outline

Fundo

CDNs e provedores de nuvem fornecem grandes volumes de tráfego na Internet e empregam extensas ferramentas de monitoramento para garantir desempenho e confiabilidade. Estas incluem ferramentas que cobrem várias camadas de entrega de tráfego, como Rede, Servidor, Aplicação, etc. O TCP/IP é responsável pela maioria desse tráfego (enquanto O QUIC baseado em UDP está crescendo globalmente, ele ainda é uma pequena fração do tráfego total em comparação ao TCP).

Sockets são abstrações do sistema operacional que vinculam a conexão cliente e servidor sobre a qual os dados são transmitidos. Os problemas de rede, portanto, são refletidos diretamente nos dados armazenados com cada soquete. Por exemplo, o congestionamento na rede pode levar a tempos de resposta lentos e a um aumento nos tempos de ida e volta (RTT). Também é possível que a largura de banda da rede esteja disponível, mas o aplicativo está sobrecarregado com muitas solicitações e não pode preencher o buffer com dados suficientes para utilizar totalmente a largura de banda disponível, resultando em uma anomalia limitada ao aplicativo. Muitas vezes, os servidores lidam com vários soquetes ao mesmo tempo, o que pode levar à contenção de recursos colocando estresse nos recursos do sistema, como CPU e memória.

Assim, monitorar o desempenho dos soquetes TCP em escala pode fornecer uma compreensão crítica dos comportamentos de tráfego, como tempos de resposta lentos ou conexões interrompidas, e identificar casos em que melhorias podem ser feitas.

Ferramentas existentes

O utilitário “ss” no Linux é uma ferramenta comum usada para obter estatísticas de socket. Semelhante ao “netstat”, o ss fornece um mecanismo mais rápido e flexível para obter informações, permitindo filtros em estados de soquete, protocolos e endereços. Começamos nossa jornada de monitoramento de soquete com ss também. Embora seja uma ferramenta poderosa para obter rapidamente uma lista de soquetes e métricas relevantes, o principal desafio do ss é que ele pode consumir recursos significativos, especialmente quando usado em sistemas com um grande número de soquetes. Isso pode afetar o desempenho do sistema e retardar outros processos. Além disso, a saída ss não é ideal para análise, devido a uma chave inconsistente: Uso de valor, e complica significativamente a capacidade de transmitir dados coletados de milhares de servidores.

Nossa primeira versão da coleção de socket usando ss foi um script bash executado em servidores de cache selecionados que exportamos a saída de “ss -tcp -info” para um arquivo. Esse arquivo seria rsync-ed para um host bastion a partir do qual um script python iria lê-lo, analisar e inseri-lo no Elasticsearch. Isso fez o trabalho, mas não estava perto da escala que precisávamos. A próxima iteração deste trabalho foi ter um script python ativo nos servidores de cache que seria chamado de uma interface HTTP e retornar as estatísticas agregadas de volta para serem inseridas no cluster Elasticsearch. Esse método escalou o gargalo de análise de um local central de back-office para o servidor de cache individual, mas resultou em uma grande utilização de memória em servidores com um número significativamente alto de soquetes. Em última análise, reconhecemos a necessidade de uma substituição leve para a parte ss do sistema.

Nossos principais requisitos para essa nova ferramenta eram que ela deveria ser leve e dimensionada para o grande número de soquetes que nossos servidores CDN possuem e ser capaz de transmitir dados de volta usando um mecanismo eficiente, como buffers de protocolo. A ferramenta TCP-info do MeasurementLab é um grande utilitário implementado no Golang. No entanto, ele é projetado para rastrear os mesmos soquetes ao longo do tempo. Dado o grande volume de nossas conexões de soquete, fizemos uma escolha de design para não rastrear soquetes individuais. Em vez disso, faça com que cada loop de polling seja independente, fornecendo um instantâneo do estado atual dos soquetes abertos. O principal objetivo aqui é rastrear o desempenho geral do sistema e não soquetes individuais.

XTCP

Para resolver esses desafios, apresentamos e de código aberto o xTCP ( Extract, export, Xray TCP). XTCP é um utilitário Golang para capturar e transmitir dados de soquete em escala. O xTCP usa o NetLink para capturar informações de soquete, empacota os dados em protobufs e envia-os através de uma porta UDP (para ser eventualmente enviada para Kafka, etc) ou escreve no NSQ .

O NetLink fornece uma interface genérica para comunicação entre o espaço do usuário e o espaço do kernel. As ferramentas de monitoramento de soquete ss, tcp-info usam NETLINK_INET_DIAG, parte da família de protocolos NetLink, para obter informações de soquete do kernel para o espaço do usuário (nota da página man: NETLINK_INET_DIAG foi introduzido no Linux 2.6.14 e suportado apenas os soquetes AF_INET e AF_INET6. No Linux 3,3, ele foi renomeado para NETLINK_SOCK_DIAG e estendido para suportar sockets AF_UNIX.)

O xTCP extrai dados TCP INET_DIAG do kernel a taxas elevadas e exporta esses dados através de protobufs. Em uma máquina com aproximadamente 120k soquetes, as mensagens NetLink são aproximadamente 5-6MB, no entanto, a saída ASCII do ss é de aproximadamente 60MB. Além disso, ss lê do kernel em blocos de aproximadamente 3KB por padrão. O xTCP lê blocos de 32KB e, assim, minimiza as chamadas do sistema. O xTCP lê os dados do soquete NetLink simultaneamente usando vários trabalhadores para drenar a fila o mais rápido possível e analisa simultaneamente as mensagens do NetLink para streaming. Todas essas otimizações tornam o espaço ocupado do xTCP menor para ser executado em servidores de cache de produção.

Uso em Edgio

Utilizamos dados xTCP fortemente para analisar o desempenho do cliente. Comumente rastreamos RTT e retransmite agregados por Ponto de Presença (Pop) e ASN.

Em contraste com a taxa de envelhecimento, o TTL nos permite alterar a capacidade de cache de um item específico. Para a duração definida usando a função TTL, um item não envelhece enquanto está no disco, por isso é menos provável (mesmo muito improvável) ser despejado. Depois que o TTL expira, o item pode começar a envelhecer na forma tradicional de LRU ou com envelhecimento rápido ou envelhecimento lento (dependendo de como o operador o configura). Na figura abaixo, o TTL com envelhecimento lento manteve um item no disco até o ponto em que não excedeu o limite de despejo de cache. No lado oposto, o TTL garantiu que um fluxo de vídeo ao vivo fosse armazenado em cache por pelo menos a duração do evento, mas depois disso foi rapidamente removido do disco usando o envelhecimento rápido.

Um exemplo de painel xTCP mostrando RTT, retransmite e número de soquetes amostrados para POPs AGA e CHB para um grande provedor dos EUA.

Em um post anterior, apresentamos nosso pipeline para ajuste dinâmico de controle de congestionamento para habilitar automaticamente o BBR para clientes que estão com baixo desempenho e onde sabemos que o mecanismo do BBR seria mais útil. Os dados xTCP são a principal fonte para a análise.

Estamos constantemente encontrando novas maneiras de usar os dados xTCP para responder perguntas complexas, como o impactos do congestionamento e aprendizado de máquina para prever o desempenho e detetar anomalias. Planejamos relatar essa análise de dados de soquete em um post futuro no blog.

Hoje o xTCP se junta ao vFlow (sflow, netflow, ipfix collector) em nosso conjunto de ferramentas de monitoramento de rede de código aberto. Esperamos que isso sirva a comunidade de monitoramento de desempenho de infraestrutura para coleta de dados de soquete e estamos ansiosos para a participação ativa em levar essa ferramenta mais longe.

Confirmação

O sucesso e a ampla usabilidade do xTCP são resultado de contribuições de indivíduos e equipes de toda a Edgio. Gostaríamos de agradecer especialmente a David Seddon, que é o desenvolvedor inicial do xTCP. Agradecimentos especiais a todos os revisores de código internos e colaboradores por testes, ingestão, dashboards e feedback sobre o xTCP.