Observability in 2025 has a recurring promise: see what is happening inside your processes without touching code. The combination of Parca for continuous profiling, Beyla for eBPF auto-instrumentation, and Grafana for visualisation has been one of the stacks drawing most conference interest for a year and a half. This post gathers what I learned integrating the three pieces in a couple of test clusters and what still does not quite fit for production.
What we are talking about
Parca is a Polar Signals project that does continuous profiling. It captures CPU stack samples from every process on the system via eBPF, aggregates them with configurable criteria, and persists them in its own columnar storage. The idea is to have profiles available all the time, not only when a manual tool is started. That way, when a CPU spike hits at 3 in the morning, you can see exactly which function caused it without reproducing the incident.
Beyla is Grafana Labs’s auto-instrumentation agent released in 2023. It also uses eBPF, but with a different goal: generating RED metrics, distributed traces, and logs by observing the process’s network calls and user-space functions. It does not require binary modification or library injection, and it supports HTTP, gRPC, SQL, and several messaging systems. The big advantage is that you get standard OpenTelemetry telemetry without developers having to touch the code.
Grafana is the familiar piece: dashboards, alerts, PromQL, LogQL, and TraceQL queries. In this stack it acts as a single layer where Beyla metrics, logs, traces, and Parca profiles are queried. The Parca Grafana plugin integration is the most recent piece and the one I wanted to evaluate.
What they share and why it matters
The three pieces share a foundation: eBPF. This is not decorative, it defines the stack’s properties. eBPF allows adding kernel probes without modifying it, at low cost, isolated and safe by design. This contrasts with older models where instrumentation required modifying the observed process or injecting a library via LD_PRELOAD, with the fragility that entailed.
The practical consequence is that the stack needs no sidecars. There is no extra container per pod to maintain, version, and monitor. The eBPF agent runs once per node, observes all processes, and sends data to the backend. This reduces operational load significantly in a medium-sized cluster. In my environment I went from 120 trace sidecars to 3 eBPF agents, and cluster simplicity improved noticeably.
Parca in detail
Parca captures CPU profiles via the perf_event eBPF probe, which samples stacks every 10 or 20 milliseconds. Samples are aggregated in memory and compressed into the pprof format already used by other profiling tools. The agent sends aggregates to the Parca server every minute, where they are stored in a custom columnar database built on FrostDB.
What differentiates Parca from a classic profiler is continuity. You do not turn profiling on when you suspect a problem; it was already on when the problem happened. In my tests I found two performance issues that would have been impossible to capture with manual profiling: a JSON serialisation regression appearing on a rare branch, and a Java GC spike lasting 200 ms every 6 hours. Without continuous capture, neither would have been caught because they did not reproduce easily.
The cost of running Parca is surprisingly low. On a 32-core node with 150 active processes, the agent consumes between 0.5% and 1% CPU. Storage grows about 30 MB per node per day at default sampling, manageable for a small cluster and requiring a retention policy for a large one. Parca supports tiered retention with hot data on local disk and cold on S3.
Beyla in detail
Beyla takes a complementary approach. Instead of sampling stacks, it observes kernel calls associated with network operations: accept, connect, send, recv syscalls, and maps them to HTTP, gRPC, and SQL protocols. With that information it automatically generates three signals: rate, error, and duration metrics per service; trace spans with request flow; and structured logs of each call.
The magic is that it does not require process cooperation. A binary compiled two years ago without observability in mind gets, when run next to Beyla, standard OpenTelemetry traces. I tested this with a Django app that was nearly impossible to instrument manually and with an old Go binary whose source we no longer had. In both cases RED metrics appeared within minutes.
Beyla’s limit is that it only observes what flows through network or well-known syscalls. It cannot add spans inside code, it cannot read local variables, it cannot follow logical flow inside a process. For deep business logic observability, manual instrumentation is still required. Beyla is excellent for getting 70% value with no work, but the remaining 30% demands explicit work.
Where integration still rubs
The stack works well together, but I hit two points of friction. First is signal correlation. Grafana lets you jump from a trace to its associated Parca profiles, but correlation depends on the trace carrying the correct trace_id and on Parca tagging the profile with that trace_id. In theory Beyla emits trace_id and Parca receives it, but in practice context propagation in async processes still has gaps. In a Python service using aiohttp I saw profiles with no linked trace_id 40% of the time.
Second is language support. Parca captures profiles from all processes equally, but the ability to symbolise stacks, meaning translating memory addresses to function names, depends on the binary. For Go symbolisation works out of the box. For C and C++ it depends on having debug symbols available. For Java and the JVM an additional agent is needed to export the JIT compile map, one more piece to maintain. For Node.js and Python, support has improved in 2025 but is not perfect.
Configuring the stack
Setting up the three pieces in a test cluster is not hard, but order matters. First the Parca agent as a DaemonSet with privileged permissions for eBPF, and the Parca server as a Deployment with persistent storage. Second Beyla as a DaemonSet or as a per-node sidecar depending on preference, with configuration for services to instrument. Third Grafana with Parca plugins and datasources for Tempo, Loki, and Mimir or Prometheus.
Complication lies in permissions and networking. eBPF requires access to the node’s kernel, which implies hostPID, hostNetwork, and several capabilities. In clusters with strict Pod Security policy, explicit exceptions are needed. The trust model changes: agents have very wide visibility over the node, and any security bug in the agent would have broad impact. Polar Signals and Grafana Labs are projects with good reputation, but it pays to watch for security advisories.
Where this stack is not the answer
There are cases where the sidecar-free stack is not appropriate. First is when the cluster runs on very old kernels, earlier than 5.4, where eBPF support is limited. In 2025 this affects mainly vSphere clusters or legacy systems. Second is when internal business logic needs instrumentation: deciding which part of price calculation is slow, for instance, still requires manual OpenTelemetry instrumentation.
Third is when the team lacks observability culture. Having continuous profiles and automatic RED metrics is of little use if no one looks at them. The stack simplifies instrumentation but does not replace the discipline of investigating incidents and building useful dashboards. In a team that did not look at metrics before, introducing Parca does not change behaviour just because data exists.
When it is worth it
My practical rule after these months is that the Parca, Beyla, Grafana stack pays off mainly in two scenarios. First, teams with many heterogeneous applications where manual instrumentation is unworkable by volume. With thirty services in different languages, the saving from not adding the OTel SDK to each is enormous. Second, teams already using Grafana who want depth without switching tools. Native integration reduces friction and the learning curve is short.
In homogeneous environments with few services, manual OpenTelemetry instrumentation is comparable in effort and gives more control. If you have five well-maintained Go services, adding the OTel SDK is not unbearable and gives full control over what and how to instrument.
My take
What I find interesting about the stack is that it represents a mental shift about observability. Before, instrumentation was the developer’s responsibility, who had to add code to be observable. Now observability can be an infrastructure layer, external to code, that the operator activates. This separation of responsibilities has implications beyond the technical: it lets platform teams deliver observability as a service without depending on each product team doing its part.
Stack integration still has rough edges. Signal correlation, JVM stack symbolisation, async context propagation are areas lacking polish. I do not think these will be resolved before 2026, but the direction is clear and quarterly progress is visible.
What does not change is that observability remains a discipline, not a tool. Having Parca, Beyla, and Grafana well set up does not turn a team with no culture into an SRE team. It eases work but does not replace it. If a team already watches metrics and has a mature on-call chain, this stack gives a real depth jump. If not, first build the discipline and then add the tools.
