Por qué eBPF por sí solo no puede resolver problemas de gráficos de dependencia a gran escala

El pipeline de topología de servicios en tiempo real de Netflix procesa cinco millones de registros de flujo eBPF por segundo en miles de microservicios, asegurando un SLA de consulta de sub-segundo en los gráficos de dependencia, reemplazando mapas estáticos que quedan obsoletos antes de que los ingenieros puedan acceder a ellos.

El sistema divide la observabilidad en tres capas de grafos físicamente separadas, cada una almacenada en su propia partición de base de datos. La capa de red ejecuta un FlowExporter sidecar en cada instancia de Titus, capturando flujos a nivel de kernel utilizando puntos de seguimiento TCP de eBPF con menos del uno por ciento de sobrecarga de CPU y memoria. Un IPManAgent escribe mapeos de IP a ID de carga de trabajo directamente en mapas de eBPF en el momento del lanzamiento del contenedor; FlowExporter los lee en kernel, eliminando la atribución errónea basada en el retraso que afectaba los enfoques de flujo de eventos de Sonar anteriores. Estos registros de flujo se envían a Kafka de varias regiones y son procesados por Apache Pekko Streams a través de tres etapas: lote inicial, resolución de identidad IP a servicio y escritura en la base de datos de grafos en la partición de red. Una segunda partición ingiere métricas de IPC de aplicaciones entregadas como Server-Sent Events, proporcionando contexto de punto final y protocolo para servicios instrumentados. Una tercera mantiene rastros distribuidos en almacenamiento de columnas para precisión de comportamiento en rutas muestreadas. Una API de gRPC expone cada capa individualmente o como una unión paralela fusionada, admitiendo recorrido de varios saltos, filtrado por nivel de disponibilidad y paginación.

En producción, la primera versión colapsó debido a que los consumidores de Kafka se quedaron atrás, las instancias agotaron la memoria y el particionado en caliente concentró aproximadamente cien veces el tráfico esperado en nodos individuales. Las pausas de recolección de basura consumieron más CPU que la lógica de negocio de la topología en sí. Colas de memoria sin límites provocaron bloqueos de memoria; el control de flujo basado en descarte produjo gráficos de dependencia incompletos; y las tuberías de lotes entregaron datos de horas atrás, lo que los hizo inútiles en un entorno en el que los servicios se despliegan varias veces al día.

El problema de retropresión se resolvió con flujos reactivos en Pekko Streams. Cuando la etapa final de escritura en la base de datos de grafos se ralentiza, envía una señal hacia arriba a través de las etapas de flujo para pausar el consumidor de Kafka. Los registros esperan en Kafka hasta que la capacidad downstream vuelve, permitiendo que el sistema se degrade de manera elegante sin pérdida de datos. La frescura mejoró de horas a "típicamente dentro de minutos". Las consultas históricas se basan en la agregación de ventanas de tiempo en lugar de instantáneas puntuales, lo que permite a los ingenieros reconstruir estados de topología pasados sin la sobrecarga de almacenamiento de retener copias completas cada vez que se despliega un servicio.

Tres capas independientes significan que ninguna señal es autoritaria: eBPF cubre cada conexión pero carece de semántica de aplicación, IPC está limitado a rutas instrumentadas y los rastros son muestreados. Las consultas que se fusionan a través de capas se ejecutan en paralelo, sin embargo, las publicaciones del Netflix TechBlog no cuantifican las garantías de consistencia entre particiones. El equipo también señala que los flujos reactivos son más difíciles de razonar que el código de bloqueo sincrónico, lo que impone un costo de depuración e incorporación. El trabajo futuro incluye la inyección de eventos de cambio de despliegue y configuración en el grafo y el paso hacia el análisis de causa raíz automatizado, aunque ninguna de ellas está en producción todavía.

El patrón transferible no es "desplegar eBPF" sino esto: ninguna sola secuencia de telemetría cubre el gráfico de dependencia completo, y lo único que hace que una topología de cinco millones de registros por segundo sea viable es la retropresión sobre Kafka, sin ella, la base de datos de grafos o el agente de eBPF es irrelevante.