La forma tradicional de perfilar un problema en producción tiene una dependencia incómoda: ya tienes que sospechar de él. Algo se ve lento, adjuntas un perfilador, intentas reproducir la condición, y — si eres afortunado y el problema todavía está sucediendo — capturas datos. El modo de fallo es obvio y común. El incidente sucedió a las 3 a.m., duró cuatro minutos, y para cuando alguien mirara, la evidencia se fue. Añades logging, esperas que recurra, y esperas.
eBPF cambió la economía suficientemente para invertir ese workflow. Porque los programas de eBPF se ejecutan dentro del kernel en una sandbox verificada, pueden observar syscalls, scheduling, y stack traces cruzando cada proceso en una máquina a overhead lo suficientemente bajo — consistentemente menos de 1% — para dejar ejecutándose permanentemente. Eso convierte el perfilado de algo que inicias a algo que consultas: los datos para las 3 a.m. ya existen. Esta guía cubre ese cambio a través de Parca Agent para perfilado continuo, y una aplicación más nueva que ha emergido conforme los agentes autónomos proliferan — usando la misma visibilidad kernel-level para ver qué un agente de IA realmente hizo, vía herramientas como AgentSight.
Por qué eBPF hizo always-on viable
La razón técnica por la que el perfilado continuo fue impracticable antes es que las opciones más antiguas todas impusieron un tax que no pagarías permanentemente. Los perfiladores de muestreo basados en perf son baratos pero requieren setup por objetivo y producen datos que debes manejar. Los perfiladores instrumentados requieren cambios de código y añaden overhead por-llamada. Los agentes específicos del lenguaje cubren un runtime y frecuentemente introducen su propio costo de rendimiento. Ninguno de ellos eran cosas que ejecutarías en cada proceso en cada nodo para siempre.
La contribución de eBPF es que los programas se ejecutan en espacio kernel, así que recolectar un stack trace no requiere context-switching a un agente userspace para cada muestra, y el verificador del kernel estáticamente prueba que el programa no puede crashear el sistema o loopear para siempre antes de permitir que cargue. El resultado es visibilidad a nivel kernel con garantías de seguridad y overhead en el ruido. Crucialmente también es cero-instrumentación: no modificas, recompiles o reinicias las aplicaciones siendo perfiladas, lo cual elimina la fricción organizacional que mató la mayoría de intentos previos ("necesitaríamos que cada equipo añadiera un agente").
Hay un prerrequisito real que vale la pena establecer: esto depende de un kernel razonablemente moderno con soporte de BTF, y la calidad de unwinding de stack depende de tus binarios teniendo símbolos. Los binarios de producción stripped produce perfiles llenos de direcciones hexadecimales, que es un problema solvible pero uno que deberías resolver antes de concluir que la herramienta no funciona.
Perfilado continuo en la práctica
Parca Agent es la expresión más clara de la idea. Desplegado como un DaemonSet en Kubernetes (o un proceso en un nodo), muestrea stack traces desde cada proceso en ese nodo, continuamente, los etiqueta con metadatos de pod, contenedor y namespace, y los envía a un servidor donde se almacenan como métricas — consultables por rango de tiempo y etiqueta.
Ese modelo de almacenamiento es lo que lo hace útil en lugar de meramente interesante. Porque los perfiles son series de tiempo etiquetadas, puedes hacer preguntas que el perfilado on-demand no puede responder. ¿Qué estaba consumiendo CPU en el namespace de payments entre 03:04 y 03:08? El perfil existe; filtras a la ventana. Aún más valioso es comparación: diff el perfil desde antes de un despliegue contra después, y la regresión aparece como una función que creció. No necesitabas predecir que querrías el perfil "antes" — la recolección continua significa que siempre está allí.
Parca maneja stacks de lenguaje mixto, que importa más de lo que suena. Un servicio moderno podría ser Go llamando a librerías C, o Python invocando extensiones nativas, y un perfil que resuelve solo una capa cuenta una historia engañosa. El unwinding a nivel kernel ve el stack completo. Para análisis profundo de una sola ejecución todavía alcanzarás perf o async-profiler — el perfilado continuo optimiza para cobertura e historia, no máximo detalle per-ejecución — pero la pregunta cotidiana de "en qué está gastando CPU este cluster" es respondida continuamente y baratamente.
El problema más nuevo: ¿qué hizo el agente?
La segunda aplicación es más nueva y, en 2026, crecentemente urgente. Los equipos están ejecutando agentes de codificación autónomos y agentes de LLM con acceso a herramientas en sistemas reales. Estos agentes leen archivos, ejecutan comandos, instalan paquetes y hacen llamadas de red. La observabilidad que esos sistemas proporcionan es a nivel de aplicación: prompts, llamadas a herramientas, conteos de token, spans. Herramientas como Langfuse y Arize Phoenix hacen esto bien y son genuinamente útiles para entender el razonamiento de un agente.
Pero el rastreo a nivel de aplicación tiene una limitación estructural: muestra lo que el framework del agente eligió reportar. Si una herramienta ejecuta un comando shell, el rastreo registra la cadena de comando — no los diecisiete procesos que el comando generó, los archivos que tocaron, o el host que contactaron. Si el agente está comprometido por inyección de prompt y toma una acción fuera de su alcance previsto, el rastreo muestra la acción que narró, que es exactamente la fuente de verdad equivocada para una pregunta de seguridad.
AgentSight aplica eBPF aquí: observar el comportamiento del sistema real del agente a nivel kernel — ejecución de proceso, acceso a archivo, conexiones de red — sin instrumentación del agente en absoluto. El agente no puede omitir o tergiversar estos eventos porque no es quien los reporta. Para un agente de codificación operando en un repositorio, obtienes la respuesta real a "qué archivos modificó," "qué ejecutó" y "alcanzó fuera del workspace."
La postura correcta es que estas son capas complementarias, no competidoras. El rastreo de aplicación te dice la intención y razonamiento del agente; el rastreo de kernel te dice sus efectos. Correlacionarlos por timestamp te da ambas mitades: esto es lo que el agente estaba intentando hacer, y esto es lo que realmente sucedió en la máquina. Para cualquier cosa con permisos reales, tener solo la primera mitad es una brecha.
Seguridad, no solo rendimiento
Ese encuadre apunta al uso más amplio. La misma base eBPF subyace herramientas de seguridad de runtime — Tracee, Falco, Tetragon — que observan comportamiento kernel-level sospechoso y, en el caso de Tetragon, pueden hacer cumplir política in-kernel. Una vez que estás recolectando evento de proceso, archivo y red en cada nodo, la diferencia entre "observabilidad" y "detección" es mayormente cuál preguntas haces de los datos.
Para workloads de agente específicamente, esa convergencia es útil. Las preguntas "por qué esto es lento," "qué cambió el agente" y "¿nada escapó su sandbox" son todas respondidas del mismo stream de eventos. Prácticamente, esto significa una organización desplegando agentes con acceso al sistema debería tratar la visibilidad kernel-level como parte del despliegue, no una ocurrencia tardía — es la única capa que produce evidencia auditable de lo que un proceso autónomo realmente hizo.
La advertencia honesta es volumen. El rastreo a nivel kernel puede generar streams de eventos enormes, e ingenuamente hacer log de cada syscall en un nodo ocupado abrumará tu almacenamiento y tu habilidad de encontrar algo. Filtrado en la fuente — por ruta, por proceso, por tipo de evento — no es una optimización sino un requisito, y es donde la mayoría del trabajo operacional en esas herramientas vive.
Leyendo un perfil sin engañarte
El perfilado continuo produce mucho dato, y hay algunas formas confiables de malinterpretarlo. Vale la pena saber antes de actuar en una flame graph.
Ancho es muestras, no latencia de wall-clock. Un perfil de CPU muestra dónde fue el tiempo de CPU. Si tu servicio es lento porque está esperando — en una base de datos, un lock, una llamada de red — el perfil de CPU podría verse perfectamente sano, porque un thread bloqueado no consume CPU. Este es el maldiagnóstico más común único: concluyendo que no hay un problema porque el perfil de CPU es plano, cuando el problema es tiempo off-CPU. El perfilado de wall-clock u off-CPU responde esa pregunta en su lugar.
Los hotspots agregados no son necesariamente tu problema de latencia. Una función consumiendo el 30% de CPU del cluster puede ser completamente esperada background work — serialización, compresión, garbage collection. La señal interesante es usualmente un cambio: esta función fue 5% la semana pasada y ahora es 30%. Es por qué la comparación importa más que el ranking absoluto, y por qué la recolección continua vence una snapshots única.
La calidad de símbolo moldea conclusiones. Símbolos faltantes hacen que stacks colapsen en direcciones hexadecimales poco útiles, y peor, pueden maltrabuir tiempo a la frame más cercana resoluble — produciendo una respuesta confidante, equivocada. Si un perfil culpa a una función que no tiene sentido, sospecha del unwinding antes de sospechar del código.
El muestreo tiene un piso. Una función que corre frecuentemente pero muy brevemente puede ser subrepresentada relativa a su costo verdadero, y eventos raros-pero-costosos pueden no aparecer en absoluto en una ventana corta. La recolección continua mitiga esto agregando sobre períodos largos, que es otro argumento para always-on sobre on-demand.
El hábito práctico: usa el perfil para formar una hipótesis, luego confírmalo con una medición dirigida antes de pasar un sprint optimizando.
Adoptando esto sensatamente
Una secuencia pragmática evita el fallo común de desplegar todo y ahogarse. Comienza con perfilado continuo en un subset de nodos. Es la introducción de riesgo más bajo, entrega valor inmediatamente (encontrarás algo sorprendente en la primera semana), y te enseña cómo tus kernels y símbolos se comportan antes de que nada dependa de esto. Confirma que los stacks se resuelven a nombres de función reales; arregla disponibilidad de símbolo si no.
Luego añade workflows de comparación, porque es donde la recompensa se concentra: integra diffing de perfil en tu proceso de release para que una regresión de CPU sea atrapada como un cambio de perfil en lugar de como una alerta de latencia tres días después.
Añade rastreo a nivel de agente cuando realmente ejecutes agentes con acceso al sistema. Si tus agentes solo llaman APIs y retornan texto, el rastreo de kernel es excesivo. Si ejecutan comandos, escriben archivos u operan en repositorios, la brecha de visibilidad es real y vale la pena cerrar.
Y filtra agresivamente desde el inicio. Decide de antemano qué rutas, procesos y tipos de evento importan, y excluye el resto. Es mucho más fácil ampliar un filtro estrecho después que retrofittar filtrado a una firehose que ya estás almacenando.
Finalmente, mantén las herramientas on-demand afiladas. El perfilado continuo te dice que una función se puso hot y cuándo; perf, bpftrace y async-profiler permanecen mejores para el deep dive en por qué. El workflow que funciona es datos continuos para detección e historia, herramientas dirigidas para diagnóstico.
La conclusión
eBPF movió la observabilidad de "adjunta un perfilador cuando sospechas un problema" a "los datos ya existen, consulta," porque ejecución a nivel kernel con una sandbox verificada hizo la recolección always-on costar menos del 1% y no requerir cambios de aplicación. Parca Agent entrega eso como perfilado continuo, label-queryable, multilenguaje de CPU cuyo superpoder real es comparar antes y después. La nueva frontera es aplicar la misma visibilidad a agentes autónomos: AgentSight muestra qué un agente realmente hizo a nivel de syscall, cerrando la brecha dejada por trazas de aplicación que solo reportan lo que el agente eligió narrar. Comienza con perfilado en unos pocos nodos, verifica tus símbolos, construye comparación en releases, añade rastreo de agente cuando los agentes tocan sistemas reales, filtra fuerte desde el primer día, y mantén perf y bpftrace para los deep dives.
Referencias y recursos
Herramientas
Background y análisis
- 8 Best Open-Source eBPF Tracing Tools in 2026 — Better Stack
- eBPF.io — what is eBPF
- Brendan Gregg on eBPF performance tools
Cheatsheets relacionados de 1337skills