La observabilidad de 2025 tiene una promesa recurrente: ver lo que pasa dentro de tus procesos sin tocar codigo. La combinacion de Parca para perfiles continuos, Beyla para auto-instrumentacion via eBPF y Grafana como capa de visualizacion lleva un anio y medio siendo uno de los stacks que mas interes despierta en conferencias. En este post recojo lo que he aprendido integrando las tres piezas en un par de clusters de pruebas y lo que no acaba de encajar todavia para produccion.
De que estamos hablando
Parca es un proyecto de Polar Signals que hace perfilado continuo. Captura muestras de pila de CPU en todos los procesos del sistema mediante eBPF, las agrega con criterios configurables, y las persiste en su propio almacenamiento columnar. La idea es tener perfiles disponibles todo el tiempo, no solo cuando arrancas una herramienta manual. Asi, cuando detectas un pico de CPU a las 3 de la madrugada, puedes ver exactamente que funcion lo causo sin reproducir el incidente.
Beyla es el agente de auto-instrumentacion de Grafana Labs publicado en 2023. Tambien usa eBPF, pero con un objetivo diferente: generar metricas RED, trazas distribuidas y logs a partir de observar las llamadas de red y las funciones de usuario del proceso. No requiere modificar el binario ni anadir una biblioteca, y soporta HTTP, gRPC, SQL y varios sistemas de mensajeria. La gran ventaja es que obtienes telemetria estandar OpenTelemetry sin que los desarrolladores tengan que tocar el codigo.
Grafana es la pieza familiar: cuadros, alertas, consultas PromQL, LogQL y TraceQL. En este stack actua como capa unica donde se consultan las metricas de Beyla, los logs, las trazas y los perfiles de Parca. La integracion con Parca via plugin Grafana es la pieza mas reciente y la que me interesa evaluar.
Que tienen en comun y por que importa
Las tres piezas comparten un fundamento: eBPF. Esto no es decorativo, define las propiedades del stack. eBPF permite anadir sondas al kernel sin modificarlo, con coste bajo, aislado y seguro por diseno. Esto contrasta con modelos antiguos donde la instrumentacion exigia modificar el proceso observado o inyectar una biblioteca via LD_PRELOAD, con la fragilidad que eso implicaba.
La consecuencia practica es que el stack no necesita sidecars. No hay un contenedor extra por cada pod que haya que mantener, versionar y monitorear. El agente eBPF se ejecuta una vez por nodo, observa todos los procesos del nodo, y envia datos al backend. Esto reduce la carga operativa de forma significativa en un cluster mediano. En mi entorno pase de 120 sidecars para trazas a 3 agentes eBPF, y la simplicidad del cluster mejoro mucho.
Parca en detalle
Parca captura perfiles de CPU mediante la sonda perf_event de eBPF, que muestrea la pila cada 10 o 20 milisegundos. Las muestras se agregan en memoria y se comprimen en el formato pprof que ya usan otras herramientas de perfilado. El agente envia agregados al servidor Parca cada minuto, donde se almacenan en una base de datos columnar propia construida sobre FrostDB.
Lo que diferencia a Parca de un perfilador clasico es la continuidad. No hay que encender el perfilado cuando sospechas un problema; ya estaba encendido cuando el problema ocurrio. En mis pruebas descubri dos problemas de rendimiento que habrian sido imposibles de capturar con perfilado manual: una regresion en serializacion JSON que aparecia en una rama rara, y un pico de GC en Java que duraba 200 ms cada 6 horas. Sin captura continua, ninguno se habria detectado porque el fallo no se reproducia facilmente.
El coste de ejecutar Parca es sorprendentemente bajo. En un nodo de 32 nucleos con 150 procesos activos, el agente consume entre 0.5% y 1% de CPU. El almacenamiento crece unos 30 MB por nodo por dia con el nivel de muestreo por defecto, lo que para un cluster pequenio es manejable y para uno grande requiere politica de retencion. Parca soporta retencion tiered con datos calientes en disco local y frios en S3.
Beyla en detalle
Beyla tiene un enfoque complementario. En lugar de muestrear pilas, observa las llamadas al kernel asociadas a operaciones de red: syscalls accept, connect, send, recv, y las mapea a protocolos HTTP, gRPC y SQL. Con esa informacion genera automaticamente tres senales: metricas de tasa, error y duracion por servicio; spans de traza con el flujo de peticiones; y logs estructurados de cada llamada.
La magia es que no requiere que el proceso colabore. Un binario compilado hace dos anios sin pensar en observabilidad obtiene, al correr junto a Beyla, trazas OpenTelemetry estandar. He probado esto con una aplicacion Django que hacia imposible instrumentar manualmente y con un binario Go antiguo del que no teniamos fuente. En ambos casos las metricas RED aparecieron en pocos minutos.
El limite de Beyla es que solo observa lo que pasa por red o por syscalls bien conocidos. No puede anadir spans dentro del codigo, no puede leer variables locales, no puede seguir el flujo logico dentro de un proceso. Para observabilidad profunda de logica de negocio sigue haciendo falta instrumentacion manual. Beyla es excelente para obtener el 70% de valor sin trabajo, pero el 30% restante exige trabajo explicito.
Donde la integracion todavia roza
El stack en conjunto funciona bien, pero hay dos fricciones que he encontrado. La primera es la correlacion entre senales. Grafana permite saltar de una traza a sus perfiles Parca asociados, pero la correlacion depende de que la traza tenga el trace_id correcto y de que Parca haya etiquetado el perfil con ese trace_id. En teoria Beyla envia trace_id y Parca lo recibe, pero en la practica la propagacion de contexto en procesos asyncronos todavia tiene agujeros. En un servicio Python con aiohttp vi perfiles sin trace_id vinculado el 40% del tiempo.
La segunda friccion es el soporte de lenguajes. Parca captura perfiles de todos los procesos por igual, pero la capacidad de simbolizar las pilas, es decir, traducir direcciones de memoria a nombres de funcion, depende del binario. Para Go la simbolizacion funciona de serie. Para C y C++ depende de tener simbolos de depuracion disponibles. Para Java y JVM hace falta un agente adicional que exporte el mapa de compilacion JIT, que es una pieza mas a mantener. Para Node.js y Python el soporte ha mejorado en 2025 pero no es perfecto.
Configurar el stack
Montar las tres piezas en un cluster de pruebas no es complicado, pero hay que seguir el orden. Primero Parca agente como DaemonSet con permisos privilegiados para eBPF, y Parca servidor como Deployment con almacenamiento persistente. Segundo Beyla como DaemonSet o como sidecar por nodo segun preferencia, con configuracion de servicios a instrumentar. Tercero Grafana con los plugins de Parca y con datasources para Tempo, Loki y Mimir o Prometheus.
La complicacion esta en los permisos y networking. eBPF requiere acceso al kernel del nodo, lo que implica hostPID, hostNetwork y varios capabilities. En clusters con politica Pod Security estricta hay que anadir excepciones explicitas. El modelo de confianza cambia: los agentes tienen visibilidad muy amplia sobre el nodo, y cualquier bug de seguridad en el agente tendria impacto grande. Polar Signals y Grafana Labs son proyectos con buena reputacion, pero conviene estar atentos a los avisos de seguridad.
Donde este stack no es la respuesta
Hay casos donde el stack sin sidecars no es adecuado. El primero es cuando el cluster corre sobre kernels muy antiguos, anteriores a 5.4, donde el soporte eBPF es limitado. En 2025 esto afecta sobre todo a clusters vSphere o sistemas heredados. El segundo es cuando se necesita instrumentar logica interna de negocio: decidir que parte del calculo de precio es lenta, por ejemplo, sigue exigiendo instrumentacion manual con OpenTelemetry.
El tercero es cuando el equipo no tiene cultura de observabilidad. Tener perfiles continuos y metricas RED automaticas no sirve de mucho si nadie los mira. El stack facilita la instrumentacion pero no sustituye la disciplina de investigar incidentes y construir paneles utiles. En un equipo que no miraba metricas antes, introducir Parca no cambia el comportamiento solo porque los datos existan.
Cuando compensa
Mi regla practica tras estos meses es que el stack Parca, Beyla y Grafana compensa sobre todo en dos escenarios. Uno, equipos con muchas aplicaciones heterogeneas donde instrumentar manualmente es inviable por volumen. Con treinta servicios en distintos lenguajes, el ahorro de no anadir SDK de OTel a cada uno es enorme. Dos, equipos que ya usan Grafana y quieren profundidad sin cambiar de herramienta. La integracion nativa reduce friccion y la curva de aprendizaje es corta.
En entornos homogeneos con pocos servicios, la instrumentacion manual con OpenTelemetry sigue siendo comparable en esfuerzo y da mas control. Si tienes cinco servicios en Go bien mantenidos, anadir el SDK de OTel no es carga insoportable y te deja control total sobre que y como instrumentas.
Mi lectura
Lo que me parece interesante del stack es que representa un cambio de modelo mental sobre la observabilidad. Antes la instrumentacion era responsabilidad del desarrollador, que debia anadir codigo para ser observable. Ahora la observabilidad puede ser una capa de infraestructura, externa al codigo, que el operador activa. Esta separacion de responsabilidades tiene implicaciones mas alla de lo tecnico: permite que equipos de plataforma entreguen observabilidad como servicio sin depender de que cada equipo de producto haga su parte.
La integracion del stack aun tiene bordes rugosos. La correlacion entre senales, la simbolizacion de pilas en JVM, la propagacion de contexto en async, son areas donde falta pulimento. No creo que esten resueltas antes de 2026, pero la direccion es clara y los avances cada trimestre son visibles.
Lo que no cambia es que la observabilidad sigue siendo disciplina, no herramienta. Tener Parca, Beyla y Grafana bien montados no convierte a un equipo sin cultura en un equipo SRE. Facilita el trabajo pero no lo sustituye. Si un equipo ya mira metricas y tiene cadena de guardia madura, este stack le da un salto de profundidad real. Si no, primero conviene construir la disciplina y luego anadir las herramientas.
