eBPF Is Not Your Instrumentation Layer. It's Your Infrastructure Layer.

On April 16, the GitHub Engineering Blog published the internal story of a problem that engineers at the company had quietly worried about for years: to deploy GitHub, you need GitHub. If the platform goes down, the deployment tooling that is supposed to fix it makes outbound requests back to the same services it cannot reach, completing a circle that prevents remediation at exactly the moment remediation is most needed.

The solution GitHub shipped does not touch a single line of their deployment scripts. Instead, they attach eBPF programs to the cgroups containing the deployment processes, intercept outbound network calls at the kernel level, and block the requests that would complete the circle. DNS queries from deployment scripts are routed through a filtering proxy. The deployment script has no idea this is happening. The kernel knows.

That is the capability eBPF has reached in production in 2026. It no longer requires cooperation from application code to observe, enforce, or modify what application code does. For platform engineering teams, that is a genuine shift in what the platform can offer unilaterally. For the teams they support, it introduces a question that most eBPF adoption plans leave unasked: if the platform now observes everything at the kernel level, what does application instrumentation still have to do?

What moved into the platform

The numbers behind eBPF’s production maturation are no longer early-adopter data. In January 2026, the CNCF released its Annual Cloud Native Survey, covering a period when 82% of container users were running Kubernetes in production. That same survey found that Cilium, the eBPF-based networking and observability project, had overtaken Flannel and Calico to become the most widely used CNI plugin in production Kubernetes deployments, with 47% year-over-year adoption growth. GKE, EKS, and AKS all enable eBPF-mode Cilium as a default networking option.

The eBPF Foundation published an “In Production” report in February 2026, consolidating enterprise outcome data across networking, security, and observability. The numbers it documents are not preliminary benchmarks. ByteDance, whose infrastructure supports approximately one million servers, achieved a 10% improvement in network throughput by replacing virtual Ethernet pairs with netkit, an eBPF-based container networking solution, eliminating a soft-interrupt bottleneck that iptables-based approaches could not reach. Netflix uses eBPF for network defense and large-scale telemetry across an infrastructure supporting more than 325 million subscribers.

These are not engineering experiments. They are the production record of a technology that has crossed from kernel novelty to platform infrastructure primitive. The question for most engineering organizations in 2026 is not whether to adopt eBPF tools but what adopting them actually changes about the instrumentation work their teams still need to do.

The layer eBPF genuinely owns

eBPF programs run inside the Linux kernel’s verified execution sandbox. They can attach to virtually any kernel event: network packets entering or leaving an interface, system calls made by any process, file system operations, scheduler events, security policy decisions. They can observe, modify, or block behaviors that application code has no visibility into and no ability to affect.

This produces a specific set of signals that eBPF owns in a way nothing else does.

Network behavior is the most common entry point. Cilium’s Hubble layer, built on eBPF, captures HTTP request and response metadata, DNS queries and responses, TCP connection establishment and duration, and network policy decisions across every service in a cluster, without any SDK installed, without any application restart, and without any code change reviewed by an application team. The GitHub deployment safety implementation shows what this means in practice: observing and filtering deployment script network calls at the kernel level, enforcing a policy that prevents circular dependencies, all without touching the scripts themselves.

Syscall and process behavior are the security and reliability domain. Tetragon, a Cilium sub-project, uses eBPF hooks at the syscall boundary to observe and block behaviors that indicate attack or misconfiguration. A process attempting to write to a directory it should not access triggers the eBPF policy synchronously, inside the kernel, before the write completes. This is not a detection-after-the-fact capability. It is enforcement that cannot be bypassed by a container process, because it executes at a layer the container process cannot reach.

Performance observability at the kernel level rounds out the ownership claim. CPU scheduler events, memory allocations, I/O wait times, and interrupt latency are all visible to eBPF programs and invisible to user-space agents, whose own execution occupies the same CPU time they are trying to measure.

For all of these signals, eBPF is not one approach among several. It is structurally better positioned than anything that runs in user space, because it operates at a level below any abstraction the application can influence.

The layer eBPF cannot reach

A Hubble export for an HTTP call to /api/orders includes the method, the URL path, the response status code, and the duration in milliseconds. It does not include the customer’s account identifier, the account tier, the order total, which feature flag variant was active during the request, or whether the business outcome was a successful fulfillment or a retry triggered by a payment gateway error. Those signals exist only in the application’s memory, and eBPF has no mechanism to extract them.

This is not a limitation that future eBPF versions will close. It is structural. Business context is not a kernel artifact. The application constructs it from authenticated session state, database reads, and domain logic applied to business entities. No kernel event represents “this HTTP call was for a Premium-tier customer processing a refund.” That representation requires application code that understands what a customer tier and a refund are.

The practical consequence appears when an engineering team investigates a latency spike. The eBPF-derived data says: HTTP POST to /api/orders, 94th-percentile duration 1,240ms, status 200. This answers what happened. The question engineers actually need to answer is why it happened, for whom, under what conditions, and whether those conditions are recurring. Those answers require business context that only application instrumentation can provide: which customer segment was affected, what the order contents were, whether a specific feature flag rollout correlates with the degradation, and what the downstream service calls looked like at the application level. Without application-layer telemetry, the eBPF data is a symptom without a diagnosis.

Security investigations follow the same pattern. eBPF can show the syscall sequence that preceded a suspicious file access. It cannot show which business transaction triggered the sequence, which authenticated user the request was running on behalf of, or what the application was logically doing when the kernel event occurred. Connecting a kernel-level security event to its business context requires application-level tracing that eBPF cannot produce.

Three anti-patterns that follow

Three patterns appear when engineering organizations adopt eBPF without explicitly settling the ownership question.

Instrumentation neglect is the most common. A platform team deploys Cilium and Hubble, demonstrates that service-to-service HTTP metrics are now visible without any SDK, and concludes that observability is covered. Application teams draw the same conclusion. Over the following months, new services are shipped without OTel instrumentation. Span coverage falls. When the first significant incident occurs that requires understanding business-level behavior, the team has infrastructure signals and no business context. The eBPF data shows there was a problem. It provides no information about scope, affected customers, or root cause at the application level.

Shadow observability occurs when the platform team enriches and routes eBPF-derived telemetry without making clear to application teams what is being collected, how to query it, or how it relates to the OTel data they do control. Application teams develop their own mental models of what is observable, which often assume that only what they deliberately instrumented is visible. The platform is observing network behavior, syscall patterns, and process interactions that the application team may not know are captured. This produces an asymmetry: the platform team has observability data the application team does not know exists, while the application team has business context the platform team cannot access. Neither has complete picture.

eBPF governance gap is the failure mode that is easiest to miss until it matters. eBPF programs run inside the kernel. A buggy eBPF program can cause a kernel panic. A misconfigured security policy can block production traffic. These programs are loaded by platform teams, often as operational configuration changes rather than as production code changes. They rarely go through the same review and testing process as a service deployment. The result is that the most privileged code running in the environment, with access to every kernel event across the entire cluster, is managed with less rigor than a configuration map change in a service repository.

The decision framework

The ownership question resolves into four cases based on two properties of the signal: whether it requires business context to be useful, and whether it has an infrastructure dimension that eBPF can observe directly.

flowchart TD
    Start["New signal to capture or measure"] --> Q1{"Requires business entity context\nto be useful?\n\ne.g. customer ID, order ID,\nfeature flag state, domain outcome"}

    Q1 -- "Yes: context lives\nin the application" --> Q2{"Also has an infrastructure\ndimension?\n\nlatency, process behavior,\nnetwork traffic"}

    Q2 -- "Yes: dual-dimension" --> Dual["OTel SDK for business context\neBPF for infrastructure dimension\n\nLink via W3C Trace Context header\nso traces correlate across layers"]

    Q2 -- "No: context only" --> OTel["OTel SDK span attribute\nApplication team owns this\n\nPlatform eBPF cannot supply it.\nMissing this is instrumentation neglect."]

    Q1 -- "No: purely system-level" --> Q3{"Network traffic, syscall,\nprocess behavior, file I/O,\nor security enforcement?"}

    Q3 -- "Yes" --> EBPF["Platform eBPF layer\nCilium, Hubble, Tetragon, Beyla\n\nPlatform team owns, deploys, governs.\nNo application code change needed."]

    Q3 -- "No: edge case" --> Review["Assess whether observable at all.\nIf business context is needed,\nreturn to OTel SDK path."]

The correlation mechanism matters. For signals that span both layers, the W3C Trace Context propagation header is what links an eBPF-observed network call to the OTel-instrumented application logic that made it. Hubble’s flow log for a request and the OTel trace for the same request are two partial views of the same event. The trace ID in the W3C header is what allows them to be joined in a query. Without explicit trace context propagation in the application, infrastructure signals and business context remain two separate datasets that cannot be correlated.

This is the practical work that eBPF adoption does not eliminate. The platform owns the eBPF programs and the infrastructure signals they produce. The application teams own the business context. The connection between them requires deliberate instrumentation decisions from both sides.

Making the boundary explicit

The ownership question does not resolve itself. Left implicit, it produces the anti-patterns described above: neglected application instrumentation, shadow observability, and eBPF programs that bypass normal production code review.

The platform team’s side of the bargain is transparency. A platform that runs eBPF observability and security programs has an obligation to publish what those programs observe, what they enforce, and how application teams can query the data they produce. Application teams should not need to infer what the platform is capturing. They should have access to documentation that states: these eBPF probes are running, these are the signals they produce, this is how you query them in the observability backend, and this is what they cannot tell you about your service’s behavior.

The application team’s side is to recognize that eBPF adoption does not transfer the responsibility for business context to the platform. A service that relies entirely on Hubble for observability is a service whose incidents will be diagnosable at the infrastructure level and opaque at the business level. The question “was this latency spike affecting a specific customer segment, and did the feature flag rollout that shipped on Tuesday correlate with it?” cannot be answered from eBPF data alone. It requires OTel span attributes that the application team put there.

The eBPF governance gap closes the same way any production code governance gap closes: by applying the same review and deployment process to eBPF programs that applies to service deployments. A pull request that adds a Tetragon security policy or a Cilium network policy is a change to the behavior of the production environment. It should have a reviewer, a rollout plan that does not immediately apply to all nodes, a monitoring period, and a rollback procedure.

Across the platform engineering teams we work with, the ones generating the most value from eBPF adoption are the ones that treated the ownership question as a first-class deliverable alongside the technical rollout. The platform published what it observes. The application teams understood what they still owned. eBPF programs went through the same review gate as service code. The result was infrastructure-layer observability and security enforcement that complemented rather than displaced the application-layer telemetry those teams had built.

eBPF gives platform teams a capability they did not previously have: observing and enforcing at the kernel level without requiring application cooperation. That capability is valuable precisely because it does not depend on application teams. The failure mode arrives when the platform assumes that capability extends further than it does, into the business context that only application code can supply.

If your platform team is evaluating eBPF adoption, or you have deployed Cilium and are now working out what your application teams still need to instrument, we have helped engineering organizations establish that ownership boundary and are glad to compare notes.