Grafana Beyla: Auto-Instrumentation Without Touching Code

Actualizado: 2026-05-03

Grafana Beyla^[1] solves a classic observability problem: how to instrument legacy or third-party apps without touching source code. Instead of requiring code changes plus SDK integration, Beyla observes syscalls via eBPF and automatically generates OpenTelemetry traces — for Go, Java, Python, Node, and Rust, without a single line added to the application.

Key takeaways

• A single agent per node (DaemonSet in K8s) instruments all apps without requiring code changes.
• Generates RED metrics (rate, errors, duration) and OTLP spans compatible with any OTel backend.
• Measured overhead: 0.5-2% additional CPU per agent and ~50-100 MB memory — low enough for production.
• Distributed context propagation only works if the app forwards W3C TraceContext headers.
• It cannot see business metrics or internal logic: the manual SDK remains essential for that.

What Beyla does

• Auto-instrumentation of HTTP/gRPC requests.
• Generates OTel spans with service name, method, status code, and latency.
• Exports OTLP to any compatible backend (Tempo, Jaeger, Datadog).
• Multi-language: compiled (Go, Rust) and interpreted (Python, Node).
• DNS tracking and SQL tracking (limited).

How it works: the eBPF model

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

Beyla runs as a DaemonSet — one pod per node — and observes traffic from all applications on the same node via eBPF programs attached to network interfaces and kernel syscalls. Requires kernel 5.8+ (recommended) and containers with elevated privileges.

Kubernetes installation

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

Alternative manual configuration:

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

Apps are targeted by port, executable path, or Kubernetes labels.

Supported languages

• Go: excellent — native, deep visibility.
• Rust: good.
• C/C++: functional.
• Java: basic HTTP (Java agent gives richer auto-instrumentation).
• Python: requests, aiohttp, Django.
• Node.js: http, express, fetch.
• .NET: basic.

For Go and Rust, Beyla approaches the coverage of a manual SDK. For the rest, it complements without replacing.

Beyla vs SDK: when to use each

Beyla shines as a first step, with legacy apps, and for quick wins in broad coverage. The SDK is essential for rich business-level observability. Using both is the most common production pattern, as described in the OpenTelemetry unification article: Beyla for broad coverage, SDK for critical apps with deep instrumentation.

Integration with the Grafana stack

Recommended full stack:

1. Beyla on each node → OTLP.
2. Grafana Alloy (optional) as intermediate collector.
3. Grafana Tempo for traces.
4. Grafana Mimir / Prometheus for metrics.
5. Grafana for visualisation.

The Service Graph is generated automatically from Beyla data. It also pairs with a well-configured alerting setup; see the SLOs and error budgets with Prometheus article for defining correct thresholds on these RED metrics.

Honest limitations

• Limited context propagation if the app doesn’t forward W3C TraceContext headers.
• Internal app spans invisible — Beyla only sees ingress/egress.
• Business metrics impossible — Beyla only observes syscalls.
• HTTPS: Beyla doesn’t decrypt (sees only TLS metadata).
• Kernel requirements: 5.8+ recommended.
• Considerable security surface: privileged container, HostPID, HostNetwork. Strict RBAC is mandatory.

Real measured overhead

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

Low enough for production on most workloads.

Incremental adoption path

1. Deploy Beyla in staging observing some services.
2. Validate overhead and data quality.
3. Extend cluster-wide.
4. Compare with SDK on already-instrumented apps — identify gaps.
5. Decide which apps keep both and which use only Beyla.

Rollback is trivial: no changes to the apps.

Conclusion

Grafana Beyla is the ideal tool to kickstart observability without a long instrumentation project. For Go apps and legacy services, the value is immediate. For modern apps with a proper SDK, Beyla complements without replacing. The Beyla + OTel SDK combination covers the full observability spectrum with minimum accumulated effort. For teams on the Grafana stack, it is a natural addition. For Datadog or New Relic teams, Beyla’s OTLP output is fully portable.

1. Grafana Beyla