El ecosistema: bpftrace, libbpf, CO-RE y el mundo real

Ya sabes qué es la máquina virtual, cómo se demuestra segura, dónde se engancha y cómo guarda estado. Falta lo que convierte todo eso en algo que un ingeniero usa a diario: el ecosistema. Aquí conviven tres capas de abstracción —desde una línea de bpftrace que responde una pregunta en segundos hasta un binario de producción con libbpf que corre idéntico en miles de kernels distintos— y una tecnología, CO-RE, que resolvió el problema que durante años impidió que eBPF saliera del laboratorio. Y por encima de todo, los sistemas reales que ya no se entienden sin eBPF: la red de Kubernetes, la seguridad en tiempo de ejecución, los balanceadores de la nube.

Tres capas de abstracción

El ecosistema se ordena por cuánta ceremonia exige. En lo más alto, bpftrace: un lenguaje de dominio específico, heredero de DTrace y awk, para escribir observabilidad en una sola línea. En medio, BCC —la BPF Compiler Collection—, un framework en Python y C++ que compila C en el arranque y trae decenas de herramientas legendarias como execsnoop o biolatency; su talón de Aquiles es que necesita un compilador y las cabeceras del kernel en la máquina de destino, en tiempo de ejecución. Y en la base, libbpf: la biblioteca C canónica, que vive en el árbol del kernel y carga programas portables sin compilar nada en destino. La regla práctica: bpftrace para explorar, libbpf para producir.

bpftrace: observabilidad de una línea

Cuando quieres una respuesta ya —qué proceso abre qué fichero, cómo se distribuyen los tamaños de lectura, dónde gasta la CPU— bpftrace es imbatible. Compila tu expresión a bytecode eBPF, lo carga, agrega en mapas y te da el resultado:

# quién abre qué fichero, en vivo
bpftrace -e 'tracepoint:syscalls:sys_enter_openat {
    printf("%-16s %s\n", comm, str(args.filename)); }'

# histograma del tamaño de las lecturas de fichero
bpftrace -e 'kprobe:vfs_read { @ = hist(arg2); }'

# perfil de CPU: pilas del kernel muestreadas a 99 Hz
bpftrace -e 'profile:hz:99 { @[kstack] = count(); }'

La salida es igual de directa. El histograma anterior, que agrega en un mapa del kernel y se dibuja al terminar, tiene esta forma:

@:
[16, 32)          12 |@@@                                     |
[32, 64)           4 |@                                       |
[64, 128)        128 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[128, 256)        96 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@            |
[256, 512)        21 |@@@@@@                                  |

Cada una de esas líneas de bpftrace es un programa eBPF completo —con su verificación, su JIT y sus mapas— comprimido en una sintaxis que cabe en un tuit. Esa es la potencia de la capa alta: el poder del kernel programable sin escribir una sola línea de C.

BCC: el framework que lo empezó todo

Cuando una pregunta no cabe en una línea pero tampoco justifica un binario de producción, la capa intermedia es BCC. Combina un fragmento de C para el kernel con un guion en Python que lo compila al vuelo, lo carga, gestiona los mapas y presenta los resultados. Es el marco que popularizó eBPF y del que salieron las herramientas de observabilidad más usadas del mundo Linux:

from bcc import BPF

programa = r"""
int cuenta_exec(void *ctx) {
    bpf_trace_printk("execve\n");
    return 0;
}
"""

b = BPF(text=programa)
b.attach_kprobe(event=b.get_syscall_fnname("execve"), fn_name="cuenta_exec")
b.trace_print()   # imprime lo que el kernel emite por bpf_trace_printk

Su comodidad tiene un precio: BCC arrastra Clang y LLVM en la máquina de destino y compila en cada arranque, lo que consume memoria, tarda y exige tener a mano las cabeceras del kernel. Ese defecto es, precisamente, el que la siguiente capa vino a corregir.

CO-RE: compila una vez, corre en cualquier kernel

El gran problema histórico de eBPF era la portabilidad. Un programa lee campos de estructuras internas del kernel, y el desplazamiento de esos campos cambia entre versiones y configuraciones. BCC lo resolvía compilando en cada máquina, con el compilador y las cabeceras presentes en destino: lento, frágil y pesado. CO-RE —Compile Once, Run Everywhere— lo resolvió de raíz, y descansa en tres piezas.

La primera es BTF, el BPF Type Format: información de tipos compacta que el kernel moderno publica de sí mismo en /sys/kernel/btf/vmlinux cuando se compila con CONFIG_DEBUG_INFO_BTF. La segunda es vmlinux.h, un único cabezal generado desde ese BTF que contiene todos los tipos del kernel sin necesidad de sus fuentes:

bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h
clang -O2 -g -target bpf -c minimal.bpf.c -o minimal.bpf.o
bpftool gen skeleton minimal.bpf.o > minimal.skel.h

La tercera son las reubicaciones: cuando lees un campo con BPF_CORE_READ, el compilador no fija el desplazamiento, sino que anota qué campo querías. Al cargar, libbpf compara con el BTF del kernel real y reescribe cada acceso con el desplazamiento correcto de esa máquina concreta:

/* el desplazamiento de i_ino se resuelve al cargar, no al compilar */
u64 inodo = BPF_CORE_READ(file, f_inode, i_ino);

flowchart LR
B[BTF del kernel destino] --> H[vmlinux.h generado]
H --> K[clang compila una sola vez]
K --> O[objeto bpf con reubicaciones CO-RE]
O --> L[libbpf reajusta desplazamientos al cargar]
L --> R[el mismo binario corre en cualquier kernel]

El resultado es un binario pequeño, sin compilador ni cabeceras en destino, que se carga en un kernel de 2019 o en uno de 2026 y funciona en ambos. libbpf genera además un esqueleto —el .skel.h— que da al programa de usuario funciones tipadas para abrir, cargar y enganchar:

#include "minimal.skel.h"

int main(void)
{
	struct minimal_bpf *skel = minimal_bpf__open_and_load();  /* verifica y reubica */
	if (!skel)
		return 1;
	if (minimal_bpf__attach(skel))         /* engancha cada SEC() a su gancho */
		goto limpiar;

	/* ... consumir el ring buffer hasta recibir señal de parada ... */

limpiar:
	minimal_bpf__destroy(skel);
	return 0;
}

El esqueleto separa el ciclo de vida en etapas nítidas: open lee el objeto y prepara la configuración, load dispara la verificación y las reubicaciones CO-RE, attach engancha cada programa a su gancho, y destroy lo desmonta todo. Entre open y load puedes ajustar parámetros —redimensionar mapas, fijar variables globales de solo lectura que el verificador tratará como constantes—, lo que permite el mismo binario configurable sin recompilar. Y si prefieres Rust a C, libbpf-rs y el marco Aya ofrecen la misma potencia con las garantías de tipos y memoria de ese lenguaje.

De la herramienta al ecosistema: usos reales

eBPF dejó de ser una curiosidad hace años; hoy es infraestructura crítica. En la red de contenedores, Cilium implementa el plano de datos de Kubernetes enteramente en eBPF, sustituyendo a kube-proxy y a las cadenas de iptables por programas XDP y tc; su componente Hubble da observabilidad de red y Tetragon aplica políticas de seguridad. En seguridad en tiempo de ejecución, Falco detecta comportamientos anómalos de llamadas al sistema. En balanceo de carga, Katran de Meta reparte millones de conexiones con XDP, y Cloudflare mitiga ataques de denegación de servicio descartando paquetes en el driver antes de que toquen la pila.

La observabilidad vive un renacimiento paralelo. Perfiladores continuos como Parca y Pixie muestrean pilas con eBPF para dibujar dónde gasta CPU una flota entera sin instrumentar el código, y proyectos como Grafana Beyla extraen métricas de aplicaciones —latencias, tasas, trazas— sin tocar sus binarios. El patrón es siempre el mismo: un programa que agrega en el kernel y un plano de control que lee el resultado, exactamente la arquitectura de mapas del nivel anterior. Que industrias que compiten entre sí —proveedores de nube, fabricantes de seguridad, plataformas de observabilidad— convergieran todas en la misma base no es casualidad: es la señal de que eBPF resolvió un problema estructural que ninguna de ellas podía resolver por su cuenta.