Grafana Beyla

Last reviewed Sep 13, 2026 · 864 words

Picture the third-party Go service in your homelab that exposes no metrics, the Node app a friend wrote in 2021, and the Java thing behind the printer. Beyla gets you request rate, error rate and latency histograms for all three, by service and by route, without touching a line of their code or restarting them. It does this with eBPF: kernel probes that watch the sockets and, for some runtimes, the functions those processes use, then export what they see as Prometheus metrics or OpenTelemetry traces. For the unowned half of a stack, that is the difference between graphs and guesswork. The conditions are a Linux kernel from this decade, elevated privileges, and realistic expectations about how deep the traces go.

The kernel is the first thing to check

Beyla needs a kernel with BTF type information, which in practice means 5.8 or newer on mainstream distributions (Ubuntu 22.04 and Debian 12 qualify; RHEL's backported 4.18 also works). Check with ls /sys/kernel/btf/vmlinux; if the file is missing, stop, because no configuration will fix it. It then needs enough privilege to load programs into that kernel: as a systemd service that means root or the capability set the docs list (CAP_BPF, CAP_PERFMON, CAP_SYS_PTRACE and several more); in Docker it means --privileged or those capabilities plus pid: host, since Beyla has to see the processes it is watching. The tool itself is a single Go binary using about 128 MB, which is modest for what it observes, and it is one of the cheaper ways to instrument anything.

One process, one port, one exporter

The minimal setup targets a service by listening port or by executable name and exports Prometheus metrics on a port of your choosing:

services:
  beyla:
    image: grafana/beyla:latest
    pid: host
    privileged: true
    environment:
      BEYLA_OPEN_PORT: "8080"
      BEYLA_PROMETHEUS_PORT: "9400"
    ports:
      - "9400:9400"

Point Prometheus at :9400/metrics and within a scrape interval you have http_server_request_duration_seconds histograms labelled by method, route and status code, plus RPC and SQL client metrics if the process makes those calls. Swap the Prometheus variables for OTEL_EXPORTER_OTLP_ENDPOINT and Beyla ships traces to Tempo or any OTLP collector instead, and on Kubernetes a DaemonSet with a discovery block does the same thing cluster-wide. If you already run Grafana Alloy, it can embed Beyla as a component and you skip the separate container.

Go gets real traces; everything else gets the socket view

Here is the limitation the marketing copy files under "limited language depth". For Go, Beyla attaches uprobes to the standard library's HTTP and gRPC functions, so it reconstructs full spans with context propagation across services and the traces look like ones produced by an SDK. For Java, Node, Python, Ruby, .NET and Rust it watches at the socket and TLS boundary. You still get the RED metrics per route, which is the 80 per cent that matters for dashboards, but distributed traces spanning several non-Go services rely on the propagation headers being passed through by the app, and internal spans (database call inside a handler, cache lookup, queue publish) are visible only when they cross a socket. If you want method-level tracing inside a Python app, an OpenTelemetry SDK still does that job, and Beyla complements rather than replaces it.

It will not read encrypted traffic it cannot hook

TLS termination matters. Beyla handles Go's crypto/tls and OpenSSL-based runtimes through library probes, so a Node or Python service serving HTTPS directly is generally visible. Traffic that terminates in a reverse proxy and arrives at the app as plain HTTP is the easy case and the common one. Where it goes dark is unusual TLS libraries, statically linked binaries with stripped symbols, and anything speaking a protocol Beyla has no parser for. Verify per service with a 5-minute test before assuming coverage.

The wider picture: Beyla is becoming an OpenTelemetry project

Grafana donated the core of Beyla to the OpenTelemetry project in 2025, where it continues as OpenTelemetry eBPF Instrumentation, and Grafana's Beyla is now the vendor distribution of that upstream. For a self-hoster this is good news: the eBPF instrumentation is being maintained by the same community that owns the export format, and the risk of a single vendor deprecating it drops. It also means the configuration keys and image names may shift over the next year, so pin a version and read release notes before pulling. The monitoring category covers the stack you plug it into.

What I'd do

Run Beyla on the box that hosts the services you did not write, with pid: host and a Prometheus port, and import Grafana's RED dashboard on day one. Confirm the kernel has BTF before anything else. For your own Go services, let Beyla replace SDK instrumentation entirely; for everything else, use it for metrics and keep the OpenTelemetry SDK for traces where you need them. That split gives you the Datadog APM view of a homelab for the cost of one container and about 128 MB, which is a bargain I would not have believed in 2022.