Parca: perfilado continuo abierto basado en eBPF

Actualizado: 2026-05-03

Parca^[1] convierte el profiling en una señal de observabilidad continua. Tradicionalmente, el profiling era una herramienta ad hoc: se abría pprof cuando algo iba mal. Parca lo hace 24 horas al día, 7 días a la semana, en todo el cluster, a través de eBPF, con un overhead inferior al 1 % de CPU. El resultado: ves cómo evoluciona el perfil de CPU de tus servicios, detectas regresiones de rendimiento antes de que lleguen a producción y el debugging adquiere una nueva dimensión.

Puntos clave

• El perfilado continuo via eBPF no requiere instrumentar las aplicaciones.
• El overhead es lo suficientemente bajo (0,5-1 % de CPU por nodo) para correr siempre, no solo durante incidentes.
• La comparación temporal antes/después de un despliegue es el caso de uso con mayor retorno inmediato.
• Para apps compiladas (Go, Rust, C), Parca es casi perfecto; para apps interpretadas, conviene complementarlo.
• El profiling continuo es la cuarta señal de observabilidad, después de métricas, logs y trazas.

Por qué el profiling continuo cambia las reglas

El ciclo habitual de debugging de rendimiento tiene un problema estructural: cuando detectas que algo va lento, el perfil del momento en que ocurrió ya no existe. Con Parca, ese perfil siempre está disponible. Almacena muestras comprimidas de CPU con resolución temporal, de modo que puedes comparar el comportamiento antes y después de cualquier despliegue, o reconstruir qué estaba haciendo el servicio durante un pico de latencia detectado cuarenta minutos después.

La integración con el stack de observabilidad estándar es directa. Parca expone datos en un formato que Grafana puede consumir, con lo que la cuarta señal encaja junto a las métricas de Prometheus, los logs de Loki y las trazas de Tempo:

• Métricas: ¿qué está pasando?
• Logs: ¿qué ocurrió exactamente?
• Trazas: ¿por qué tardó este request?
• Profiles: ¿qué función consume la CPU de este servicio?

Instalación en Kubernetes

Parca se despliega como un DaemonSet por nodo (el agente) más un servidor central para almacenamiento y UI:

helm repo add parca https://parca-dev.github.io/helm-charts
helm install parca-agent parca/parca-agent --namespace monitoring
helm install parca parca/parca --namespace monitoring

El agente perfila por defecto todos los procesos del nodo. Se puede filtrar por labels de pod, namespace o contenedor para reducir el volumen de datos.

La interfaz: qué ves y cómo usarlo

La UI de Parca ofrece cuatro vistas principales:

• Vista temporal: muestreo de CPU por servicio a lo largo del tiempo, para identificar cuándo ocurrió un cambio.
• Flame graph: jerarquía de funciones consumiendo CPU. El ancho de cada barra es proporcional al tiempo consumido; la profundidad refleja el call stack.
• Comparación: diff entre dos períodos (antes y después de un deploy) con color para destacar qué funciones empeoraron o mejoraron.
• Vista iceberg: inversión del flame graph para ver los consumidores más costosos de abajo hacia arriba.

Cómo leer un flame graph:

• Ancho = tiempo de CPU: cuanto más ancha la barra, más CPU consume esa función.
• Altura = profundidad de llamada: las barras superiores son las llamadas más externas.
• Busca los plateau anchos en la parte alta: ahí está el trabajo real.
• En comparaciones, el rojo indica regresión y el verde, mejora.

Para equipos sin experiencia previa, el tutorial de Brendan Gregg —quien popularizó los flame graphs— es la referencia más completa.

Parca frente a Pyroscope

Pyroscope^[2] (integrado ahora en Grafana) tiene soporte multilenguaje más maduro para Python, Ruby, Node, Java y .NET, y encaja de forma nativa en el stack Grafana. La desventaja es que requiere instrumentación por lenguaje.

Parca, en cambio:

• Un único agente eBPF perfila todos los lenguajes sin modificar código.
• El soporte de Go, Rust y C/C++ con debug info es excelente.
• Para Java y .NET existe soporte experimental mediante stack walkers específicos.
• Para Python y Node, el agente ve frames del intérprete, no código Python: complementar con Pyroscope o py-spy.

La elección práctica: Parca para clusters Kubernetes con mix de lenguajes y política de zero-instrumentation; Pyroscope para equipos centrados en Grafana con apps ya instrumentadas.

Overhead y almacenamiento

Los números reales son confortables:

• CPU: 0,5-1 % por nodo con el agente activo.
• Almacenamiento: aproximadamente 1 GB/día para un cluster de 50 nodos con muestras comprimidas.
• Red: mínimo, las muestras se agregan en el nodo antes de enviarse.

El servidor Parca puede almacenar en S3 (o cualquier object storage compatible) con políticas de retención configurables, manteniendo el coste bajo control.

Seguridad

El agente eBPF requiere permisos elevados:

• Contenedor privilegiado para acceso a eBPF.
• HostPID para ver procesos del host.
• HostNetwork en algunos escenarios.

Esto representa una superficie de ataque significativa. Limita los permisos al mínimo necesario, audita regularmente y considera si el entorno tiene requisitos de hardening que hagan preferible una alternativa sin acceso al host.

El perfilado continuo como cultura de ingeniería

Más allá de la herramienta, adoptar profiling continuo produce cambios en cómo los equipos trabajan:

• Las regresiones de rendimiento se detectan en staging, no en producción.
• Las decisiones de optimización se toman sobre datos, no sobre intuición.
• Los nuevos miembros del equipo pueden explorar la codebase a través de flame graphs reales.
• El capacity planning se basa en perfiles de CPU medidos, no en estimaciones.

Equipos que mantienen profiling continuo activo reportan reducciones significativas en incidentes relacionados con rendimiento. La inversión de setup —un par de horas de Helm— se amortiza en el primer despliegue donde el flame graph muestra una regresión que de otro modo hubiera llegado a producción.

Conclusión

Parca es la cuarta señal de observabilidad, y adoptarla cuesta menos que ignorarla. Para apps compiladas en Go, Rust o C, el soporte eBPF es prácticamente perfecto. Para apps interpretadas, conviene combinarlo con perfiladores por lenguaje. Si ya tienes OpenTelemetry para trazas y métricas, añadir Parca cierra el stack. Para equipos que se toman en serio el rendimiento, el overhead de 0,5 % de CPU es un precio muy razonable por no volver a hacer debugging de rendimiento a ciegas.

1. Parca
2. Pyroscope