Grafana Beyla[1] resuelve un problema clásico de observabilidad: cómo instrumentar apps legacy o de terceros sin tocar el código fuente. En lugar de requerir cambios en el código y una integración de SDK, Beyla observa syscalls vía eBPF. Genera trazas OpenTelemetry automáticamente para Go, Java, Python, Node y Rust, sin una sola línea de código añadida a la aplicación.

Puntos clave

  • Un único agente por nodo (DaemonSet en K8s) instrumenta todas las apps sin requerir cambios de código.

  • Genera métricas RED (rate, errors, duration) y spans OTLP compatibles con cualquier backend OTel.

  • Overhead medido: 0,5-2 % de CPU adicional por agente y ~50-100 MB de memoria; un coste bajo para producción.

  • La propagación de contexto distribuido solo funciona si la app reenvía las cabeceras W3C TraceContext.

  • No puede ver métricas de negocio ni lógica interna: para eso sigue siendo imprescindible el SDK manual.

Qué hace Beyla

  • Auto-instrumentación de peticiones HTTP/gRPC.

  • Genera spans OTel con service name, method, status code y latencia.

  • Exporta OTLP a cualquier backend compatible (Tempo, Jaeger, Datadog).

  • Multi-lenguaje: compilados (Go, Rust) e interpretados (Python, Node).

  • DNS tracking y SQL tracking (limitado).

Cómo funciona: el modelo eBPF

[App A]   [App B]   [App C]
            |        /
         (syscalls)
            |       /
     [Beyla eBPF agent]
           ↓ OTLP
     [OTel Collector / Grafana Tempo]

Beyla se ejecuta como DaemonSet (un pod por nodo) y observa el tráfico de todas las aplicaciones del mismo nodo mediante programas eBPF anclados a las interfaces de red y syscalls del kernel. Requiere kernel 5.8+ (recomendado) y containers con privilegios elevados.

Instalación en Kubernetes

helm repo add grafana https://grafana.github.io/helm-charts
helm install beyla grafana/beyla 
  --set env.BEYLA_AUTO_INSTRUMENT_TARGET=my-service 
  --set env.OTEL_EXPORTER_OTLP_ENDPOINT=http://tempo:4317

Configuración manual alternativa:

service_name: my-api
discovery:
  services:
    - open_ports: 8080
    - exe_path: ".*/my-api"

otel_traces_export:
  endpoint: http://tempo:4317
  protocol: grpc

otel_metrics_export:
  endpoint: http://mimir:4317

Las apps se identifican por puerto, ruta del ejecutable o labels de Kubernetes.

Lenguajes soportados

  • Go: excelente, nativo y con visibilidad profunda.

  • Rust: bueno.

  • C/C++: funcional.

  • Java: HTTP básico (el Java agent da auto-instrumentación más rica).

  • Python: requests, aiohttp, Django.

  • Node.js: http, express, fetch.

  • .NET: básico.

Para Go y Rust, Beyla se acerca a la cobertura de un SDK manual. Para el resto, complementa sin reemplazar.

Beyla vs SDK: cuándo usar cada uno

Aspecto Beyla (eBPF) SDK manual
Cambios de código Ninguno Requeridos
Granularidad Límites de llamada Lógica de negocio
Propagación de contexto Basada en cabeceras Explícita
Métricas de negocio No Sí
Distributed tracing async Limitado Completo
Overhead de rendimiento 1-3 % 1-5 %

Beyla brilla como primer paso, con apps legacy y para quick wins de cobertura amplia. El SDK es imprescindible para una observabilidad rica del negocio. La combinación de ambos es el patrón más común en producción, como describe el artículo sobre unificación con OpenTelemetry: Beyla para cobertura amplia, SDK para las apps críticas con instrumentación profunda.

Integración con el stack Grafana

Stack completo recomendado:

  • Beyla en cada nodo → OTLP.

  • Grafana Alloy (opcional) como collector intermedio.

  • Grafana Tempo para trazas.

  • Grafana Mimir / Prometheus para métricas.

  • Grafana para visualización.

El Service Graph se genera automáticamente de los datos de Beyla. Encaja también con un stack de alertas bien configurado; ver el artículo de SLOs y error budgets con Prometheus para definir los umbrales correctos sobre estas métricas RED.

Limitaciones honestas

  • Propagación de contexto limitada si la app no reenvía las cabeceras W3C TraceContext.

  • Spans internos de la app no visibles: Beyla solo ve ingress/egress.

  • Métricas de negocio imposibles: Beyla solo observa syscalls.

  • HTTPS: Beyla no descifra (ve solo metadatos TLS).

  • Kernel requirements: 5.8+ recomendado.

  • Superficie de seguridad considerable: container privilegiado, HostPID, HostNetwork. RBAC estricto es obligatorio.

Overhead real medido

  • CPU: 0,5-2 % por agente Beyla.

  • Memoria: ~50-100 MB.

  • Red: mínima (OTLP comprimido).

  • Latencia en apps: <1 ms añadido.

Con esas cifras puedes dejarlo en producción.

Path de adopción incremental

  • Desplegar Beyla en staging observando algunos servicios.

  • Validar overhead y calidad de los datos.

  • Extender cluster-wide.

  • Comparar con SDK en apps ya instrumentadas para identificar los huecos de cobertura.

  • Decidir qué apps mantienen ambos y cuáles solo Beyla.

El rollback se hace en un comando: no hay cambios en las apps.

Conclusión

Grafana Beyla es la herramienta ideal para arrancar observabilidad sin un proyecto largo de instrumentación. Para apps Go y servicios legacy, el valor se ve desde el primer despliegue. Para apps modernas con SDK correcto, Beyla complementa sin reemplazar. La combinación Beyla + SDK OTel cubre el espectro completo de observabilidad con el mínimo esfuerzo acumulado.

Para equipos en el stack Grafana, es una adición natural. Para equipos en Datadog o New Relic, el output OTLP de Beyla es perfectamente portable.

Este artículo también está disponible en inglés.

Fuentes:

  1. Grafana Labs: página oficial de Grafana Beyla[1]
  2. Grafana Beyla: repositorio y documentación en GitHub[2]
  3. ebpf.io: qué es eBPF y cómo funciona[3]
  4. OpenTelemetry: documentación de trazas (spans)[4]
  5. W3C: especificación Trace Context (propagación de cabeceras)[5]

Preguntas frecuentes

¿Cuánto overhead añade Beyla a las aplicaciones en producción?

El overhead medido es de 0,5-2 % de CPU adicional por agente y unos 50-100 MB de memoria. El tráfico de red es mínimo porque el OTLP va comprimido, y la latencia añadida en las apps es de menos de 1 ms. Con esas cifras puedes dejarlo en producción, y el rollback se hace en un comando porque no hay ningún cambio en las aplicaciones.

¿Funciona el tracing distribuido con Beyla si no toco el código?

Solo parcialmente. La propagación de contexto se basa en cabeceras, así que las trazas distribuidas únicamente se enlazan si la aplicación reenvía las cabeceras W3C TraceContext. Beyla ve solo ingress y egress, no los spans internos de la app, y el tracing distribuido asíncrono es limitado. Para lógica de negocio, métricas de negocio y trazas async completas sigue siendo imprescindible el SDK manual de OpenTelemetry.

¿Qué permisos y kernel necesita Beyla en Kubernetes?

Beyla se despliega como DaemonSet, un pod por nodo, y requiere kernel 5.8 o superior (recomendado) y contenedores con privilegios elevados: container privilegiado, HostPID y HostNetwork. Es una superficie de seguridad considerable, por lo que un RBAC estricto es obligatorio. Se instala con Helm desde el repositorio grafana/beyla y las apps se identifican por puerto, ruta del ejecutable o labels de Kubernetes.

Fuentes

  1. Grafana Beyla
  2. Grafana Beyla: repositorio y documentación en GitHub
  3. ebpf.io: qué es eBPF y cómo funciona
  4. OpenTelemetry: documentación de trazas (spans)
  5. W3C: especificación Trace Context (propagación de cabeceras)