Por que o eBPF sozinho não pode resolver problemas de gráfico de dependências em escala

A pipeline de topologia de serviço em tempo real da Netflix processa cinco milhões de registros de fluxo eBPF por segundo em milhares de microsserviços, garantindo SLA de consulta de sub-segundo em gráficos de dependências, substituindo mapas estáticos que se tornaram obsoletos antes que os engenheiros pudessem acessá-los.

O sistema divide a capacidade de observação em três camadas de gráficos fisicamente separadas, cada uma armazenada em sua própria partição de banco de dados. A camada de rede executa um FlowExporter sidecar em cada instância Titus, capturando fluxos de nível de kernel usando pontos de rastreamento TCP eBPF com menos de um percentual de sobrecarga de CPU e memória. Um IPManAgent grava mapeamentos IP-para-ID de carga de trabalho diretamente nos mapas eBPF no momento do lançamento do contêiner; o FlowExporter os lê no kernel, eliminando a atribuição baseada em atraso que afetava os antigos métodos de fluxo de eventos do Sonar. Esses logs de fluxo são enviados para Kafka de várias regiões e processados por Apache Pekko Streams através de três estágios - loteamento inicial, resolução de identidade IP-para-serviço e gravação no banco de dados do gráfico - na partição de rede. Uma segunda partição ingere métricas IPC de aplicativo entregues como Server-Sent Events, fornecendo contexto de ponto final e protocolo para serviços instrumentados. Uma terceira mantém rastros distribuídos em armazenamento de coluna para precisão comportamental em caminhos amostrais. Uma API gRPC expõe cada camada individualmente ou como uma união mesclada paralela, suportando navegação de multi-hop, filtragem por nível de disponibilidade e paginação.

Em produção, a primeira versão colapsou devido a consumidores do Kafka atrasando, instâncias esgotando memória e particionamento quente concentrando aproximadamente cem vezes o tráfego esperado em nós individuais. Pausas de coleta de lixo consumiram mais CPU do que a lógica de negócios da topologia em si. Filas de memória sem limites causaram falhas de memória; controle de fluxo baseado em descarte produziu gráficos de dependências incompletos; e pipelines de lote entregavam dados com várias horas de atraso, tornando-os inúteis em um ambiente onde os serviços são implantados várias vezes ao dia.

O problema de backpressure foi resolvido com fluxos reativos no Pekko Streams. Quando a fase de gravação final do banco de dados do gráfico é lenta, sinaliza para a parte upstream nas etapas do fluxo para pausar o consumidor do Kafka. Os registros aguardam no Kafka até que a capacidade downstream retorne, permitindo que o sistema degrade-se graciosamente sem perda de dados. A frescura melhorou de horas para "tipicamente dentro de dezenas de minutos". Consultas históricas confiam na agregação de janelas de tempo em vez de instantâneos de ponto no tempo, permitindo que os engenheiros reconstroem estados de topologia passados sem a sobrecarga de armazenamento de manter cópias completas toda vez que um serviço é implantado.

Três camadas independentes significam que nenhum sinal é autoritário: o eBPF cobre todas as conexões, mas carece de semântica de aplicativo, o IPC está limitado a caminhos instrumentados e os rastros são amostrais. Consultas que se mesclam entre camadas são executadas em paralelo, no entanto, as postagens do TechBlog da Netflix não quantificam garantias de consistência entre partições. A equipe também observa que os fluxos reativos são mais difíceis de serem compreendidos do que o código de bloqueio síncrono, impondo um custo de depuração e integração. Trabalhos futuros incluem a injeção de eventos de mudança de configuração e implantação no gráfico e a mudança em direção à análise automatizada da causa raiz, embora nenhum esteja em produção ainda.

O padrão transferível não é "implantar eBPF", mas sim isso: nenhum fluxo de telemetria individual cobre o gráfico de dependências completo, e a única coisa que torna uma topologia de cinco milhões de registros por segundo sobrevivível é o backpressure sobre Kafka - sem isso, o banco de dados do gráfico ou o agente eBPF é irrelevante.