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

javi
Dashboard de monitorización con gráficos y métricas en pantalla grande

Grafana Beyla resuelve problema clásico de observability: instrumentar apps legacy o de terceros. En vez de requerir cambios de código + SDK integration, Beyla observa syscalls via eBPF y genera traces OpenTelemetry automáticamente. Para Go, Java, Python, Node, Rust — sin tocar el código.

Qué hace

  • Auto-instrumentation de HTTP/gRPC requests.
  • Genera spans OTel con service name, method, status, latency.
  • Exporta OTLP a cualquier backend (Tempo, Jaeger, Datadog).
  • Multi-language: funciona con compiled (Go, Rust) e interpreted (Python, Node).
  • DNS tracking, SQL tracking (limited).

Arquitectura

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

Un Beyla por nodo (DaemonSet en K8s). Observa traffic de apps en el mismo nodo.

Instalación 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

O config manual:

service_name: my-api
log_level: info

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

Target apps por puerto, exe path, k8s labels.

Lenguajes soportados

  • Go: excelente (native, deep visibility).
  • Rust: bueno.
  • C/C++: funcional.
  • Java: HTTP básico (auto-instrumentation via Java agent más rica).
  • Python: requests, aiohttp, Django.
  • Node.js: http, express, fetch.
  • .NET: básico.

Para Go/Rust, casi como SDK manual. Para otros, complementa SDK.

Métricas y traces

Beyla genera:

Traces:

  • Span per HTTP/gRPC request.
  • Attributes: method, path, status, duration.
  • Context propagation (via W3C TraceContext headers).

Métricas:

  • RED metrics (rate, errors, duration).
  • Histogram buckets para latency.
  • Service graph metrics.

Output OTLP estándar — cualquier backend OTel compatible.

Beyla vs SDK

Aspecto Beyla (eBPF) SDK manual
Code changes Zero Required
Granularity Call boundaries Custom business logic
Context propagation Header-based Explicit
Business metrics No Yes
Distributed tracing Limited para async Full
Performance overhead 1-3% 1-5%

Beyla: great primer paso, apps legacy, quick wins. SDK: indispensable para rich business-level observability.

Usar ambos es pattern común: Beyla para coverage amplio, SDK para apps críticas con deep instrumentation.

Casos de uso

Donde Beyla brilla:

  • Legacy apps que no puedes modify.
  • 3rd party apps (databases, caches) para observar ingress/egress.
  • Quick POC de observability antes de invertir en SDK.
  • Fill gaps en apps donde SDK es imperfecto.
  • Multi-language cluster con observability uniforme sin adaptar cada lenguaje.

Limitations

Honest:

  • Context propagation limitado si app no forward trace headers.
  • Deep spans dentro de app no visibles (solo ingress/egress).
  • Business metrics impossible — Beyla solo ve syscalls.
  • HTTPS encryption: Beyla no decrypta (ve solo TLS metadata).
  • Performance overhead en apps I/O-heavy.
  • eBPF kernel requirements: 5.8+ recommended.

Integración con stack Grafana

Stack completo:

  1. Beyla en cada nodo → OTLP.
  2. Grafana Alloy (optional) como collector.
  3. Grafana Tempo para traces.
  4. Grafana Mimir/Prometheus para metrics.
  5. Grafana para visualization.

Service Graph generado automáticamente de Beyla data.

Context propagation

Para traces distribuidos complete, apps deben forward W3C TraceContext:

  • Go HTTP client: añadir OTel HTTP client middleware.
  • Python requests: opentelemetry-instrumentation-requests.
  • Envoy sidecar: automaticamente propaga.

Sin propagation, cada servicio tiene traces locales pero no unificadas cross-service.

Beyla vs Pixie

Pixie (CNCF sandbox) es competidor más completo:

  • Visualization integrada.
  • Query language (PxL).
  • Flame graphs.

Beyla es más focused:

  • Generate OTel data.
  • Lightweight.
  • Integra con Grafana stack nativo.

Para Grafana-heavy stacks, Beyla. Para Pixie-native, Pixie.

Overhead real

Medido:

  • CPU: 0.5-2% per Beyla agent.
  • Memory: ~50-100MB.
  • Network: minimal (OTLP compressed).
  • Latency on apps: <1ms added.

Low-enough para producción.

Security

Requiere:

  • Privileged container (eBPF).
  • HostPID para ver processes.
  • HostNetwork para ciertos features.

Superficie de seguridad considerable. RBAC estricto recomendado.

Deployment incremental

Adoption path:

  1. Beyla en staging observando algunos services.
  2. Validate overhead y data quality.
  3. Roll out cluster-wide.
  4. Compare with SDK en apps instrumentadas, identify gaps.
  5. Decide qué apps mantienen ambos, cuáles solo Beyla.

Fácil rolling back — no changes en apps.

Conclusión

Grafana Beyla es tool ideal para kickstart observability sin project instrumentation largo. Para Go apps y legacy services, valor inmediato. Para apps modernas con SDK proper, Beyla complementa pero no reemplaza. La combinación Beyla + OTel SDK cubre spectrum de observability con minimum effort. Para teams en Grafana stack, inclusion natural. Para teams en Datadog/New Relic, Beyla output OTLP = portable.

Síguenos en jacar.es para más sobre observabilidad, eBPF y Grafana stack.

Entradas relacionadas