Grafana Beyla: auto-instrumentación sin tocar código

Actualizado: 2026-05-03

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 más una integración de SDK, Beyla observa syscalls vía eBPF y 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 — 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, 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

Beyla brilla como primer paso, con apps legacy y para quick wins de cobertura amplia. El SDK es imprescindible para observabilidad rica a nivel de 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:

1. Beyla en cada nodo → OTLP.
2. Grafana Alloy (opcional) como collector intermedio.
3. Grafana Tempo para trazas.
4. Grafana Mimir / Prometheus para métricas.
5. 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.

Suficientemente bajo para producción en la mayoría de cargas.

Path de adopción incremental

1. Desplegar Beyla en staging observando algunos servicios.
2. Validar overhead y calidad de los datos.
3. Extender cluster-wide.
4. Comparar con SDK en apps ya instrumentadas — identificar gaps.
5. Decidir qué apps mantienen ambos y cuáles solo Beyla.

El rollback es trivial: 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 es inmediato. 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.

1. Grafana Beyla