La diferencia fundamental es la «intrusividad». Los agentes de monitorización tradicionales, ya sean para APM (Application Performance Monitoring) o para métricas de sistema, funcionan en el espacio de usuario. Esto significa que, para obtener datos del kernel (como llamadas al sistema, operaciones de red o accesos a disco), necesitan realizar constantes cambios de contexto (de espacio de usuario a espacio de kernel y viceversa). Cada uno de estos saltos, aunque pequeños, suma y genera una sobrecarga. Si lo multiplicas por miles de eventos por segundo en un servidor concurrido, el overhead se vuelve tangible.

Además, estos agentes suelen venir en «paquetes» grandes y monolíticos. ¿Quieres monitorizar solo las conexiones TCP? mala suerte, te instalas el agente completo con sus 200MB de dependencias y su consumo de memoria base, aunque no uses el 90% de sus funcionalidades.

eBPF invierte este modelo. En lugar de un agente pesado, cargas «sondas» o programas eBPF extremadamente ligeros y específicos para lo que necesitas.

Estos programas se compilan a un bytecode que es verificado por el kernel antes de cargarse. Este verificador es como un portero de discoteca extremadamente estricto: se asegura de que el programa no pueda caer en bucles infinitos, no acceda a memoria no autorizada ni pueda, en definitiva, colgar el sistema. Una vez aprobado, el JIT (Just-In-Time) compiler del kernel lo traduce a código máquina nativo, haciéndolo increíblemente rápido. El resultado es una monitorización con un impacto en el rendimiento casi nulo, a veces estimado en menos del 1%.

Seamos sinceros, ninguna tecnología es una bala de plata. eBPF nos da superpoderes, pero como siempre, un gran poder conlleva… bueno, ya sabes.

En resumen, eBPF nos da la capacidad de obtener una visibilidad profunda y con un rendimiento que antes era impensable. Sin embargo, exige a cambio una mayor inversión técnica por nuestra parte. Es el paso de ser un simple usuario de herramientas de monitorización a ser un constructor de nuestras propias herramientas, perfectamente adaptadas a nuestras necesidades.

Vale, ya hemos visto el «porqué», ahora vamos a meternos en el fango y ver el «cómo» funciona esto por dentro. Para usar eBPF de verdad y no solo recitar conceptos, hay que entender sus piezas fundamentales. No te preocupes, no hace falta que saques el manual de ensamblador del kernel, pero sí que tengas claros tres o cuatro conceptos que son el motor de toda esta historia. Vamos a desmontar el mecanismo pieza por pieza.

La arquitectura de eBPF se sostiene sobre dos pilares: los programas y los mapas. Entender la relación entre ambos es clave.

Imagina un contador de paquetes. El programa eBPF se ejecuta por cada paquete que llega, lee la IP de origen, y actualiza una entrada en un mapa (un hash map, por ejemplo) donde la clave es la IP y el valor es el número de paquetes. El programa en sí no recuerda nada, toda la inteligencia y el estado se delegan en los mapas.

Aquí viene la parte que hace que todo esto sea seguro y viable en producción. Si has trabajado con módulos del kernel (LKMs), sabrás el pánico (literalmente, kernel panic) que puede dar cargar código nuevo. Un puntero nulo, un bucle infinito… y adiós servidor.

eBPF soluciona esto con el Verificador. Antes de que un programa eBPF se cargue y se enganche a un evento del kernel, pasa por un proceso de análisis estático extremadamente riguroso. El verificador es como un guardia de seguridad paranoico pero increíblemente eficiente que se asegura de varias cosas:

Si el programa no pasa alguna de estas comprobaciones, el kernel simplemente se niega a cargarlo. Esto nos da una garantía de seguridad que era impensable con los módulos del kernel tradicionales, permitiendo extender la funcionalidad del sistema operativo de forma segura y dinámica.

Un programa eBPF no hace nada por sí solo. Necesita «engancharse» a un evento para que el kernel lo ejecute. Estos puntos de enganche se conocen como hooks. La potencia de eBPF reside en la enorme variedad de hooks disponibles, que nos dan visibilidad en casi cualquier subsistema. Los más importantes son:

Elegir el hook correcto es como elegir la herramienta adecuada: podrías clavar un tornillo con un martillo, pero no es lo ideal. Aquí una guía rápida:

Muy bien, ya entendimos la magia, pero ahora toca la parte menos glamurosa pero más importante: la fontanería. ¿Puedo usar esto en mis servidores? ¿Qué necesito? Porque de nada sirve una tecnología revolucionaria si solo funciona en el portátil de un desarrollador del kernel.

La buena noticia es que, a día de hoy, en 2026, eBPF ya no es una rareza exótica. Es una tecnología madura y soportada por todas las distribuciones Linux serias. Sin embargo, no todas las «experiencias eBPF» son iguales, y el diablo, como siempre, está en los detalles de la versión.

Si has investigado sobre eBPF antes de, digamos, 2020, probablemente leíste sobre la pesadilla de tener que recompilar tus programas eBPF para cada versión específica del kernel. Era un auténtico dolor de cabeza. Cada vez que actualizabas un servidor, tenías que tener las cabeceras del kernel (kernel-headers) instaladas y un compilador (Clang/LLVM) a mano para que la herramienta de monitorización pudiera adaptar su programa eBPF a las estructuras de datos de ese kernel concreto. Un lío.

Ese infierno se acabó gracias a una cosa llamada BTF (BPF Type Format) y el concepto que habilita: CO-RE (Compile Once – Run Everywhere).

BTF es, en esencia, una forma de empaquetar la información de depuración sobre las estructuras de datos del kernel directamente dentro de la propia imagen del kernel (el vmlinuz). Piensa en ello como si el kernel llevara consigo un «mapa» de sus propias estructuras internas. Con este mapa, una herramienta eBPF moderna puede leerlo al arrancar y adaptar dinámicamente sus programas para que coincidan con la versión del kernel en la que se está ejecutando. Sin necesidad de compiladores ni cabeceras. Es un cambio brutal en la usabilidad.

Entonces, la pregunta clave es:

La respuesta corta es: un kernel con soporte para BTF. La mayoría de las distribuciones principales ya lo habilitan por defecto en sus versiones recientes:

En resumen, si estás trabajando con servidores desplegados en los últimos 2-3 años y los mantienes actualizados, lo más probable es que ya tengas todo lo necesario para disfrutar de la portabilidad de CO-RE. Puedes comprobarlo tú mismo con un simple comando en tu servidor:

Si este fichero existe, tienes soporte BTF.

Si el comando te devuelve la ruta del fichero, ¡Enhorabuena! Estás en el mundo moderno de eBPF. Si no, es hora de empezar a planificar esa actualización del kernel.

Ahora la pregunta del millón en cualquier entorno cloud native: ¿cómo funciona esto con Docker, Kubernetes y compañía? Porque mis aplicaciones corren en contenedores, no directamente sobre el metal.

Aquí es donde la cosa se pone delicada. Por su naturaleza, eBPF opera a nivel del kernel del host. Un contenedor comparte el kernel con el host y con otros contenedores, así que un programa eBPF cargado desde un contenedor tiene, potencialmente, visibilidad sobre todo lo que ocurre en el nodo. Esto es increíblemente potente para herramientas de observabilidad y seguridad (como Cilium o Falco), pero también es un riesgo de seguridad si no se gestiona bien.

Por defecto, un contenedor no tiene permisos para cargar programas eBPF. Y menos mal. Para hacerlo, el proceso dentro del contenedor necesita privilegios especiales. Históricamente, la única forma era darle la capacidad CAP_SYS_ADMIN, que es básicamente entregarle las llaves del reino. Es la capacidad más poderosa, permitiendo hacer casi cualquier cosa, desde montar dispositivos hasta cargar módulos del kernel. Demasiado arriesgado para la mayoría de los casos de uso.

Afortunadamente, el kernel evolucionó. A partir del kernel 5.8, se introdujo una capacidad mucho más granular y segura: CAP_BPF. Esta capacidad otorga a un proceso el derecho a usar la llamada al sistema bpf() para cargar programas y gestionar mapas, pero sin concederle otros superpoderes de CAP_SYS_ADMIN.

En la práctica, en un entorno Kubernetes, esto significa que las herramientas de monitorización o red basadas en eBPF (que suelen desplegarse como un DaemonSet) necesitarán que su SecurityContext especifique estas capacidades. No es «rootless» en el sentido estricto, pero es un modelo de privilegios mínimos mucho más seguro que el todo o nada de antes.

Hay otro componente en esta ecuación de permisos: el sistema de ficheros virtual de BPF, o bpffs.

¿Qué es esto? Es un pequeño sistema de ficheros virtual, similar a /proc o /sys, que se usa para «pinnear» (anclar) programas y mapas de eBPF. Cuando un proceso carga un programa o crea un mapa, estos suelen desaparecer cuando el proceso termina. Si los «pineas» en el bpffs, se convierten en nodos del sistema de ficheros (simples ficheros) que persisten. Esto permite que otras aplicaciones se comuniquen con ellos o que el estado se mantenga aunque el proceso original se reinicie. Es fundamental para herramientas que operan como servicios.

Para que esto funcione, primero hay que montar el bpffs, normalmente en /sys/fs/bpf. Esto, por supuesto, requiere privilegios. Se suele hacer una sola vez en el arranque del sistema con una línea en /etc/fstab o con un servicio de systemd.

Comando manual para montar el bpffs.

Una vez montado, la interacción con los objetos pineados depende de los permisos de los ficheros y directorios dentro de /sys/fs/bpf, como con cualquier otro sistema de ficheros.

Entonces,

Depende de lo que queramos decir con eso.

Así que el modelo de trabajo realista en 2026 es este: un servicio centralizado en el host (o un pod de DaemonSet en Kubernetes) se ejecuta con las capacidades CAP_BPF y CAP_PERFMON bien definidas. Este servicio se encarga de cargar y gestionar el ciclo de vida de los programas eBPF y de pinear los mapas necesarios en bpffs. El resto de aplicaciones, si necesitan los datos, los leen de los mapas a través del sistema de ficheros, con permisos de UNIX estándar. Es un equilibrio sensato entre poder y seguridad.

Ok, la teoría está clara. Sabemos que podemos enganchar código a eventos del kernel de forma segura. Genial. Pero, ¿cómo pasa esa información de ser un evento fugaz dentro del kernel a una línea en un gráfico de Grafana o a una alerta de Slack? Esa es la verdadera miga del asunto. No basta con capturar datos, hay que transportarlos, procesarlos y darles sentido. Este es el viaje, el pipeline completo de un dato de telemetría nacido en eBPF.

La estrategia más importante que eBPF nos obliga a aprender es a ser selectivos. Si intentas enviar cada evento individual desde el kernel al espacio de usuario, vas a tener un problema. Y gordo. Imagina un servidor concurrido: millones de llamadas al sistema, paquetes de red o accesos a ficheros por segundo. Intentar enviar todo eso crearía un «incendio» de datos que saturaría la CPU, solo para mover información de un lado a otro. El overhead de tu «monitorización sin overhead» se dispararía.

El patrón correcto es pensar como un embudo: filtrar y agregar tan pronto como sea posible.

Un programa eBPF se activa en un hook (ej. tracepoint:syscalls:sys_enter_openat). En este punto, tiene acceso al contexto completo del evento: qué proceso lo ha llamado, con qué argumentos, etc.

Aquí está la magia. En lugar de enviar inmediatamente el evento, lo procesamos dentro del kernel. Usamos mapas eBPF para agregar la información.

El agente de monitorización que corre en espacio de usuario adopta un rol pasivo. Periódicamente (ej. cada X segundos), lee los mapas de eBPF para recolectar los datos ya agregados. Este modelo «pull» es infinitamente más eficiente que un «push» constante desde el kernel.

Este enfoque de «agregar primero» reduce el tráfico entre el kernel y el espacio de usuario en órdenes de magnitud, y es la clave para lograr una observabilidad de alto rendimiento con un impacto mínimo.

Claro, no siempre podemos agregar. A veces necesitamos el evento crudo, por ejemplo, para una alerta de seguridad («¡El proceso nginx ha intentado abrir /etc/shadow!»). En estos casos, no nos vale un contador, necesitamos los detalles del evento individual.

Para esto, se usan buffers de memoria compartida para pasar eventos del kernel al espacio de usuario. Históricamente, se usaba el perf buffer, que en realidad es un conjunto de buffers, uno por cada CPU. Funcionaba, pero tenía problemas: los eventos de diferentes CPUs podían llegar desordenados y el uso de memoria no era óptimo.

La solución moderna, disponible desde el kernel 5.8, es el ring buffer (BPF_MAP_TYPE_RINGBUF). Es un único buffer MPSC (Múltiples Productores, Consumidor Único) que soluciona los problemas del perf buffer:

Pero, ¿qué pasa si el agente en espacio de usuario no puede leer el buffer a la misma velocidad que el kernel escribe? Esto es lo que se conoce como backpressure. Y la respuesta del kernel es simple y brutal: los eventos se pierden. El kernel no puede permitirse el lujo de esperar a un proceso lento de espacio de usuario. Si el buffer está lleno cuando llega un nuevo evento, se descarta.

Una herramienta de monitorización bien diseñada debe tener esto en cuenta. El propio programa eBPF, al intentar enviar un evento y ver que el buffer está lleno, debe incrementar un contador de «eventos perdidos» en un mapa separado. De esta forma, tu dashboard no solo mostrará los eventos que has recibido, sino también un aviso crítico que diga «¡Ojo, me he perdido 1.5 millones de eventos en los últimos 5 minutos!». Sin ese contador, estarías ciego a tus propios puntos ciegos.

Hemos capturado un evento, genial. Sabemos que el proceso con PID 12345 ha hecho algo. En un servidor de hace 10 años, eso sería suficiente. En un clúster de Kubernetes, el PID 12345 no significa absolutamente nada. ¿Es parte del pod de frontend? ¿Del de la base de datos? ¿Pertenece al namespace produccion o al de staging? Sin ese contexto, el dato es inútil.

Aquí es donde se completa el pipeline. El programa eBPF puede enriquecer el dato con la información que tiene a mano en el kernel. Usando funciones helper, puede obtener metadatos de bajo nivel en el momento de la captura:

El programa eBPF captura el evento y lo etiqueta con este ID de cgroup. Pero el kernel no sabe qué es un «Pod» o un «Deployment». La pieza final del puzzle la pone el agente en espacio de usuario.

Este agente tiene una doble vida. Por un lado, está leyendo los datos de los mapas y buffers de eBPF. Por otro, está constantemente hablando con la API del kubelet o del runtime de contenedores (Docker, containerd). Con esa información, construye y mantiene en su memoria un mapa de correspondencias:

Cuando el agente recibe un evento de eBPF etiquetado con el Cgroup ID 54321, hace una búsqueda en su caché, lo enriquece con toda la metadata de Kubernetes y, solo entonces, lo envía al sistema de visualización o alertas.

Este proceso de «costura» o enriquecimiento en espacio de usuario es lo que transforma un evento críptico del kernel en una pieza de información accionable. Además, con contexto completo en un entorno cloud-native. Es el paso final que nos lleva de la señal en el kernel al panel de control.

Aquí es donde eBPF pasa de ser una tecnología interesante a una herramienta indispensable en el arsenal de cualquier SysAdmin o SRE. La promesa del «casi cero» impacto no es marketing; es una consecuencia directa de su arquitectura. Como el trabajo pesado de filtrado y agregación se hace en el kernel, evitamos el coste brutal de copiar cantidades masivas de datos al espacio de usuario.

El resultado es que podemos obtener métricas increíblemente granulares de los subsistemas más críticos del sistema operativo, en producción y de forma continua, sin miedo a «matar» el servidor con la propia herramienta de monitorización. Vamos a ver qué tipo de «joyas» podemos extraer.

La red es, probablemente, el área donde eBPF brilla con más intensidad. Antes, para depurar problemas de red, nuestra principal herramienta era tcpdump, que es como intentar beber de una boca de incendios. Funciona para análisis post-mortem, pero su overhead lo hace inviable para una monitorización continua. eBPF cambia las reglas del juego.

Podemos engancharnos a puntos clave de la pila TCP/IP para extraer métricas de oro:

Los promedios mienten. Una latencia promedio de 50ms puede ocultar que el 5% de tus usuarios (los que pagan, probablemente) están sufriendo latencias de 2 segundos. La verdadera historia está en los percentiles.

Aquí es donde los mapas de eBPF de tipo BPF_MAP_TYPE_HISTOGRAM son una maravilla. Nuestro programa eBPF, en lugar de enviar cada medida de latencia individual al espacio de usuario, la clasifica directamente en un bucket del histograma dentro del kernel. Por ejemplo, al medir la latencia de una petición a un servicio en el puerto 443, calculamos el delta de tiempo y hacemos algo como: bpf_map_update_elem(lat_histogram, &slot, 1, BPF_ANY).

El agente de espacio de usuario solo tiene que leer este mapa cada pocos segundos para obtener una distribución completa de las latencias. A partir de ahí, calcular los percentiles p50 (la mediana), p95 y p99 es trivial y computacionalmente barato. Esto nos da una visión precisa y realista del rendimiento que experimentan nuestros usuarios, con un overhead mínimo.

Los problemas de disco son de los más difíciles de diagnosticar. ¿Es el hardware? ¿El sistema de archivos? ¿Una aplicación haciendo un mal patrón de acceso? eBPF nos permite diseccionar la pila de E/S.

Enganchándonos a los tracepoints del subsistema de bloque (block:*), podemos obtener una visibilidad sin precedentes:

Cuando una aplicación va lenta y el top muestra CPU de sobra, el siguiente sospechoso es el planificador (scheduler). Quizás la aplicación quiere ejecutarse, pero el scheduler no le da tiempo de CPU. Este tipo de problemas de «latencia de run queue» eran históricamente muy difíciles de cuantificar.

Con eBPF, podemos engancharnos a los tracepoints del scheduler (sched:*) para medir con precisión:

Finalmente, podemos subir un nivel y mirar no solo el kernel, sino el comportamiento de las propias aplicaciones, ¡sin tocar su código!

Usando tracepoints para las llamadas al sistema y uprobes para las librerías de espacio de usuario, podemos trazar la ruta crítica de una petición.

Imagina una petición que llega a tu aplicación web. Podemos:

Al correlacionar todos estos eventos, podemos reconstruir el ciclo de vida completo de la petición: «La petición X tardó 200ms en total, de los cuales 150ms se pasaron esperando una respuesta de la base de datos (syscall recvfrom), 10ms escribiendo logs (syscall write) y 40ms en computación pura». Este nivel de detalle, obtenido de forma segura y en producción, es el santo grial del profiling de rendimiento.

El profiling ha sido durante mucho tiempo una especie de «arte oscura». Todos sabemos que es la herramienta definitiva para encontrar cuellos de botella, pero la idea de ejecutar un profiler en producción era, hasta hace poco, casi un tabú. Las herramientas tradicionales, aunque potentes, solían ser tan pesadas que el propio acto de medir el rendimiento alteraba (o directamente hundía) el sistema. Era algo que hacías en un entorno de pre-producción o, si te atrevías, durante una ventana de mantenimiento a las 3 de la mañana.

eBPF cambia radicalmente este paradigma. Mueve el acto de muestrear (sampling) al kernel. Ya no es necesario un agente pesado en espacio de usuario que detenga procesos para hurgar en sus entrañas. Un programa eBPF puede capturar los stack traces (las «pilas de llamadas» que nos dicen qué función llamó a qué otra) de forma segura y con una eficiencia asombrosa.

Esto nos abre las puertas al perfilado continuo (continuous profiling): la capacidad de tener un profiler funcionando siempre, en todos tus servidores de producción. Ya no es una herramienta de emergencia, sino una fuente constante de datos sobre la salud y eficiencia de tu código. Es como pasar de hacer una radiografía puntual cuando sospechas que algo va mal, a tener un TAC en tiempo real 24/7. Las implicaciones para la optimización de costes y la resolución de incidentes son enormes.

Para entender por qué eBPF es un salto cualitativo, comparémoslo con la herramienta clásica por excelencia: perf. perf es una navaja suiza increíblemente potente, parte del propio kernel de Linux. Para hacer profiling de CPU, perf utiliza el subsistema perf_events para tomar muestras de en qué función se encuentra la CPU en un momento dado. Es el estándar de oro para el análisis de rendimiento en Linux.

Sin embargo, perf tiene sus «peros» en entornos de producción a gran escala:

El profiling con eBPF aborda estos puntos débiles. Un profiler basado en eBPF, como los que utilizan herramientas como Parca o Pyroscope, se engancha a los mismos eventos de temporizador del kernel que perf. Cada vez que salta el temporizador (por ejemplo, 100 veces por segundo), el programa eBPF se activa, captura el stack trace del proceso que se estaba ejecutando en esa CPU en ese preciso instante y lo guarda en un mapa eBPF.

La diferencia clave es la eficiencia de la captura y la agregación inicial dentro del kernel. El programa eBPF puede contar las ocurrencias de cada stack trace único directamente en un mapa hash. Esto significa que el agente de espacio de usuario no recibe un torrente de miles de muestras por segundo, sino que periódicamente recoge un resumen ya agregado de los «puntos calientes». Este enfoque reduce drásticamente el overhead de mover y procesar los datos, haciendo factible el perfilado continuo con un impacto mínimo.

El resultado final de un profiling de CPU suele ser un flame graph. Esta visualización, popularizada por Brendan Gregg, es una forma increíblemente intuitiva de ver dónde se está consumiendo el tiempo de CPU. Cada caja en el gráfico es una función, y el ancho de la caja es proporcional a la frecuencia con la que apareció en las muestras. Los «picos» anchos en la parte superior del gráfico son tus culpables.

La verdadera revolución es tener estos flame graphs de forma continua y para todo el clúster. Herramientas como Parca se especializan precisamente en esto: ingieren los datos de profiling de los agentes eBPF en cada nodo y te permiten explorar los flame graphs a lo largo del tiempo. Puedes seleccionar un pico de CPU de hace tres horas en tu dashboard de métricas y saltar directamente al flame graph exacto de ese momento para ver qué código lo causó.

Pero, ¿cómo sabemos a qué servicio, pod o contenedor pertenece una función caliente? Aquí es donde se une todo lo que hemos visto. El programa eBPF, en el momento de capturar el stack trace, también captura el cgroup_id del proceso. El agente en espacio de usuario, que está hablando con la API de Kubernetes, enriquece esa muestra con los metadatos correspondientes: «este stack trace pertenece al pod frontend-xyz del namespace produccion».

Esto es un cambio de juego. Permite filtrar y agrupar los datos de profiling por etiquetas de Kubernetes. Puedes pedir un flame graph agregado de todos los pods con la etiqueta app=checkout-service, comparar el flame graph de la versión v1.2 con la v1.3 para detectar regresiones, o aislar el perfil de un único pod problemático. La atribución se vuelve precisa y nativa del entorno en el que trabajamos.

Nada es gratis, ni siquiera con eBPF. El profiling continuo tiene un coste, pero la clave es que es increíblemente bajo y predecible. El factor principal que determina el overhead es la frecuencia de muestreo.

Una frecuencia típica para profiling de CPU es de 99Hz o 101Hz. Se suelen usar números primos para evitar sincronizarse accidentalmente con otras tareas periódicas del sistema, lo que podría sesgar los resultados. Esto significa que tomamos una muestra 99 o 101 veces por segundo en cada CPU.

Con esta configuración, el overhead de CPU de un agente de profiling moderno basado en eBPF suele estar en el rango del 1-3%. Algunos proyectos altamente optimizados reportan incluso menos del 1% de impacto. Comparemos esto con los profilers tradicionales, que fácilmente podían introducir un 10-20% de overhead o más, lo que los hacía insostenibles para un uso continuo en producción.

Este coste tan bajo es lo que hace que la balanza se incline. Pagar un peaje de un 1-3% de CPU en cada nodo a cambio de tener visibilidad completa y continua a nivel de código sobre el rendimiento de todo tu clúster es un negocio redondo para cualquier equipo de SRE o desarrollo. Permite optimizar el código de forma proactiva, reducir los costes de la nube encontrando ineficiencias y resolver incidentes de rendimiento en una fracción del tiempo que llevaba antes. El profiling ha dejado de ser una herramienta de emergencia para convertirse en un pilar fundamental de la observabilidad moderna.

Vale, la tecnología es una pasada, pero ¿cómo la usamos en el día a día? Nadie empieza escribiendo código eBPF en C desde cero para resolver un problema a las 2 de la mañana. El ecosistema ha madurado una barbaridad y hoy tenemos un abanico de herramientas que cubren distintos casos de uso, desde la exploración rápida hasta agentes de producción a prueba de balas. Vamos a clasificar el «quién es quién» en el mundo eBPF.

Aquí es donde casi todos empezamos. Piensa en bpftrace y BCC (BPF Compiler Collection) como tu navaja suiza para el análisis de sistemas. Son las herramientas que usas cuando aterrizas en un servidor en llamas y necesitas entender qué diablos está pasando, ahora.

BCC es una colección de herramientas y un framework, principalmente en Python y Lua, que te permite escribir scripts para tareas de análisis muy específicas. Es increíblemente potente y la colección de herramientas pre-hechas (opensnoop, execsnoop, tcplife, etc.) es un recurso de aprendizaje brutal. El «pero» de BCC es que, tradicionalmente, compila el código eBPF en la máquina de destino en tiempo de ejecución. Esto significa que necesita tener las cabeceras del kernel y un compilador (LLVM/Clang) instalado, lo que puede ser un engorro y añadir un overhead considerable, sobre todo al inicio.

bpftrace, por otro lado, es la respuesta a «¿y si tuviéramos algo como awk o sed pero para el kernel?». Es un lenguaje de tracing de alto nivel que te permite escribir one-liners increíblemente potentes directamente en la terminal. ¿Quieres ver qué proceso está abriendo un fichero específico? Una sola línea de bpftrace te lo dice. Su sintaxis es mucho más concisa y está diseñada para el análisis ad-hoc.

La línea divisoria es sencilla: si estás depurando un problema en vivo, aprendiendo o prototipando una idea, bpftrace y BCC son tus mejores amigos. Te dan una agilidad que es difícil de superar. Para un agente que va a correr de forma permanente en producción, sin embargo, hay una opción mejor.

Cuando la cosa se pone seria y quieres construir un agente de monitorización, profiling o seguridad que corra en toda tu flota, la eficiencia y la portabilidad no son negociables. Aquí es donde libbpf y el paradigma CO-RE (Compile Once – Run Everywhere) entran en juego y se han convertido en el estándar de facto para el desarrollo de aplicaciones eBPF serias.

El problema histórico de eBPF era que un programa compilado para una versión del kernel no funcionaba en otra, porque las estructuras de datos internas del kernel cambian. BCC lo solucionaba recompilando en cada host, con el coste que eso implica.

CO-RE, junto con BTF (BPF Type Format), soluciona esto de raíz. BTF es, básicamente, una especie de «mapa» de las estructuras de datos del kernel que se incluye con los kernels modernos. Cuando compilas tu programa eBPF, este incluye reubicaciones que libbpf (la librería que carga tu programa en el kernel) puede usar en tiempo de carga para «ajustar» los accesos a memoria según el BTF del kernel donde se está ejecutando.

El resultado es un único binario, pequeño y estático, que no necesita dependencias pesadas como LLVM o las cabeceras del kernel en la máquina de destino. Es más rápido, consume muchísima menos memoria (hasta 9 veces menos que su equivalente en BCC, según algunas pruebas) y es infinitamente más fácil de desplegar. Prácticamente todos los proyectos modernos y robustos de eBPF, como Cilium o Falco, han migrado o usan este enfoque. Es el camino para construir software de producción.

eBPF es una fuente de datos increíble, pero no vive en una isla. Necesitamos integrar esas métricas, trazas y logs en nuestros sistemas de observabilidad existentes, como Prometheus y OpenTelemetry. Afortunadamente, la comunidad ha creado los puentes necesarios.

Para Prometheus, existen varios exportadores de eBPF. Uno de los más conocidos es el ebpf_exporter de Cloudflare, que permite cargar programas eBPF y exponer los datos de sus mapas como métricas de Prometheus. Esto te da la flexibilidad de crear tus propias métricas a bajo nivel y engancharlas a tu sistema de dashboards y alertas de siempre.

En el mundo de OpenTelemetry (OTel), la integración es cada vez más profunda. eBPF se está convirtiendo en una de las formas más potentes de generar telemetría sin instrumentación manual. Proyectos como Grafana Beyla, donado a OTel, permiten capturar métricas RED (Requests, Errors, Duration) y trazas de aplicaciones de forma completamente automática, simplemente observando el tráfico de red a nivel de kernel. Esto significa que puedes tener un service map de tus aplicaciones en Go, Rust, o cualquier lenguaje compilado, sin tocar una sola línea de código. La convergencia de eBPF como fuente de datos y OTel como estándar para la telemetría es una de las tendencias más potentes del sector.

Finalmente, llegamos a los «productos» o proyectos de código abierto que usan eBPF para resolver problemas complejos de forma integral. No tienes que escribir código eBPF, simplemente los despliegas y obtienes el valor.

Hablemos claro: «cero overhead» es el unicornio del marketing. Cualquier cosa que hagas en un sistema, por muy optimizada que esté, tiene un coste. La pregunta no es si eBPF tiene overhead, sino si podemos conseguir que ese overhead sea tan ridículamente bajo que resulte insignificante. Y la respuesta es un rotundo sí.

La clave está en ser inteligentes y quirúrgicos. No se trata de encender una manguera de datos y apuntar al kernel, sino de usar un bisturí láser. Con eBPF, el poder reside en hacer el trabajo pesado y la toma de decisiones dentro del kernel, enviando solo la información esencial y ya procesada al espacio de usuario. Si sigues algunas reglas de oro, puedes mantener el impacto en un nivel casi imperceptible.

Este es el mandamiento número uno y el que separa a los profesionales de los novatos. La mayor fuente de overhead no suele ser la ejecución del programa eBPF en sí, sino el coste de enviar cantidades masivas de datos desde el kernel al espacio de usuario. Cada evento enviado implica un cruce de contexto y consumo de memoria en el búfer.

La estrategia ganadora es simple: procesa los datos donde se originan.

Piensa en ello como tener un asistente increíblemente rápido dentro del kernel. En vez de pedirle que te traiga cada grano de arena de la playa, le pides que te traiga un informe con el número total de granos.

No siempre necesitas el 100% de los datos. Para casos de uso como el profiling, el muestreo (sampling) es tu mejor aliado. La idea es tomar instantáneas del sistema a una frecuencia determinada en lugar de registrar cada acción.

La frecuencia de muestreo es el dial que ajusta el equilibrio entre la granularidad de los datos y el overhead. Un profiler de CPU que muestrea a 99Hz (99 veces por segundo por CPU) suele tener un impacto de CPU del 1-3%. Si lo subes a 199Hz, obtendrás datos más detallados, pero el overhead podría duplicarse.

Aquí es donde entra una mentalidad de SRE: define un presupuesto de recursos para tu agente de observabilidad. Trátalo como cualquier otro servicio en tu clúster. Decide cuál es un coste aceptable (por ejemplo, «el agente de monitorización no debe consumir más del 2% de una CPU en ningún nodo») y ajusta la configuración para mantenerte dentro de ese límite. Esto podría significar reducir la frecuencia de muestreo, desactivar algunas sondas menos críticas o aumentar el intervalo de recolección de métricas.

Hay una herramienta en el arsenal de eBPF que debes tratar con extremo respeto y casi nunca usar en producción: bpf_printk. Es el printf del mundo eBPF, una forma rápida de escupir mensajes de depuración al log de trazas del kernel. Es fantástico para desarrollar y depurar, pero es una bomba de relojería para el rendimiento. bpf_printk es lento, síncrono y puede inundar fácilmente los buffers del kernel si se usa en un punto de anclaje muy concurrido.

La forma correcta de enviar datos es a través del búfer de perf (bpf_perf_event_output) o, idealmente, no enviar eventos individuales en absoluto y depender de la lectura de mapas.

Además, cuando interactúas con mapas desde el espacio de usuario, la eficiencia importa. En lugar de leer o actualizar entradas una por una, lo que implica una llamada al sistema por cada elemento, usa las operaciones por lotes (batch operations) que proporciona libbpf. Funciones como bpf_map_lookup_batch() y bpf_map_update_batch() te permiten leer o escribir múltiples elementos con una sola syscall. Esta es una optimización clave para los agentes que necesitan sincronizar grandes cantidades de datos desde los mapas.

No te fíes de la palabra de nadie. Mide el impacto en tus sistemas y con tu carga de trabajo. La confianza se gana con datos.

Una caída de sonda ocurre cuando los eventos del kernel se generan más rápido de lo que el agente de espacio de usuario puede procesarlos desde el búfer de perf. El kernel, para protegerse, simplemente descarta los datos. Si esto ocurre, significa que tienes un punto ciego en tu observabilidad y que tus datos son incompletos. Una tasa de caídas distinta de cero es una señal de alerta: o tu programa eBPF es demasiado complejo, la frecuencia de eventos es demasiado alta, o el agente de espacio de usuario no es lo suficientemente eficiente. Es un indicador claro de que necesitas volver a la mesa de diseño y optimizar tu enfoque.

Muy bien, ya hemos visto la potencia de eBPF, pero ahora viene la pregunta del millón para cualquier sysadmin: ¿cómo diantres se gestiona esto a escala, en un cluster de Kubernetes con cientos de nodos, sin volverse loco? Desplegar un agente en tu portátil es una cosa; mantenerlo funcionando, actualizado y siendo fiable en un entorno de producción dinámico es un juego completamente distinto.

Aquí es donde la elegancia del ecosistema moderno de eBPF realmente brilla. Los problemas operativos que nos quitaban el sueño hace años (compatibilidad de kernels, actualizaciones sin caídas, gestión de estado) tienen hoy soluciones robustas y probadas en batalla. La clave es tratar a nuestro agente de observabilidad como lo que es: una aplicación crítica de primer nivel.

En el universo Kubernetes, hay un patrón de despliegue que encaja como un guante para los agentes basados en eBPF: el DaemonSet. Un DaemonSet asegura que una réplica de tu pod (en este caso, tu agente de monitorización) se ejecute en cada uno de los nodos del clúster. ¿Añades un nodo nuevo? Kubernetes se encarga de desplegar el agente allí. ¿Un nodo se va? El pod se elimina con él. Es el modelo «instálalo y olvídate» para la cobertura total.

Proyectos como Cilium o Tetragon se despliegan de esta manera. Pero esto nos lleva directamente al mayor dolor de cabeza histórico de eBPF: la compatibilidad del kernel. En un clúster grande, es casi seguro que no todos los nodos ejecuten la misma versión exacta del kernel. Puede que estés en medio de una actualización del sistema operativo, o que uses distintos tipos de instancia con AMIs diferentes. Si tu programa eBPF fue compilado contra la versión 5.4.0 del kernel, es muy probable que falle al cargarse en un kernel 5.10.0 porque alguna estructura de datos interna que usa ha cambiado de tamaño o sus campos se han reorganizado.

La solución a esto, y la que ha permitido que eBPF despegue en producción, es CO-RE (Compile Once – Run Everywhere). Gracias al BTF (BPF Type Format), que es una especie de mapa de depuración que describe todas las estructuras de datos de un kernel específico, el cargador de eBPF (como libbpf) puede realizar «ajustes» en tiempo de carga. Tu programa eBPF se compila una sola vez, y el binario resultante incluye información sobre qué quiere leer (por ejemplo, «el PID del proceso actual»), en lugar de dónde está exactamente («en el byte 1248 de la struct task_struct»). Al cargarse en un nodo, libbpf consulta el BTF de ese kernel, averigua dónde está el PID en esa versión concreta y parchea el programa en memoria antes de adjuntarlo.

El resultado es un único agente, desplegado como un DaemonSet, que funciona sin problemas a través de las diferentes versiones de kernel de tu clúster. Se acabaron las pesadillas de mantener múltiples builds de tu agente.

Operar código a nivel de kernel exige una confianza y una disciplina férreas. No puedes permitirte un «ups, desplegué un bug» que tira abajo un nodo. Aquí es donde las prácticas de CI/CD y la gestión de versiones se vuelven cruciales.

La capacidad de tener un único artefacto que funciona en todas partes, combinado con las primitivas de despliegue robustas de Kubernetes, convierte la gestión de agentes eBPF a escala de un problema complejo a una tarea operativa estándar.

Aquí entramos en un terreno un poco más avanzado pero fundamental para las operaciones «cero downtime». ¿Qué pasa con el estado que acumula tu agente? Imagina que tienes un mapa eBPF que cuenta el número de errores de red por pod. Si actualizas el agente simplemente reiniciando el pod del DaemonSet, el proceso de usuario muere y, por defecto, el kernel limpia todos sus mapas y programas asociados. Perderías todos los contadores.

La solución es el pinning (o «anclaje») a través del sistema de ficheros virtual de BPF, bpffs, que normalmente se monta en /sys/fs/bpf. Cuando un objeto eBPF (un mapa o un programa) se «ancla», el kernel crea un archivo especial en bpffs que mantiene una referencia a ese objeto. Esto significa que el objeto persistirá en la memoria del kernel incluso si el proceso que lo creó termina.

Esto nos permite un patrón de actualización increíblemente elegante y seguro:

Este mecanismo es crucial para la continuidad de los datos y permite actualizaciones transparentes sin perder una sola métrica o evento de seguridad. Es el tipo de detalle operativo que distingue a una herramienta de producción de un simple prototipo.

• Rendimiento: Menor sobrecarga de CPU/memoria y latencia casi nula.
• Cobertura universal: Ve todo lo que pasa por el kernel, independientemente del lenguaje de programación de la aplicación.
• Seguridad: El verificador y el sandbox garantizan que los programas no pueden dañar el kernel.
• No intrusivo: No requiere cambios en el código de la aplicación ni reinicios.

• Métricas de negocio: Tienen el contexto de la aplicación para medir lógicas específicas.
• Facilidad de despliegue (para casos simples): Un apt install prometheus-node-exporter es un comando que todos conocemos y confiamos.
• Ecosistema maduro: Hay miles de exportadores y dashboards listos para usar para casi cualquier tecnología imaginable.

• 1
  Ejecutar en Paralelo: Despliega tu nuevo agente basado en eBPF junto a tus agentes actuales. Sí, durante un tiempo tendrás dos sistemas recolectando datos similares. Asume este pequeño sobrecoste temporal. Es tu red de seguridad.
• 2
  Calibrar y Validar: Crea nuevos dashboards en tu sistema de visualización (ej. Grafana) que muestren las métricas de eBPF junto a las antiguas. ¿Coinciden? ¿La latencia de red que mide eBPF es comparable a la que medía tu viejo agente? Pasa tiempo aquí. Construye confianza en los nuevos datos.
• 3
  Migrar Dashboards, NO Alertas: Empieza por acostumbrar a tu equipo a usar los nuevos dashboards. Conviértelos en la fuente de verdad para la visualización del día a día, mientras las alertas críticas siguen dependiendo del sistema antiguo y probado.
• 4
  Alertas en Sombra (Shadowing): Ahora, recrea tus alertas más importantes (las que protegen tus SLOs) usando las nuevas métricas. Configúralas para que se disparen, pero sin enviar notificaciones. Durante unas semanas, compara los disparos. Cuando la alerta antigua se activa, ¿se habría activado también la nueva? Si no es así, ¿por qué? Afina los umbrales hasta que estés 100% seguro de que el comportamiento es el esperado.
• 5
  El Gran Cambio (Controlado): Una vez que las alertas en sombra han demostrado ser fiables, llega el momento. Durante una ventana de bajo riesgo (¡nunca un viernes por la tarde!), activa las notificaciones de las nuevas alertas y silencia las antiguas. Monitoriza de cerca.
• 6
  Desmantelamiento: Solo después de que el nuevo sistema haya funcionado sin problemas durante un ciclo de negocio completo (una semana, un mes…), puedes empezar a apagar y desinstalar los agentes antiguos.

ls /sys/kernel/btf/vmlinux