Profiling continuo con eBPF en producción

Actualizado: 2026-05-03

El profiling continuo dejó de ser un experimento hace dos años. Cuando preparo una revisión de rendimiento en un servicio con tráfico real, el primer sitio al que miro no es la métrica agregada de Prometheus, es el perfil de CPU del último cuarto de hora en Parca o Pyroscope. El salto no es retórico: saber que el 12 % del tiempo de CPU se va en una función concreta de serialización JSON es una respuesta distinta que saber que el p99 ha subido.

Puntos clave

• El profiling continuo cambia el modelo de diagnóstico: ya no hay que reproducir el problema porque queda registrado en el histórico.
• El overhead típico de un agente eBPF en producción es del 1 al 3 % de CPU, según frecuencia de muestreo.
• Tres opciones maduras: Parca (más orientado a infraestructura kernel-nativa), Pyroscope integrado en Grafana, y Grafana Beyla (autoinstrumentación combinada).
• Compensa en servicios con impacto directo en coste o experiencia de usuario: bases de datos, pasarelas de API, servicios de alta concurrencia.
• No compensa en servicios con poca carga, batch con ejecuciones cortas o entornos con regulación de datos muy estricta.

Qué resuelve el profiling continuo

El profiling clásico funciona con dos modos. O bien instrumentas el código con timers y contadores, que es caro en líneas de código y requiere anticipar dónde vas a medir, o bien disparas perf o equivalentes bajo demanda cuando ya tienes un incidente encima. Ambos caminos fallan en el caso intermedio: cuando el rendimiento se ha degradado durante la última semana y nadie sabe cuándo empezó.

El profiling continuo cambia el modelo. El sistema toma muestras del stack de ejecución de cada proceso cada pocos milisegundos, de forma ininterrumpida, y almacena los perfiles etiquetados por servicio, hora y versión. Cuando el rendimiento se degrada, comparas el perfil de la semana pasada con el actual y ves exactamente qué función ha crecido en proporción de CPU.

La diferencia práctica es que ya no tienes que reproducir un problema para diagnosticarlo. El problema ha quedado registrado en el histórico, y tu trabajo es interpretar los flame graphs con la versión anterior al lado. Esta capacidad de diagnóstico retrospectivo también es lo que hace valiosa la evaluación continua de RAG: detectar cuándo empezó la degradación antes de que se vuelva visible.

El papel de eBPF

La pregunta obvia es por qué ahora, si perf lleva en Linux desde 2009. La respuesta es eBPF. Sin eBPF, recoger perfiles continuos significaba instrumentar cada binario en un lenguaje concreto, lidiar con símbolos de depuración desplegados en producción y pagar un coste de CPU inaceptable. Con eBPF, una sonda en el kernel toma muestras por ti en cualquier proceso, sin cambiar el binario y con un coste medible y acotado.

La pieza técnica concreta que ha madurado es el profile attach. El kernel expone una probe que se dispara en cada cambio de contexto y captura el stack del proceso activo. La herramienta en espacio de usuario —sea Parca, Pyroscope o una integración de Grafana Beyla— agrega esas muestras y las exporta a un backend con su propio lenguaje de consulta.

La segunda pieza que ha cambiado es la resolución de símbolo. Las herramientas actuales descargan los símbolos de depuración de los binarios originales, los cachean y aplican fallbacks razonables cuando no los encuentran. Para lenguajes compilados nativos el soporte es ya muy bueno. Para lenguajes gestionados como Java o Python hay un paso adicional de mapear direcciones JIT, que no siempre es perfecto.

Coste real en producción

La pregunta que siempre hace el equipo de plataforma antes de aprobar el despliegue es cuánto cuesta. La respuesta que he medido en tres entornos distintos: el sobrecoste típico está entre el 1 % y el 3 % de CPU. Eso cubre el agente eBPF tomando muestras, la agregación local y el envío a la capa de agregación central.

Este número tiene matices:

• El sobrecoste es proporcional a la frecuencia de muestreo. Por defecto muchas herramientas muestrean a 19 o 99 Hz (frecuencias que no caen en armónicos del reloj del kernel). Bajar a 19 Hz reduce el coste a la mitad.
• El otro coste, menos obvio pero real, es el almacenamiento. Un agente por nodo enviando perfiles etiquetados por servicio y versión puede generar varios cientos de megabytes diarios comprimidos. Multiplicado por la retención típica de dos a cuatro semanas, es un presupuesto que hay que prever.

Qué herramienta escoger

El ecosistema se ha consolidado en tres opciones serias:

• Parca, de Polar Signals: la más orientada a infraestructura kernel-nativa, con un modelo de datos pensado para perfiles continuos y un backend propio.
• Pyroscope, adquirida por Grafana en 2023 e integrada en la stack de Grafana: la que mejor se integra si ya tienes Grafana y Loki.
• Grafana Beyla: añadió autoinstrumentación y profiling combinados en 2024, aunque con menos opciones de ajuste.

En la práctica he acabado usando Pyroscope en entornos con stack de Grafana ya en marcha y Parca cuando el equipo quiere separar la telemetría de profiling del resto de la observabilidad. La decisión no es técnica, es organizativa.

Para Kubernetes existe un agente oficial de Pyroscope que se despliega como DaemonSet y captura perfiles de todos los pods del nodo automáticamente. Para docker compose o swarm basta con un agente por host que mira procesos por cgroup.

Cuándo compensa y cuándo no

El profiling continuo compensa en servicios donde el rendimiento tiene impacto directo sobre el coste o la experiencia de usuario:

• Bases de datos.
• Pasarelas de API.
• Servicios con alta concurrencia.

En estos casos una optimización del 10 % de CPU puede ahorrar varios miles de euros anuales en infraestructura. Este análisis coste-beneficio encaja con el de FinOps aplicado a IA: instrumentar primero para identificar los puntos calientes antes de optimizar.

No compensa igual en:

• Servicios con poca carga, aplicaciones de back-office o pipelines batch con ejecuciones cortas.
• Entornos donde la regulación de datos es muy estricta: un perfil continuo captura nombres de funciones que pueden filtrar información sobre qué operaciones se ejecutan con qué frecuencia.

Mi lectura

Mi sensación después de un año largo integrando profiling continuo en cuatro entornos distintos es que es la novedad más útil que ha llegado a observabilidad desde que se estabilizó OpenTelemetry. No porque aporte datos que antes no se podían obtener, sino porque los aporta de forma pasiva, constante y con etiquetas por servicio y versión. El diagnóstico diferencial se vuelve posible.

El único miedo razonable sigue siendo el coste en CPU. El número real en nuestros sistemas ha sido inferior al que temíamos, pero recomiendo hacer una prueba de una semana en un nodo de producción antes de aprobar el despliegue general.

A los equipos que están empezando les sugiero instalar uno de estos sistemas aunque no tengan un problema de rendimiento concreto ahora mismo. El valor real aparece cuando lo tienen, y la curva de aprendizaje de interpretar flame graphs se hace mucho más fácil con datos históricos propios que con demos ajenas.