Durante años, observar el comportamiento interno de un sistema Linux en producción ha implicado instalar agentes, cargar módulos del kernel o resignarse a herramientas tradicionales con visibilidad limitada. Cada nuevo componente de monitorización añadía dependencias, consumía recursos y multiplicaba los puntos de fallo. eBPF ha cambiado esta ecuación de forma radical: permite instrumentar el kernel de manera segura, eficiente y sin modificar el código fuente ni cargar módulos externos.
Para quien administra sistemas, esto significa poder observar tráfico de red, llamadas al sistema, latencias de disco o comportamiento de aplicaciones sin tocar el software en ejecución. No es magia, pero sí representa un salto cualitativo en cómo se puede entender qué ocurre realmente en un servidor sin pagar el precio habitual en complejidad operativa.
Este artículo explica qué es eBPF desde la perspectiva de quien necesita tomar decisiones sobre observabilidad, cuándo tiene sentido adoptarlo, qué problemas resuelve de verdad y dónde están sus límites prácticos.
Qué es eBPF y por qué importa en observabilidad
eBPF (extended Berkeley Packet Filter) es una tecnología del kernel Linux que permite ejecutar programas en un entorno aislado dentro del propio kernel, sin necesidad de compilar módulos ni reiniciar el sistema. Originalmente diseñado para filtrado de paquetes de red, ha evolucionado hasta convertirse en una plataforma general para instrumentación, seguridad y observabilidad.
Lo relevante para administradores es que eBPF permite colocar puntos de observación en prácticamente cualquier parte del sistema: llamadas al sistema, funciones del kernel, eventos de red, operaciones de disco, scheduling de procesos. Todo esto con garantías de seguridad: el kernel verifica cada programa eBPF antes de ejecutarlo, asegurando que no puede bloquear el sistema ni acceder a memoria arbitraria.
En términos prácticos, esto significa poder responder preguntas que antes requerían instrumentación invasiva o eran directamente imposibles: qué procesos están generando más llamadas de red, cuánto tiempo real pasa una operación de lectura en el disco versus en la cola del kernel, qué aplicación está provocando cambios de contexto excesivos. Herramientas como bcc-tools (BPF Compiler Collection) llevan este tipo de diagnóstico al nivel operativo del día a día: incluyen utilidades ya listas para usar que responden exactamente a ese tipo de preguntas sin necesidad de escribir una sola línea de código eBPF. Y todo sin modificar binarios, sin reiniciar servicios y con un impacto en rendimiento medible y controlado.
Observabilidad sin agentes: qué se gana realmente
La promesa de observabilidad sin agentes suena atractiva, pero conviene entender qué significa en la práctica. Tradicionalmente, monitorizar aplicaciones ha implicado instalar agentes que inyectan código, interceptan llamadas o envuelven bibliotecas. Cada agente trae sus propias dependencias, su configuración, su consumo de recursos y su superficie de ataque.
Con eBPF, la instrumentación ocurre en el kernel, independiente de las aplicaciones. Esto tiene varias ventajas operativas inmediatas. No hay que coordinar versiones de agentes con versiones de aplicaciones. No se modifica el comportamiento de los procesos observados. Si un contenedor muere y se recrea, la observabilidad sigue funcionando sin reconfiguración. En entornos con alta rotación de instancias o contenedores, esto reduce significativamente la fricción operativa. No es casualidad que plataformas comerciales como Dynatrace o Datadog usen eBPF internamente para parte de su instrumentación: les permite ofrecer visibilidad automática sin necesidad de modificar las aplicaciones monitorizadas.
Además, eBPF permite observar aspectos del sistema que los agentes tradicionales no pueden ver: el comportamiento del propio kernel, las interacciones entre procesos a nivel de sistema operativo, el uso real de recursos hardware. Es habitual descubrir que un problema de rendimiento no está en la aplicación sino en cómo el kernel gestiona memoria o red, y eBPF hace visible ese nivel.
Sin embargo, esto no significa que los agentes desaparezcan. eBPF no tiene contexto de aplicación: puede ver que un proceso hace una llamada de red, pero no sabe si es parte de una transacción de pago o una consulta de caché. Para correlacionar eventos del sistema con lógica de negocio, sigue siendo necesario algún nivel de instrumentación en la aplicación. La clave está en elegir qué observar desde el kernel y qué desde la aplicación.
Casos de uso donde eBPF aporta valor real
No todos los problemas de observabilidad se resuelven mejor con eBPF. Tiene sentido considerarlo cuando se necesita visibilidad de bajo nivel sin poder modificar las aplicaciones, cuando el coste operativo de los agentes es significativo, o cuando se busca entender comportamientos del sistema que trascienden procesos individuales.
Un caso típico es el análisis de red en entornos de contenedores. Observar tráfico entre servicios sin instrumentar cada contenedor permite detectar patrones de comunicación, latencias de red reales o problemas de congestión que no son visibles desde métricas de aplicación. Cilium es el ejemplo más representativo: reemplaza la capa de red de Kubernetes usando eBPF, lo que le permite implementar políticas de red, balanceo de carga y visibilidad de tráfico con un rendimiento muy superior al de las soluciones basadas en iptables. Pixie, por su parte, ofrece observabilidad automática para Kubernetes también sobre eBPF: captura trazas de peticiones HTTP, consultas SQL o llamadas gRPC sin necesidad de instrumentar los pods.
Otro escenario común es el diagnóstico de problemas de rendimiento intermitentes. Cuando una aplicación sufre picos de latencia impredecibles, bpftrace permite escribir pequeños scripts de trazado de alto nivel que capturan exactamente lo que ocurre en el kernel en ese momento: tiempos de espera en locks, cambios de contexto excesivos, llamadas lentas al sistema de ficheros. Su sintaxis, similar a awk, lo hace accesible sin necesidad de dominar la programación eBPF a bajo nivel.
En seguridad, eBPF permite implementar políticas de comportamiento observando qué hace cada proceso: qué archivos abre, con qué direcciones de red se comunica, qué capacidades del sistema usa. Falco hace exactamente esto: detecta comportamientos anómalos en tiempo de ejecución usando eBPF como motor de captura de eventos. Tetragon, del ecosistema de Cilium, va un paso más allá y permite no solo observar sino también bloquear llamadas al sistema en función de políticas definidas. Ambas herramientas son especialmente útiles en entornos donde no se controla el código de las aplicaciones pero sí se necesita garantizar que no hagan nada inesperado.
Limitaciones y compensaciones reales
eBPF no es una solución universal y tiene limitaciones prácticas que conviene conocer antes de adoptarlo. La primera es la complejidad: escribir programas eBPF directamente requiere conocimientos profundos del kernel Linux. Aunque herramientas como bcc-tools o bpftrace abstraen gran parte de esa complejidad, entender qué está pasando cuando algo falla sigue requiriendo conocimiento técnico considerable.
La segunda limitación es la portabilidad. eBPF depende de versiones específicas del kernel Linux. Funcionalidades avanzadas requieren kernels recientes, lo que puede ser un problema en entornos con sistemas operativos de soporte largo. Además, las estructuras internas del kernel cambian entre versiones, lo que puede romper programas eBPF que dependían de detalles de implementación. La iniciativa BTF (BPF Type Format) y la compilación CO-RE (Compile Once, Run Everywhere) han mejorado mucho esta situación, pero no la han eliminado por completo.
El rendimiento, aunque generalmente bueno, no es gratuito. Cada punto de observación añade latencia, y en sistemas con alta carga o con muchos eventos observados, el impacto puede ser medible. Es habitual que herramientas eBPF permitan ajustar la granularidad de la observación precisamente para controlar este equilibrio entre visibilidad y coste.
Finalmente, eBPF no reemplaza la telemetría de aplicación. Puede ver que una aplicación hace una consulta a base de datos, pero no sabe qué consulta es ni por qué tarda. Para observabilidad completa, sigue siendo necesario combinar instrumentación del kernel con métricas, trazas y logs generados desde la aplicación.
Errores habituales al adoptar eBPF
Un error común es asumir que eBPF resolverá todos los problemas de observabilidad sin necesidad de instrumentar aplicaciones. En realidad, eBPF y telemetría de aplicación son complementarios. Usar solo eBPF deja puntos ciegos en la lógica de negocio; usar solo telemetría de aplicación oculta problemas del sistema operativo.
Otro malentendido frecuente es pensar que eBPF es plug-and-play. Las herramientas modernas han simplificado mucho su uso, pero sigue siendo necesario entender qué se está observando y cómo interpretar los datos. Activar todas las opciones de observación disponibles puede generar un volumen de datos inmanejable y un impacto en rendimiento significativo.
También es habitual subestimar la importancia de las versiones del kernel. Desplegar herramientas eBPF sin verificar compatibilidad puede llevar a fallos silenciosos o comportamientos inesperados. En entornos con kernels antiguos, muchas capacidades avanzadas simplemente no estarán disponibles.
Finalmente, confiar en eBPF para seguridad sin entender sus límites puede crear una falsa sensación de protección. eBPF puede observar y bloquear comportamientos, pero un atacante con privilegios suficientes puede desactivar o manipular programas eBPF. No es un sustituto de otras capas de seguridad.
Criterio para decidir si adoptar eBPF
La decisión de incorporar eBPF a la estrategia de observabilidad debe basarse en necesidades concretas, no en tendencias. Tiene sentido cuando se necesita visibilidad de bajo nivel que las herramientas tradicionales no proporcionan, cuando el coste operativo de los agentes es significativo, o cuando se busca observabilidad uniforme en entornos heterogéneos.
Antes de adoptar eBPF, conviene evaluar si las herramientas existentes ya proporcionan la información necesaria. Muchos problemas de observabilidad se resuelven con métricas bien elegidas, logs estructurados y trazas distribuidas. eBPF aporta valor cuando se necesita ir más allá de lo que la aplicación puede contar sobre sí misma.
También es importante considerar el coste de aprendizaje y mantenimiento. Las herramientas basadas en eBPF han madurado considerablemente, pero siguen requiriendo conocimiento especializado para usarlas eficazmente. En equipos pequeños, este coste puede no justificarse a menos que haya problemas específicos que otras herramientas no puedan resolver.
La estrategia más sensata suele ser incremental: empezar con herramientas eBPF para casos de uso específicos donde el valor es claro —diagnóstico de red, trazado de llamadas al sistema, detección de comportamientos anómalos—, aprender cómo se comportan en el entorno real, y expandir su uso según se demuestre útil. Intentar reemplazar toda la infraestructura de observabilidad de golpe rara vez funciona bien.
Conclusiones prácticas
eBPF representa un cambio fundamental en cómo se puede observar sistemas Linux, pero no es una tecnología mágica que resuelva todos los problemas de observabilidad. Su valor principal está en proporcionar visibilidad de bajo nivel sin modificar aplicaciones, reducir la complejidad operativa de los agentes y permitir observar aspectos del sistema que antes eran inaccesibles.
Para administradores y equipos de SRE, lo importante es entender cuándo eBPF aporta valor real y cuándo otras herramientas son más apropiadas. El ecosistema ya ofrece opciones para distintos niveles de necesidad: desde bcc-tools para diagnóstico puntual, hasta Cilium o Falco para integración en producción. La observabilidad efectiva sigue requiriendo combinar múltiples fuentes de información: métricas de sistema, telemetría de aplicación, logs estructurados y, cuando sea necesario, instrumentación del kernel con eBPF.
La adopción sensata pasa por identificar problemas específicos donde la visibilidad actual es insuficiente, evaluar si eBPF puede resolverlos mejor que las alternativas, y construir experiencia gradualmente. No se trata de seguir una moda tecnológica, sino de añadir capacidades de observabilidad que permitan entender mejor qué ocurre en los sistemas y tomar mejores decisiones operativas.
Para seguir aprendiendo
El ecosistema eBPF ha generado documentación de muy buena calidad en los últimos años. Estos recursos son un buen punto de partida para profundizar:
- «BPF Performance Tools« de Brendan Gregg (O’Reilly): la referencia definitiva del sector. Exhaustivo y técnico, cubre bcc-tools y bpftrace en profundidad. Imprescindible si se va a trabajar seriamente con eBPF.
- «Learning eBPF« de Liz Rice (O’Reilly): más accesible que el de Gregg, orientado a quien quiere entender los fundamentos sin perderse en los detalles del kernel desde el principio. Buen punto de entrada.
- ebpf.io: el sitio oficial del proyecto eBPF, mantenido por la Linux Foundation. Incluye documentación introductoria, casos de uso y un directorio de proyectos del ecosistema actualizado.