OpenTelemetry is the Standard that Solves Most things

Introduction

Observability serves a critical role for engineering teams because it accounts for the truth. It tells them what actually happened when something went wrong in the applications and infrastructure that their stakeholders depend and build upon. The language in which it communicates that truth is largely determined by the standards in OpenTelemetry (OTel). While the OTel standard that to may solve the interoperability problem for observability, it doesn't fix the widespread issue of data completeness. 

Why Standards Matter: Ending the Telemetry Wild West

Before OTel, every vendor shipped their own telemetry format. Teams built around those formats, and switching between vendors meant rewriting instrumentation. OTel is the de facto standard now because the community valued an alternative that empowered them over platforms. Vendors can't lock you in with proprietary SDKs, and you can swap components without rebuilding.

AI applications, however, test that guarantee. A typical stack combines multiple model providers (Anthropic, OpenAI) alongside framework-specific SDKs (LangChain, CrewAI), and the instrumentation each provider emits is not interchangeable.  If the instrumentation for Anthropic vs OpenAI isn’t interchangeable (hint: it is not), then the standard alone is insufficient for observing your platform when both providers get involved. Even though OpenTelemetry is essential, it doesn’t fix the data blindness problem that is only exacerbated by the complicated AI workloads becoming the norm. 

The Data Problem: Incomplete Telemetry and the Cost of Sampling

Teams add OTel by writing code that pulls in SDKs and libraries that point at an observability platform. Sometimes engineers write that instrumentation; sometimes agents do.

What’s great is that OpenTelemetry logs are portable, so teams can exchange observability vendors when they lose confidence in one. If the community doesn’t like what their current offering does with their data, they can redirect it to a vendor they trust more. 57% of practitioners cite vendor-neutrality as a requirement when selecting observability tools. Dramatically oversimplified, but the essence is the engineering team just changes the endpoint where they send that OTel data. 

Collecting those logs requires someone to have decided, at write time, that a given function was worth logging. Research from Atomik Research found that 43% of engineering leaders name incomplete telemetry and sampling limits as their top barrier to advanced observability. A function nobody instrumented doesn't appear in your traces. By the time that gap shows up in production, the developer or agent who wrote the code has moved on.

Teams default to sampling to manage costs: individual developers can generate 2-3 GB of metrics and logs per month, and mid-market teams hit terabytes weekly. Sampling creates blind spots by design.

The Modern Stack: eBPF as the Foundation, OTel as the Structure

OpenTelemetry serves a critical role as the agreed-upon structure for the modern observability stack. It imposes something repeatable that every tool in the stack can interpret. OTel's value also scales with coverage. Deep waterfall traces are useful as context data when someone instrumented the right functions before deploying. But eBPF as a data source differs from traditional observability data inputs because it filters through all network traffic. The sensor extends the capabilities of the kernel each application runs on, and when data comes into the observability platform, the eBPF collector enriches those records with network-level context.

The eBPF sensor solves a deployment sequence point of friction: OTel requires instrumentation before deployment to generate any value. eBPF starts showing network traffic within minutes of deployment and surfaces the gaps your team then knows to instrument. It acts as a guide-post for where further traces, or waterfall level depth, is critically valuable.

eBPF and native OTel together give teams full-stack visibility: eBPF catches what wasn't instrumented, OTel provides the waterfall depth where it matters. Teams can observe everything without code changes thanks to eBPF, and then decide what information they need further instrumentation of in order to enjoy true comprehensive observability. Dropping vendor SDKs and conforming to the standard prevents accidental lock-in.

Launch Story: Connectors Share a Complete Context

groundcover is launching connectors next week to make it easy to realize the true value of high-fidelity OTel and eBPF data. Customers can share their data (all the metrics, logs, and traces used as context to groundcover Agent Mode) throughout the rest of their engineering team's agentic dev stack. Connectors unlock that OTel data by letting coding and productivity tools call directly into groundcover via Model Context Protocol (MCP, another standard). Those tools include, but are not limited to, Slack, Linear, Jira, Claude Code, Codex, and Cursor.

With complete telemetry and connector access, Agent Mode can investigate an incident, identify the root cause, and push a fix through Cursor — without anyone manually pulling context from multiple tools. This explicitly shifts telemetry data’s role from being passive to proactive. 

Conclusion: Future-Proofing Your Observability

Our advice is to adopt OTel as quickly as possible. It’s a critical standard, and prevents your platform teams from the vendor lock-in that will cripple your growth as your applications and workloads scale. But be critical about where you depend on it as your only source of observability data.

OTel instrumentation is problematic for agentic workflows. The foundational model providers all emit OTel logs, but they each use their own structure. Because it’s inconsistent across frameworks, providers, tools, and custom code, eBPF has to fill the gap. The sensor captures network traffic at the kernel level, including tool calls and agentic flows that no one thought to instrument. That network map shows teams where additional instrumentation is worth the effort.

groundcover customers benefit from this rich data set collected via eBPF because they don’t have to instrument all of their applications, but also because it’s a new source. It’s additive to the observability data they can use in their development lifecycle, and that's an important value driver when combined with BYOC (Bring Your Own Cloud) - only that unique combination affords engineering teams the opportunity to retain the scale appropriate for them. Other vendors in observability force their customers to pay them for the privilege of storing their own data. 

Read more on the connector story here. It takes 45 minutes to see what eBPF and OTel can do with your application data. Schedule time with a solutions consultant this week.

References

1. https://opentelemetry.io/blog/2025/otel-rocks/