# OpenTelemetry eBPF Profiler: Whole-System Linux Profiling Without Instrumentation

> The OpenTelemetry eBPF Profiler is a Linux-only, whole-system continuous profiler that collects mixed-language stack traces across kernel space, system libraries, and high-level language runtimes without modifying the applications being profiled. It implements the alpha OTel Profiles signal and integrates with the OpenTelemetry Collector as the supported production deployment path.

**open-telemetry/opentelemetry-ebpf-profiler** — The production-scale datacenter profiler (C/C++, Go, Rust, Python, Java, NodeJS, .NET, PHP, Ruby, Perl, ...)

- Repository: https://github.com/open-telemetry/opentelemetry-ebpf-profiler
- Stars: 3,201 · Forks: 438
- Language: Go
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-telemetry-opentelemetry-ebpf-profiler

## What the Profiler Does and Why No Code Changes Are Needed

The OpenTelemetry eBPF Profiler is a Linux kernel-based continuous profiling agent that collects stack traces across a running system without requiring changes to the applications being profiled. The README describes it as 100% non-intrusive: there is no need to load agents or libraries into profiled processes, and no reconfiguration, instrumentation, or restarts of language interpreters and virtual machines are required. The agent supports unwinding each supported language in the default configuration.

This is made possible by eBPF (Extended Berkeley Packet Filter), a Linux kernel technology that allows programs to run in the kernel context with access to process memory and execution state. The profiler loads an eBPF program and its maps, starts unwinding stack frames, and reports captured traces to a backend. The README states that very low overhead is a design priority: the upper limits during testing are 1% CPU and 250 MB of memory, and the agent typically runs well below those limits. These figures are from the project's own testing, not from an external guarantee.

## Language Coverage and the .eh_frame Unwinding Technique

The profiler produces mixed stack traces that span from kernel space through unmodified system libraries into high-level language runtimes. The README lists support for native code in C, C++, Rust, Zig, and Go without requiring debug symbols on the host. For C and C++ specifically, the README notes support without DWARF debug information by leveraging .eh_frame data, a technique described in US patent US11604718B1 cited in the README.

On the high-level language side, the README lists support for the Hotspot JVM (Java), Python, Ruby, PHP, Node.JS, V8 (JavaScript), Perl, Erlang, and .NET. System libraries without frame pointers and without debug symbols on the host are also supported. ARM64 is supported for all unwinders alongside amd64. The profiler also captures native inline frames, which reflect compiler inlining decisions and provide a more precise view of the actual call chain than a simple function boundary would show.

## Building the Profiler

The README documents build requirements: Docker is required for containerized builds, and both amd64 and arm64 architectures are supported. For Linux, the Makefile provides a make agent target:

```sh
make agent
```

To cross-compile for a different architecture, pass the TARGET_ARCH variable:

```sh
make agent TARGET_ARCH=arm64
```

The resulting binary is named ebpf-profiler in the current directory. Without Docker, the agent can be built by installing the dependencies listed in the Dockerfile directly and then running:

```sh
make
```

The OTel Collector receiver binary can be built with:

```sh
make otelcol-ebpf-profiler
```

The go.mod file specifies Go 1.26.0. The project also includes Rust components (rust-crates/symblib and rust-crates/symblib-capi) with a minimum Rust version of 1.88.0 per Cargo.toml. The Dockerfile uses debian:trixie as its base image and installs LLVM 17 and Clang 17 as build dependencies alongside the Go toolchain extracted from go.mod automatically.

For running the standalone development binary:

```sh
sudo ./ebpf-profiler -collection-agent=127.0.0.1:11000 -disable-tls
```

For the OTel Collector receiver:

```sh
sudo ./otelcol-ebpf-profiler --feature-gates=+service.profilesSupport --config cmd/otelcol-ebpf-profiler/local.example.yaml
```

## Linux Kernel Version Requirements and the Version Policy

The profiler requires Linux kernel 5.10 or greater for the current codebase. The README documents two historical boundary commits: commit 8047150e was the last to support kernel 5.4, and commit 7ddc23ea was the last to support kernel 4.19. The go.mod note confirms this is not a build concern but an agent deployment concern: the agent will not start on kernels below the minimum supported version by default.

The README documents the policy governing minimum kernel version increases: the project tracks the lowest kernel version shipped by actively maintained major Linux distributions, specifically Debian stable, Red Hat Enterprise Linux, Ubuntu LTS, Amazon Linux, and SUSE Linux. The minimum requirement increases when all of those distributions stop shipping a given kernel version. The README also notes that some distributions backport eBPF features from newer kernels, so a distribution's stated kernel version may underrepresent its actual eBPF capabilities. The no-kernel-version-check configuration option bypasses the version check on such kernels.

## Production Deployment: OTel Collector vs Standalone Binary

The README draws a firm boundary between the two binary options. The supported production path is the OTel Collector receiver, available as the otelcol-ebpf-profiler distribution in the opentelemetry-collector-releases repository. The README notes that the go.mod file in this repository is not used to build any official binary; official binaries are built from the collector releases repository.

The standalone ebpf-profiler binary and the locally built otelcol-ebpf-profiler are described as aids for development, testing, and debugging. The README explicitly states they are not supported in any way, can be dropped in the future, and should not be deployed in production. This distinction matters for operators: the production artifact and the development artifact are different binaries built from different repositories.

The agent implements the Alpha OTel Profiles signal, which the README notes is still in development. Mature production-ready backends have not yet emerged as of the README's writing. The README lists two open source options: devfiler (an Elastic desktop application for development and experimentation, explicitly not a production backend) and Pyroscope (a continuous profiling database from Grafana that natively supports ingesting OTel profiling data).

## Comparing with Parca and the Project Status

Parca is an open-source continuous profiling system that also uses eBPF to collect stack traces from Linux systems without application instrumentation. It uses pprof format for profile data and has its own storage server and web UI. The fundamental difference is the data format and ecosystem alignment: Parca predates and does not implement the OTel Profiles signal, while the OpenTelemetry eBPF Profiler is specifically designed to feed into the OpenTelemetry ecosystem and the broader OTel Collector pipeline. For teams whose observability stack is already centered on OpenTelemetry, the eBPF profiler aligns with existing infrastructure. For teams that need a self-contained profiling system with a UI and storage included out of the box, Parca addresses a more complete workflow without requiring a separate OTel Collector instance.

The last push to the OpenTelemetry eBPF Profiler main branch was recorded on 2026-09-25. The repository is not archived. The Apache-2.0 license permits use in both open-source and proprietary commercial products without source disclosure requirements.

## Conclusion

The OpenTelemetry eBPF Profiler suits infrastructure and reliability engineers who need whole-system, cross-language profiling in Linux datacenter environments without modifying applications or requiring debug symbols on the host. Teams running kernels older than 5.10 should check the VERSIONING.md file for the exact minimum supported version before deploying. For production use, the README states that the supported path is the OTel Collector receiver distribution, not the standalone ebpf-profiler binary.

## FAQ

### Does the OpenTelemetry eBPF Profiler work on macOS or Windows?

No. The profiler is Linux-only. The README states that macOS and Windows users need to set up a Linux VM to build and run the agent. The profiler depends on eBPF, which is a Linux kernel technology.

### What is the minimum Linux kernel version required?

The current codebase requires Linux kernel 5.10 or greater. The README documents the policy: the minimum is tied to the lowest kernel version shipped by actively maintained major distributions including Debian stable, RHEL, Ubuntu LTS, Amazon Linux, and SUSE Linux. The no-kernel-version-check option can bypass the version check on distributions that backport eBPF features.

### Is the standalone ebpf-profiler binary suitable for production use?

No. The README explicitly states that the standalone ebpf-profiler binary is intended only for development, testing, and debugging. It is not supported, may be removed in the future, and should not be deployed in production. The supported production path is the OTel Collector receiver distribution.

## Sources

- [Issues](https://github.com/open-telemetry/opentelemetry-ebpf-profiler/issues)
- [License: Apache-2.0](https://github.com/open-telemetry/opentelemetry-ebpf-profiler/blob/main/LICENSE)
- [open-telemetry/opentelemetry-ebpf-profiler on GitHub](https://github.com/open-telemetry/opentelemetry-ebpf-profiler)
- [README](https://github.com/open-telemetry/opentelemetry-ebpf-profiler/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-telemetry-opentelemetry-ebpf-profiler