eBPF for Trading Systems: Kernel-Level Observability Without the Performance Tax

If you run a trading system that cares about microseconds, you cannot afford the overhead of traditional observability. Sidecars consume CPU. Log shippers add latency. Metrics exporters create failure dependencies. And yet you still need to know when your exchange connections are dropping packets, when a syscall is running long, and when your TCP handshake to the venue is stalling.

eBPF — extended Berkeley Packet Filter — solves this. It runs sandboxed programs inside the Linux kernel without modifying kernel source, loading modules, or touching application code. The kernel verifier rejects unsafe programs at load time.

Goldman Sachs requires eBPF experience for production engineering roles. Their low-level systems engineering listing specifically asks for “experience with eBPF and tracing for observability in production” and “knowledge of RDMA or kernel networking internals beyond the socket API.” This is not a conference talk about future potential. It is a job requirement at one of the world’s largest financial institutions.

What eBPF Actually Sees

At the network level, eBPF observes L3, L4, and L7 flows with per-connection latency, packet loss, throughput, and connection establishment timing — all per process or per container, with no application modifications.

For a trading system, this means you can monitor whether your FIX session to the exchange is seeing TCP retransmissions, whether market data latency is spiking on specific connections, or whether a particular syscall is taking longer than expected — all without adding a single sidecar process.

The Linux Foundation’s February 2026 “eBPF In Production” report confirms the momentum: eBPF is “the prime vessel to apply custom networking, security, performance, or observability features in production environments.”

The Tools

Open source. Cilium and Tetragon provide eBPF-powered networking, security, and observability for Kubernetes. Tetragon can run in monitoring-only mode — critical for trading environments where enforcement features could affect performance. bpftrace gives you ad-hoc one-liner probes for specific syscalls or kernel events.

Commercial. New Relic rolled out eBPF-based network metrics in March 2026, drilling into TCP handshake latency, packet loss rates, and connection throughput — no sidecars. Dash0’s July 2026 platform provides L3-L7 observability with the same zero-modification profile.

Research. An IEEE paper from ISPASS 2024 evaluated eBPF specifically for latency-sensitive applications, demonstrating kernel-level observability through system call monitoring with minimal overhead. A May 2026 arXiv preprint extends the work with 16 eBPF-based metrics across six kernel subsystems.

The One Rule

Never block in eBPF probe context. Network requests, disk writes, or lock acquisition inside a probe will degrade your application’s latency. Collect data and return immediately. That is the entire discipline.

Beyond that: prefer tracepoints over kprobes (stable API, lower overhead). Limit data to relevant events — specific syscalls, specific connections, specific process IDs. Use per-CPU data structures to avoid locking. Test on staging before production, because eBPF behavior can vary across kernel versions.

Know what eBPF cannot do: application-specific business logic — how your pricing engine processes a specific market data event — still needs application-level tracing. The two layers complement each other.

Where to Start

Deploy Tetragon in monitoring-only mode with TCP retransmit tracing. No application modifications needed. Run bpftrace one-liners to measure write() latency on your trading processes. Read the Rezvani paper from ISPASS 2024. And know that the tools are production-ready today — Goldman Sachs is not hiring for a future skill.

For help instrumenting trading infrastructure with kernel-level observability, see our Trading & Market Systems Engineering practice. Related reading: Low-Latency Messaging: Aeron vs Kafka vs Chronicle Queue.