How eBPF Enriches OTel–A missing database table

In the previous blog post, we learned about what eBPF is and showcased the first example in a series of 4 examples for why eBPF should be used along OTel to provide observability with zero downtime, full application coverage, and no-code instrumentation.

This series of posts will walk through four failures:

1. A slow SQL query caused by one user with a million rows.
2. A missing database table.
3. A Postgres index rebuild strangling everything around it.
4. A payment service quietly regressing after an unsuccessful migration.

And this post will focus on the second example. By the end of this series I hope you walk a way with a more centered and practical understanding of why eBPF it feels magical. If you prefer to learn through watching videos you can watch the corresponding webinar here.

Example two: a missing table

The second failure is the fastest one to demonstrate, and it's the one that shows off eBPF's real superpower — seeing things that were never instrumented at all. The next three examples all run on ShopIQ, our demo e-commerce app, so it's worth a look at the shape of it first.

This is a normal distributed system, and normal means uneven. The API gateway is JavaScript. The acquired-service is 77 lines of plain Go with zero OpenTelemetry imports. It’s just a small microservice someone wrote and shipped. The payments service is instrumented with OTel. Deploy the sensor across all of it and the service map draws itself anyway, instrumented and uninstrumented alike, because the sensor doesn't care what language you wrote in or whether you remembered to add a tracer.

Now break it. We applied a Kubernetes Job that loops forever, inserting into a table that doesn't exist. It runs as raw psql. There is no application here, nor framework, nor tracer that could produce an OTel span. Flip on "Show Unresolved Workloads" in the map and the red Postgres edge appears. Click into it and every failing statement is right there.

public.user_profiles_v2, a relation that doesn't exist. Status code, latency, pod, and cluster all attached.

Schemas change constantly. Migrations get applied out of order, ETL jobs run against stale assumptions, background jobs outlive the tables they were written against. The specific failure is overly simplistic but the point holds either way: a script nobody instrumented broke something, and the full statement, error code, and container image showed up without anyone doing anything. That's the value of groundcover proposition in a snapshot.

Final Thoughts

OpenTelemetry is good at adding business context, application semantics, and the spans you wrote on purpose because you understood the domain. That's real, and eBPF doesn't replace it. What eBPF does is cover all of your services, all the time, with no deployment required, so that when something breaks the observability is already there. Then you use that existing telemetry to decide where to add instrumentation next. Universal coverage on the bottom, deliberate context on top.

One last idea worth taking with you. For a long time, the artifact of a failed investigation was a dashboard. You’d dig through the data, you find the issue, and build a panel so you'd catch it faster next time. That's still useful. But in the first example, the artifact wasn't a dashboard. It was a skill: a saved investigation the agent can rerun, referencing the same queries and the same dashboards, on demand. It found the hot shard on its own, quantified it better than the manual version, and told us which fixes to skip.

That's what we're building toward. eBPF supplying the ground truth, OTel supplying the meaning, and an agent that runs inside your own cloud with access to both.

Conclusion and Part 2

I hope this post is helping you to understand the power of eBPF and how it can compliment and enrich your OTel when it comes to grabbing full fidelity telemetry with zero outages. I encourage you to check out the rest of the posts in this series to understand other examples of where eBPF and OTel help make each other stronger. Check out the other examples:

1. A slow SQL query caused by one user with a million rows.
2. A missing database table.
3. A Postgres index rebuild strangling everything around it.
4. A payment service quietly regressing after an unsuccessful migration.

If you have any questions about eBPF or groundcover, I encourage you to join our community slack and ask any questions you may have. I also encourage you to give groundcover a try with our playground. Finally, I want to share a link to the corresponding webinar here in case you want to see the recorded demo of these examples all together.