Un servicio de checkout en Go que llevaba meses estable empieza a arrastrar la latencia tras el despliegue del martes. El p99 sube de 120 ms a 400 ms, pero nada cuadra: la CPU del pod está al 40 %, la memoria plana, los logs limpios y las trazas señalan que el tiempo se va «dentro» de ese servicio… sin decir dónde. Sabes qué servicio es el culpable, pero no qué línea de código. Ahí se acaba lo que te cuentan las métricas, los logs y las trazas, y empieza el terreno del continuous profiling.
Qué resuelve el continuous profiling (y por qué no es lo mismo que las otras señales)
El profiling clásico es una tarea puntual: arrancas un profiler, ejecutas una prueba, miras el resultado y vuelves a la vida normal. Sirve para desarrollo y para reproducir un problema en un entorno controlado, pero en producción llega tarde y mal: el pico que querías entender ya pasó.
El continuous profiling le da la vuelta a eso. Consiste en muestrear de forma permanente y a bajo coste qué funciones consumen CPU (o memoria, o I/O) en cada momento, de modo que cuando llega el incidente los datos ya están ahí. La clave está en el muestreo estadístico: en lugar de instrumentar cada llamada, se toman fotos del stack de ejecución a una frecuencia fija. Con suficientes muestras, lo que consume recursos emerge con significancia estadística y el sobrecoste se mantiene por debajo del 1 % de CPU. Por eso puede estar siempre encendido.
Si las trazas te dicen qué servicio es el cuello de botella, un perfil te dice qué función, en qué línea se está comiendo los ciclos. Es la diferencia entre optimizar a ciegas (añadir réplicas) y optimizar con bisturí. No es casualidad que la industria lleve un par de años llamándolo la cuarta señal de la observabilidad, junto a métricas, logs y trazas.
Hoy hay tres nombres que aparecen en casi cualquier conversación seria sobre profiling en producción: Parca, Pyroscope y el agente eBPF de OpenTelemetry. Comparten más de lo que parece —los tres se apoyan en eBPF para recolectar sin tocar el código— pero ocupan lugares distintos en la cadena. Vamos uno a uno.
Parca: el profiler eBPF autocontenido
Parca nació en 2021 de la mano de Polar Signals, la empresa fundada por Frederic Branczyk (ex-Red Hat, mantenedor de Prometheus). Su propuesta es un sistema completo y autocontenido: agente de recolección, almacenamiento y UI, todo bajo licencia Apache 2.
El corazón es Parca Agent, un sampling profiler basado en eBPF. Se despliega por nodo —como un DaemonSet en Kubernetes— y observa las pilas de ejecución en espacio de usuario y de kernel unas 19 veces por segundo por CPU lógica, sin instrumentar ni reiniciar nada. De ahí construye perfiles en formato pprof, el estándar que popularizó Go. Esos perfiles se envían al servidor de Parca, que los guarda en un almacén columnar propio diseñado para este tipo de dato y los expone vía gRPC, con una UI que los pinta como icicle graphs (flame graphs invertidos). Como cada serie de perfiles se identifica por etiquetas al estilo Prometheus, puedes comparar el mismo servicio entre despliegues, versiones o regiones y ver exactamente qué cambió en el consumo de CPU tras el deploy del martes.
Parca cubre un abanico amplio de lenguajes (C/C++, Go, Rust, Java, Python, Ruby, Node.js, .NET, PHP, Perl…) y también admite recoger pprof directamente desde endpoints HTTP, lo habitual en aplicaciones Go. En el último año ha añadido perfilado de GPU para cargas CUDA, una señal de hacia dónde mira la observabilidad de IA.
¿Cuándo Parca? Cuando quieres una solución de profiling íntegramente open source, autoalojada y sin depender de un backend de terceros, y valoras poder comparar perfiles por etiquetas entre versiones y entornos. Encaja bien en flujos CI/CD donde el profiling es un control de regresiones más.
¿Cuándo no? Si tu infraestructura es pequeña o monolítica, montar agente + servidor + almacenamiento puede ser desproporcionado frente a un pprof puntual. Y, al ser un proyecto de empresa única, su ecosistema es más estrecho que el de Pyroscope o el del estándar de OpenTelemetry.
Grafana Pyroscope: el backend de profiling del stack LGTM
Aquí conviene aclarar algo que muchos artículos siguen contando mal: Pyroscope ya no es un proyecto independiente. Grafana Labs lo adquirió en 2023 y lo fusionó con Phlare (su propia base de datos de perfilado) bajo el nombre de Grafana Pyroscope. Hoy es la pieza de profiling del stack LGTM, alineada arquitectónicamente con Mimir, Loki y Tempo, lo que permite correlacionar un perfil con sus métricas, logs y trazas dentro de la misma Grafana.
A diferencia de Parca, el punto fuerte de Pyroscope es ser un backend de almacenamiento y consulta muy escalable, alimentado por dos vías: SDKs de instrumentación cliente para Go, Java, Python, Ruby, .NET, Node.js o Rust, y la ingesta de datos eBPF, incluido el formato OTLP del agente de OpenTelemetry. Es decir, no compite tanto con el recolector como con el lugar donde aterrizan los perfiles.
En abril de 2026 llegó Pyroscope 2.0, una rearquitectura de fondo: rutas de escritura simplificadas, consultas stateless, menor coste de almacenamiento y dos capacidades nuevas interesantes —metrics from profiles, que agrega perfiles en métricas de flota para comparar consumo entre servicios o versiones sin bucear perfil a perfil, e inspección de un perfil individual concreto en lugar de solo agregados.
Que esto no es teoría lo ilustró bien el banco británico Monzo en la QCon London 2026: usan Pyroscope para detectar regresiones de rendimiento en cuanto se despliegan y tienen un canal de Slack llamado «Graph Trending Downwards» donde celebran cada vez que una optimización hace bajar la gráfica de consumo. Es la cultura de profiling continuo llevada a su conclusión lógica: el rendimiento como métrica de equipo, no como apagafuegos.
¿Cuándo Pyroscope? Si ya vives en Grafana y quieres el perfilado como una señal más correlacionada con el resto, o si buscas un backend que escale y acepte tanto SDKs como datos eBPF/OTLP. Es la opción natural para quien no quiere reinventar la capa de visualización.
¿Cuándo no? Si tu objetivo es no atarte al ecosistema Grafana, o si solo necesitas recolectar y mirar perfiles puntualmente sin montar una base de datos de profiling completa.
El agente eBPF de OpenTelemetry: el recolector que se está volviendo estándar
El tercer actor no es exactamente un producto, sino el camino por el que el resto se está estandarizando. El agente eBPF de OpenTelemetry es la donación que Elastic hizo a finales de 2024 de su Universal Profiling: un profiler de CPU whole-system, basado en eBPF, que perfila todo lo que corre en un host Linux —tu código, librerías de terceros, operaciones de kernel— sin instrumentar ni reiniciar nada. Reconstruye pilas completas que van del kernel al código nativo y hasta los runtimes interpretados o JIT (C/C++, Go, Rust, Java, Python, Node.js, .NET, PHP, Ruby, Perl…), con un techo de en torno al 1 % de CPU y ~250 MB de memoria.
Su gran baza es la integración: desde la versión estabilizada del agente, funciona como un receiver del OpenTelemetry Collector —la configuración soportada de aquí en adelante— y se distribuye como una imagen oficial del Collector. Eso significa que un perfil pasa por las mismas pipelines de procesado que el resto de tu telemetría: el k8sattributesprocessor, por ejemplo, enriquece cada perfil con su namespace, pod y deployment, de modo que no ves una pila de ejecución suelta sino exactamente qué workload la produjo.
Conviene no confundirlo con OBI (OpenTelemetry eBPF Instrumentation, antes Beyla), que también es eBPF pero genera trazas y métricas zero-code; aquí hablamos de la señal de perfiles, que es otra cosa.
Y aquí va el matiz importante para no llevarse un chasco: la señal Profiles de OpenTelemetry entró en Alpha pública en marzo de 2026. Funciona, puedes empezar a experimentar con el agente y el Collector (v0.148.0 o superior), pero el propio proyecto avisa de que no debe usarse en cargas críticas de producción todavía. Además, el agente solo recolecta: necesita un backend donde almacenar y consultar. Para desarrollo existe devfiler (la app de escritorio que Elastic liberó, no apta para producción), y como backend real ya hay quien ingiere su salida de forma nativa: Grafana Pyroscope, sin ir más lejos.
¿Cuándo el agente eBPF de OTel? Cuando apuestas por el estándar abierto y quieres un perfilado uniforme, sin instrumentación, integrado en tu pipeline de Collector junto al resto de señales. Es lo más sensato si construyes pensando en los próximos años más que en el trimestre que viene.
¿Cuándo no? Si necesitas algo estable para producción crítica hoy mismo: la señal aún es Alpha. También requiere un kernel Linux que soporte eBPF, lo que descarta sistemas antiguos, y exige montar un backend aparte.
¿Cuál elegir? Recolección, almacenamiento y hacia dónde va todo
La trampa habitual es plantearlo como «tres herramientas que hacen lo mismo». No lo hacen. Sirve más pensar en dos capas: la de recolección (quién captura los perfiles) y la de backend (dónde se guardan y consultan).
Parca cubre ambas en un solo paquete autocontenido. El agente eBPF de OpenTelemetry cubre solo la recolección, pero es el que marca el rumbo del ecosistema: el día que la señal Profiles llegue a estable, recolectar perfiles vía OTLP será tan natural como exportar trazas hoy. Y Pyroscope se posiciona sobre todo como backend —con SDKs propios— capaz de ingerir tanto su instrumentación como los datos del agente eBPF de OTel.
De ahí que las combinaciones sean lo normal y no la excepción: el agente eBPF de OpenTelemetry recolectando a nivel de sistema y enviando a Pyroscope como almacén y visualizador es, ahora mismo, una de las arquitecturas más alineadas con el futuro. Parca tiene sentido cuando quieres algo cerrado, propio y bajo tu control, sin atarte a un stack concreto.
La decisión real, como casi siempre, depende menos de la herramienta y más de tu contexto: qué stack ya usas, qué lenguajes predominan, cuánta madurez exiges hoy y cuánta independencia quieres mantener mañana. Lo que ya no es defendible es seguir esperando a que un usuario se queje de que algo va lento para entonces ponerse a perfilar a mano. El continuous profiling dejó de ser un lujo de hyperscalers; con estas herramientas, y con la cuarta señal a punto de cuajar como estándar, es una opción al alcance de cualquier equipo que se tome el rendimiento en serio.
Para seguir aprendiendo
- Documentación de Parca: arquitectura, Parca Agent, ingesta pprof y despliegue en Kubernetes.
- Documentación de Grafana Pyroscope: modelo de datos, SDKs e integración con el resto del stack de Grafana.
- Profiles | OpenTelemetry: la cuarta señal explicada por el propio proyecto.
- OpenTelemetry Profiles Enters Public Alpha: el anuncio oficial del estado Alpha, con el detalle del agente eBPF como receiver del Collector.
- Repositorio opentelemetry-ebpf-profiler: código, lenguajes soportados y backends compatibles.
- Brendan Gregg, BPF Performance Tools (Addison-Wesley, 2019): la referencia para entender eBPF aplicado a rendimiento y profiling.
