eBPF y Observabilidad Avanzada en Linux 2025 | SysAdmin

La observabilidad en sistemas Linux ha dado un salto cuántico con la llegada de eBPF (extended Berkeley Packet Filter). Ya no basta con mirar logs, métricas de CPU o trazas de red tradicionales. Hoy, la capacidad de ejecutar programas sándbox en el kernel sin modificar su código fuente permite un monitoreo avanzado y un tracing kernel que antes requería parches o módulos peligrosos.

En este artículo exploraremos cómo eBPF ha redefinido la observabilidad Linux, sus mecanismos internos, el impacto de BPF CO-RE (Compile Once – Run Everywhere) y cómo implementar soluciones de monitoreo profundo en producción. Prepárate para dejar atrás las herramientas clásicas como strace o perf en su versión más limitada.

¿Qué es eBPF y por qué cambió las reglas del juego?

eBPF permite inyectar programas bytecode verificados en el kernel de Linux en tiempo de ejecución. Estos programas se ejecutan en respuesta a eventos: syscalls, funciones del kernel, puntos de rastreo, paquetes de red, etc. La máquina virtual eBPF garantiza seguridad (no bucles infinitos, acceso controlado a memoria) y eficiencia (JIT compilation, mapas compartidos).

Antes de eBPF, para observar el comportamiento interno del kernel necesitabas:

Módulos de kernel (riesgosos, difíciles de mantener).
Parches personalizados.
Herramientas como SystemTap o DTrace (limitadas por licencias o complejidad).

Con eBPF, cualquier SysAdmin puede escribir programas de tracing en C (o Python/BCC) y cargarlos sin reiniciar, sin compilar el kernel y con sobrecarga mínima.

[INFO] eBPF no es solo para redes. Su uso se ha extendido a seguridad (Falco), profiling (bpftrace), observabilidad (Pixie, Cilium) y hasta almacenamiento (Btrfs).

Conceptos clave: El núcleo de la observabilidad con eBPF

Para entender la observabilidad Linux moderna, debes dominar estos conceptos:

Hooks y puntos de anclaje

eBPF se adhiere a eventos mediante hooks:

kprobes/kretprobes: Instrumentan cualquier instrucción del kernel (entrada/salida de funciones).
tracepoints: Puntos estáticos definidos por el kernel (más estables que kprobes).
fentry/fexit: Reemplazo moderno de kprobes con menor overhead (desde kernel 5.5).
perf_events: Eventos de PMU (contadores de hardware).
XDP (eXpress Data Path): Procesamiento de paquetes a nivel de driver de red.

Mapas eBPF

Los programas eBPF se comunican con el espacio de usuario mediante mapas (hash, arrays, ring buffers). Permiten compartir estadísticas, configuraciones y eventos en tiempo real.

BPF CO-RE (Compile Once – Run Everywhere)

Uno de los mayores dolores de cabeza del eBPF temprano era la dependencia de los headers del kernel (estructuras task_struct, sk_buff, etc.). BPF CO-RE resuelve esto mediante:

BTF (BPF Type Format): Metadatos que describen las estructuras del kernel.
Relocalizaciones: El bytecode se ajusta a la estructura real del kernel en ejecución.
Libbpf: Biblioteca que carga y adapta el programa automáticamente.

Esto permite compilar un programa eBPF una vez y ejecutarlo en cualquier kernel que tenga BTF habilitado (prácticamente todos desde 5.x).

[TIP] Si usas distribuciones modernas (Ubuntu 22.04+, RHEL 9+, Arch), BTF viene activado por defecto. Verifica con: cat /sys/kernel/btf/vmlinux | head -c 4

Herramientas esenciales para el monitoreo avanzado con eBPF

No necesitas ser un experto en C para aprovechar eBPF. Aquí tienes las herramientas clave:

1. bpftrace: El awk del tracing

Lenguaje de alto nivel (similar a awk) para crear sondas rápidas. Ideal para debugging en vivo.

# Cuántas veces se llama a malloc por segundo
bpftrace -e 'kprobe:__kmalloc { @[comm] = count(); } interval:s:1 { print(@); clear(@); }'

# Latencia de syscalls read/write
bpftrace -e 'tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
             tracepoint:syscalls:sys_exit_read /@start[tid]/ {
               @us = hist((nsecs - @start[tid]) / 1000);
               delete(@start[tid]);
             }'

2. BCC (BPF Compiler Collection)

Colección de herramientas Python/C listas para usar. Incluye execsnoop, biolatency, tcplife, runqlat, etc.

# Monitorear nuevas ejecuciones de procesos
execsnoop-bpfcc

# Latencia de E/S en disco
biolatency-bpfcc -d 5

3. Libbpf + C (para soluciones personalizadas)

Si necesitas rendimiento extremo o integración con aplicaciones Go/Rust, programa directamente con libbpf. Ejemplo mínimo de programa que cuenta syscalls:

// syscall_count.bpf.c
#include <vmlinux.h>
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 600); // NR_syscalls
    __type(key, u32);
    __type(value, u64);
} syscall_count SEC(".maps");

SEC("tracepoint/syscalls/sys_enter")
int count_syscall(struct trace_event_raw_sys_enter *ctx) {
    u32 id = ctx->id;
    u64 *count = bpf_map_lookup_elem(&syscall_count, &id);
    if (count) {
        __sync_fetch_and_add(count, 1);
    }
    return 0;
}

Compilas con clang -target bpf -g ... y cargas con libbpf. El resultado: un mapa en /sys/fs/bpf que puedes leer con bpftool map dump.

Casos de uso reales: Observabilidad más allá de las métricas

Tracing de red con eBPF

Herramientas como Cilium o Pixie usan eBPF para capturar todo el tráfico de red (HTTP, gRPC, DNS) sin necesidad de sidecars o modificaciones en la aplicación.

# Usando tcplife de BCC para ver conexiones TCP con duración
tcplife-bpfcc -L  # Muestra PID, duración, bytes enviados/recibidos

Profiling continuo en producción

Con bpftrace o BCC profile puedes samplear la pila de llamadas del kernel y userspace con mínimo overhead.

# Sampleo de stacks cada 99 Hz durante 10 segundos
profile-bpfcc -af 99 -d 10 > stacks.txt
# Luego analizas con FlameGraph
./flamegraph.pl stacks.txt > profile.svg

Seguridad y detección de anomalías

Falco (CNCF) usa reglas eBPF para detectar:

Shells inversos.
Escritura en /etc/passwd.
Montajes sensibles.
Conexiones a IPs sospechosas.

# Regla Falco: Detectar spawn de shell en contenedor
- rule: Terminal shell in container
  desc: Detecta ejecución de bash/sh dentro de un contenedor
  condition: container.id != host and proc.name in (bash, sh, zsh)
  output: "Shell ejecutado en contenedor (user=%user.name container=%container.id)"
  priority: WARNING

Implementando BPF CO-RE en tu infraestructura

Para asegurar que tus herramientas eBPF funcionen sin fricción:

Habilita BTF en el kernel (config CONFIG_DEBUG_INFO_BTF=y). En kernels modernos ya viene.
Usa libbpf en lugar de BCC para programas en producción (menos dependencias, más rápido).
Compila con -g para incluir BTF en los objetos eBPF.
Empaqueta con CO-RE: Incluye el archivo .bpf.o junto con el loader.

Ejemplo de carga con libbpf (loader mínimo):

// loader.c
#include <bpf/libbpf.h>
#include "syscall_count.skel.h" // Generado por bpftool gen skeleton

int main() {
    struct syscall_count_bpf *skel;
    skel = syscall_count_bpf__open_and_load();
    if (!skel) { /* error */ }
    syscall_count_bpf__attach(skel);
    // Leer mapa cada 5 segundos...
    syscall_count_bpf__destroy(skel);
    return 0;
}

[WARNING] No cargues programas eBPF sin verificar firmas o sin control de acceso. Un programa malicioso puede leer memoria del kernel (aunque no modificarla). Usa bpf() syscall protegida con capacidades CAP_BPF.

Desafíos y limitaciones actuales

A pesar de su potencia, eBPF no es una bala de plata:

Overhead en eventos de alta frecuencia: Un kprobe en una función llamada millones de veces por segundo (ej. __slab_alloc) puede degradar el rendimiento. Usa tracepoints o fentry si es posible.
Complejidad de debugging: Los programas eBPF no pueden imprimir con printf. Usa bpf_printk (que escribe a /sys/kernel/debug/tracing/trace_pipe) o mapas con ring buffers.
Limitaciones de tamaño: El bytecode no puede exceder 1 millón de instrucciones (en kernel 5.2+). Para lógica compleja, usa múltiples programas encadenados.
Compatibilidad con contenedores: Si usas Docker/Kubernetes, necesitas montar /sys/kernel/btf y dar capacidades SYS_ADMIN o BPF al contenedor.

El futuro: eBPF como estándar de observabilidad

La industria se mueve hacia eBPF como capa base de cualquier stack de monitoreo. Proyectos como:

Pixie (New Relic) para tracing automático de Kubernetes.
Hubble (Cilium) para visibilidad de red en mallas de servicios.
Parca (Polar Signals) para profiling continuo.
Falco para seguridad runtime.

Ya no necesitas instalar agentes pesados como datadog-agent o telegraf para todo. Con eBPF, puedes obtener datos del kernel con precisión nanosegundo y sin tocar el código de las aplicaciones.

Conclusión

La observabilidad Linux ha alcanzado una madurez sin precedentes gracias a eBPF. Desde el tracing kernel con bpftrace hasta el monitoreo avanzado con CO-RE, cualquier SysAdmin tiene ahora herramientas para entender qué ocurre realmente en su sistema, sin comprometer la estabilidad.

Si aún no has explorado eBPF, empieza por:

Instalar bpfcc-tools (o bpftrace) en tu distribución.
Probar execsnoop-bpfcc y biolatency-bpfcc en un servidor de pruebas.
Leer el código de ejemplo de libbpf en github.com/libbpf/libbpf-bootstrap.

La curva de aprendizaje existe, pero el retorno en capacidad de diagnóstico es inmediato. El kernel ya no es una caja negra: con eBPF, tienes una ventana directa a su funcionamiento interno.

[TIP] Para una referencia rápida, guarda este comando: bpftrace -l 'tracepoint:syscalls:*' lista todos los tracepoints de syscalls disponibles. Úsalos como punto de partida para tus sondas.