Motadata ObserveOps eBPF instrumentation discovers and monitors application services at the kernel level with no code changes and no agent install, surfacing request count, latency, error rate, and traces in the existing APM views.
eBPF instrumentation is a way for Motadata ObserveOps to discover and monitor application services without changing a single line of source code and without installing a language agent. Built on eBPF/OBI-based instrumentation, it observes how services communicate at the kernel level and turns that activity into the same APM signals engineering teams already use: request count, latency, error rate, and trace and span data.
This matters most for services that are hard to instrument (old runtimes, third-party binaries, or code teams cannot easily modify) and for any service teams simply want visible from day one. eBPF/OBI-based instrumentation gives automatic service discovery and monitoring with no build step and no redeploy: as soon as a service is running, its traffic is captured and surfaced.
Everything eBPF/OBI collects lands in the existing APM views. The service list, service map, traces, and dashboards all populate the same way, with the instrumentation source labeled eBPF/OBI so engineers always know how a given service is being observed.
eBPF instrumentation is an APM capability focused on application code behavior and service-to-service communication. Node CPU, memory, and pod scheduling health remain with the Hybrid Infrastructure module, and browser-side experience remains with Real User Monitoring; ObserveOps cross-links to both so an investigation that starts with an eBPF-discovered service can still reach the infrastructure and frontend context around it.
Services are instrumented without code changes and without installing a language agent, so monitoring begins with no build, redeploy, or developer effort.
Running services are discovered automatically and added to APM, so newly deployed services appear without manual onboarding.
eBPF/OBI observes how services call each other and reconstructs those interactions as trace and span data for request visibility across the full call path.
Request count, latency, and error rate are captured for each observed service, giving throughput, P99 latency, and error-rate views without additional setup.
Discovered services populate the existing service list, service map, traces, errors, and dashboards, each labeled eBPF/OBI so the instrumentation source is always clear.
Heatmaps give a severity-based visual assessment over counters such as response time and error rate, built on the same counters eBPF/OBI already collects, so a discovered service's health reads at a glance without additional telemetry setup.
The Compare view places two services side by side with independent time ranges, so a change in an eBPF-discovered service's behavior after a deploy reads at a glance against its own history.
Saved Views in APM Explorer preserve search queries, filters, view types, and layout, so a recurring look at an eBPF-discovered service's traffic is one click away.
Custom Reports support Chart, Grid, Top-N, Counter, and Aggregation formats over the request count, latency, and error-rate signals eBPF/OBI collects, so a discovered service's behavior can be reported the same way as any agent-instrumented one.
Using eBPF/OBI-based instrumentation, ObserveOps observes service traffic at the kernel level with no code changes and no agent install. It captures service-to-service communication, request count, latency, error rate, and trace and span data for each discovered service. This is a separate instrumentation path from the single unified MotaAgent, and it does not change how database tracing works: Go database tracing still requires QueryContext or ExecContext with the otelsql wrapper and is not made automatic by eBPF.
Captured traffic is turned into APM signals: throughput, P99 latency, and error rate per service, with trace and span data reconstructing how requests move between services. Discovered services are correlated into the service topology so their dependencies are analyzed the same way agent-instrumented services are, and severity-based heatmaps surface which services are drifting before a full incident forms.
The results appear in the existing APM views: the service list, service map, traces, errors, and dashboards, each labeled eBPF/OBI so engineers can tell at a glance how a service is being observed. Frequently used trace fields can be pinned so they stay visible while inspecting a trace, and no separate console or parallel view is introduced.
eBPF/OBI-based discovery is not a replacement for language-agent instrumentation; it is a complementary path for the services that are hardest to reach. A team can run the single unified MotaAgent across services where code-level instrumentation is practical and rely on eBPF/OBI for the rest, without splitting the investigation across two separate tools. Both paths report into the same service list, service map, traces, and dashboards.
That combination closes coverage gaps quickly: a legacy binary, a vendored service, or a workload nobody wants to touch can be visible in APM the same day it starts running, while services under active development keep the deeper, code-level detail that agent instrumentation provides.
Teams gain APM visibility for services they could not, or did not want to, instrument by hand, closing blind spots quickly.
Because there is no code change or agent install, a service is observable as soon as it runs rather than after the next release cycle.
eBPF/OBI services sit alongside agent-instrumented services in the same views, so investigation does not fork by instrumentation method.
The eBPF/OBI label tells engineers exactly how each service is observed, which keeps troubleshooting and coverage decisions honest.
Latency, error rate, and throughput come straight from observed traffic, so P99 latency and error-rate analysis reflect real request behavior.
Heatmaps, the Compare view, Saved Views, and Custom Reports all work over eBPF/OBI-collected counters, so a discovered service gets the same reporting depth as one instrumented by an agent.
eBPF/OBI-based instrumentation stays inside the application layer even though it observes activity at the kernel level: service-to-service communication, request count, latency, and error rate for the services it discovers. Node CPU, memory, and pod scheduling health belong to the Hybrid Infrastructure module, and what a real visitor experienced in the browser belongs to Real User Monitoring.
ObserveOps cross-links these views so an eBPF-discovered service can still be read against the infrastructure it runs on and the frontend sessions that reach it, without the eBPF instrumentation path overstating what it covers. Logs from a discovered service correlate with its traces through the Log Monitoring module, and its latency or error-rate signals can feed a tracked Service Level Objective.
eBPF instrumentation gives Motadata ObserveOps a codeless, agent-free way to bring services into APM automatically. It discovers services, captures their communication and core request signals, and presents them in the same views, heatmaps, Compare view, Saved Views, and Custom Reports that agent-instrumented services already use, so coverage grows without waiting on code changes. Paired with agent-based instrumentation, it makes broad, consistent application visibility practical across the full estate.
Discover how Motadata ObserveOps can help you monitor your infrastructure in real-time and respond to issues instantly.