How eBPF Observability Monitors Docker Containers Without a Rebuild

How many containers are running in your production environment right now that nobody can see inside? A vendored service, a compiled binary, an application whose build pipeline left with the developer who wrote it: each one runs, serves traffic, and reports nothing.

Instrumenting those workloads means a code change, a rebuild, and a redeploy, and on these containers none of the three are available. The gap stays open release after release, showing up as longer incidents, thin audit evidence, and a service inventory nobody fully trusts.

eBPF, short for extended Berkeley Packet Filter, runs small safety-checked programs inside the Linux kernel to report on the activity passing through it. Because it reads the kernel instead of the application, a container becomes observable without anyone touching its code. That framing is accurate and incomplete, since kernel-level observation carries a specific edge.

Where that edge falls sets the coverage you can reasonably buy, which makes it a budget question as much as an engineering one. This guide draws the line for Docker containers on a Linux host, measured against a per-container agent doing application performance monitoring from inside the workload. In this blog, you will see a visibility matrix, a decision matrix, an overhead breakdown, and a prerequisite checklist for a vendor conversation.

What is eBPF Observability and How does It Work on a Docker Host?

eBPF observability is the collection of telemetry by small programs running inside the Linux kernel, attached to events the kernel already handles. Nothing enters the application source and nothing installs inside the container, which puts it in the agentless monitoring category, applied to application behavior instead of infrastructure polling.

It works on containers because of how Docker builds them. A container is a host process isolated by namespaces and capped by cgroups, two kernel features that control what a process can see and how much it can consume. It still runs against the host's kernel, so every syscall, or request the process makes of the operating system, crosses the kernel an eBPF program attaches to.

The execution path runs in four stages, and each one explains a property that matters later:

1. Attachment: Programs hook kernel function entries, user-space function entries, static tracepoints, or the point where raw packets first arrive

2. Verification: The kernel verifier rejects any program with unbounded loops or invalid memory access before it loads, which is why a faulty program cannot take a production host down

3. In-kernel aggregation: Verified programs run at native speed and write counters into kernel key-value stores called maps, so millions of raw events never cross into user space

4. Export: A collector in user space reads those maps on an interval and forwards the aggregated data into dashboards and trace views

Why the Host Kernel is the Attachment Point

Containers share the host kernel, and that structural property of containers and VMs lets one instrumentation point cover everything above it. A single attachment covers a host running four containers or four hundred, including containers started long after the collector was configured.

Each stage in that path limits what reaches the next, which is where the boundaries later in this guide come from.

What Can eBPF Observability See Inside a Docker Container?

eBPF observability sees whatever a containerized process asks the kernel to do, which reaches further into application behavior than most engineers expect and stops well short of application internals. What it captures separates into seven layers, each with its own cut-off point. The table below is the short version, and the sections after it explain the three layers that carry the most weight in practice.

1. Process and Network Activity

Process and network activity is the layer eBPF reports most completely. Every container process registers its start, its executable, the files it opens, and the sockets it holds, and connection behavior arrives with it: who talked to whom, on which port, for how many bytes, and how often the connection failed.

That base layer answers questions that are awkward to answer any other way:

• Which containers on this host talk to an external endpoint nobody documented

• Which service generated retransmits during the window an incident opened

• Which container process restarted three times in an hour without an alert firing

Each of those has an audit or compliance reading as well as an engineering one, which is why this layer often justifies the deployment on its own.

2. Container and Service Identity

Container and service identity mapping converts kernel events into telemetry a human can read. The kernel reports a PID and a cgroup, and the instrumentation resolves those into a container ID, an image name, its labels, and finally a service name. Without that step, container monitoring at the kernel level produces an unreadable stream of process identifiers.

Naming carries a practical consequence. A service discovered from the outside is named from what the host can observe, so image names, labels, and ports decide how that service reads in a dashboard and in any dependency map built on top of it.

3. Request Paths Without Image Modification

eBPF container instrumentation reconstructs request paths from observed traffic, producing request count, latency, error rate, and span data with the image untouched. A request entering one container and calling two others becomes a connected path, and that path populates the same distributed tracing views an instrumented service uses.

Span boundaries follow network operations, since the reconstruction is inferred from observed calls. Work handed to a background worker inside the same process never crosses a socket and produces no span. That single rule predicts most of the blind spots in the next section.

What Can eBPF Observability Not See Inside a Container?

eBPF observability cannot see anything the application keeps to itself. Kernel-level observation reads the edges of a process while business meaning lives in the middle of it, which produces a defined list of blind spots:

• Business context: Order IDs, tenant identifiers, feature flags, and customer tiers exist as application variables the kernel never handles

• Function-level detail: Which internal method consumed the time stays invisible, since only calls leaving the process are observed

• Custom spans and attributes: Anything a developer would deliberately annotate needs code that emits it

• Exception objects: A failure appears as an error response or a broken connection, with no stack trace attached

• In-process asynchronous work: Background jobs and worker threads that never open a socket generate no observable event

• Host resource metrics: Container CPU, memory, and disk consumption come from infrastructure collection

• Browser-side experience: What a visitor saw before the request arrived belongs to real user monitoring

The commercial reading of that list is straightforward. Any eBPF observability tools you evaluate will carry the same boundary, so a vendor claiming complete application visibility from the host alone is describing something the technology does not do. One item on that list carries more operational weight than the rest, and it shows up at the database.

Why do Query-Based Database Views Not Apply to eBPF-Instrumented Services?

Query-based database views depend on instrumentation inside the database driver, and kernel-level observation reaches the connection instead of the driver. eBPF records that a container opened a socket to a database endpoint, sent bytes, and waited a measurable time for a response. Which statement ran comes from the layer above.

Go makes this concrete. Getting query-level detail from a Go service means editing the code to use the otelsql driver wrapper with QueryContext or ExecContext, and eBPF on the host does not do that for you.

Plan around the operational effect. A service discovered through eBPF shows a slow dependency call, and naming the query behind it means either adding driver-level instrumentation to that service or reading the database's own monitoring for the same window. With the coverage questions settled, the next thing production owners ask is what this costs the host.

How Much Overhead does eBPF Monitoring Add in Production?

eBPF monitoring is designed for low overhead, and the verifier is the reason it can run on production hosts at all. A program that cannot loop indefinitely and cannot reach invalid memory has a bounded worst case, which is a stronger safety property than most agents offer.

Overhead still exists, and it arrives from three separate places:

1. Kernel program execution: Time spent inside the hooked path, which scales with event frequency such as connection churn or syscall volume

2. Map memory: Kernel memory held for the counters and state the programs maintain

3. User-space collection: CPU and memory consumed by the collector reading maps and shipping data off the host

Published overhead figures vary widely because they depend on which hooks are enabled and how busy the host is. Treat any single percentage as a starting point and measure on a representative host during a peak window before rolling out broadly.

How is eBPF Monitoring Different From a Per-Container APM Agent?

eBPF monitoring is deployed once on the host and observes every container running on it, while agent-based monitoring goes into each workload and reads it from inside. The same contrast applies to code-level OpenTelemetry instrumentation, where the library ships inside the application and reports what the application chooses to emit.

Neither column wins outright. The question is which workloads need covering, how much of the answer has to come from inside the code, and what the coverage is worth once you have it.

What is the Business Case for Host-Level eBPF?

The business case for host-level eBPF rests on coverage speed and the cost of the services currently missing from your monitoring picture. Four effects carry most of the value.

1. Risk exposure narrows: A service absent from monitoring is absent from incident review, dependency records, and audit evidence, and that absence surfaces at the worst possible moment

2. Incident duration falls on legacy paths: Investigations that previously stopped at an unmonitored container now continue through it, which shortens the segment of unplanned downtime that is spent locating the fault

3. Engineering effort moves elsewhere: No developer backlog item per service, no release scheduled around instrumentation, and no negotiation with the group that owns the code

4. Vendor evaluation gets sharper: Knowing the boundary in advance means you buy against the coverage you will actually receive, and you can test the claim during a trial

There is a governance benefit that rarely appears in vendor material. Because discovery is automatic, the service inventory reflects what is running instead of what somebody remembered to register, which makes it a usable input to microservices monitoring reviews and to change management.

What do You Need Before eBPF Monitoring Starts Working?

eBPF monitoring has a short prerequisite list, and every item on it belongs to the host. Confirm each one before scheduling a rollout, because a gap here surfaces as missing services with no clear error to trace.

1. Kernel version: eBPF Linux support depends on kernel version, and the tracing and networking hooks used for application visibility landed across several releases, so confirm the minimum your tooling states

2. Host access: The collector runs on the container host with root-level privileges, a wider permission than access to the Docker socket alone, which usually needs a security review

3. Protocol coverage: Request-level signals depend on the protocol being parseable, so check which protocols your tooling reads and how it treats encrypted service-to-service traffic

4. Naming conventions: Image names, labels, and listening ports become the service identity, so inconsistent naming produces a service list nobody can navigate

5. Collector capacity: The user-space collector consumes CPU and memory on the host, and busy hosts with high connection churn need that budgeted

Once those are settled, the remaining decision is which workloads go through this path and which keep instrumentation inside the code.

When Should You Choose Host-Level eBPF Over In-Application Instrumentation?

Choose host-level eBPF when the constraint is: access to the code and choose in-application instrumentation when the constraint is: depth of detail. Most environments run both, and the matrix below maps the common situations.

Both columns above describe application monitoring. The same kernel technology gets used for adjacent work, and separating those uses keeps a coverage claim accurate.

Where does eBPF Observability Fit Alongside Other Monitoring?

eBPF observability occupies the application-behavior layer while reading it from the kernel, which places it beside several adjacent practices built on the same technology. Keeping those scopes separate prevents a coverage claim the deployment cannot support, and it keeps budget lines accurate during procurement.

• Security observability with eBPF: The same hooks feed runtime threat detection for unexpected syscalls, privilege escalation, and unauthorized file access, configured separately from application telemetry

• Continuous profiling: CPU sampling and stack collection through eBPF answer a different question from request-level visibility, and open source projects in this space are often deployed independently

• Infrastructure monitoring: Host and container resource figures come from infrastructure collection alongside Docker application monitoring and are read against the application signals

• Kubernetes eBPF observability: Container orchestration adds pod scheduling, cluster networking, and workload identity, none of which the Docker host scope described here covers

Bring Uninstrumented Containers Into Monitoring with Motadata ObserveOps

Host-level eBPF will never return the function-level detail a language agent captures, and that limit belongs to the approach itself. What it does return is coverage on workloads that would otherwise stay dark, which is usually the more urgent problem.

Motadata ObserveOps eBPF instrumentation discovers and monitors services through an eBPF/OBI path with no code change and no agent install, capturing request count, latency, error rate, and trace and span data. Those services populate the existing service list, service map, traces, errors, and dashboards, each labeled eBPF/OBI so the instrumentation source is visible at a glance.

That path runs alongside the single unified MotaAgent. Services under active development keep code-level instrumentation, containers nobody can rebuild come in through the kernel, and both report into one set of views. Go database tracing still requires QueryContext or ExecContext with the otelsql wrapper, which ObserveOps states plainly in its documentation.

FAQs