Modern IT infrastructure is no longer built around a single application but around large number of distributed services. In Kubernetes and cloud environments, these services constantly scale, update, and interact with one another over the network. Under such conditions, the primary challenge is no longer stability itself but understanding how the system behaves in real time.

Traditional monitoring approaches typically require deploying agents, modifying application codes, and restarting services. This complicates operations for engineering teams and slows down release cycles. The situation becomes even more challenging for legacy systems or third-party applications where source code access may be unavailable. As a result, parts of the infrastructure remain outside visibility – and this is often where hidden issues emerge.

What OBI Is and How It Works

OBI (OpenTelemetry eBPF Instrumentation) is a component of the OpenTelemetry ecosystem within Splunk Observability Cloud that enables telemetry collection without modifying application code or restarting services. It operates as an eBPF-based solution at the operating system level. In other words, analysis occurs not inside the application itself, but within the Linux kernel, where network calls and process interactions are handled.

Simply put, OBI makes it possible to observe how services communicate with each other and how the overall system behaves – without embedding monitoring logic into every individual application. All telemetry is collected centrally at the infrastructure layer, which is particularly important for enterprise-scale environments.

Technological Foundation and Universality

The core logic behind OBI is that it operates outside the application boundary. As a result, it is independent of programming languages and service architectures, allowing it to collect telemetry equally effectively from Java, Python, .NET, Node.js, Go, Rust, and C++ environments.

In hybrid infrastructures, this becomes critically important because real-world systems almost always consist of multiple technology stacks. With traditional approaches, this typically requires separate agents or integrations for each platform. OBI, by contrast, introduces a unified observability layer capable of covering the entire infrastructure regardless of underlying technologies.

This level of unification is made possible by eBPF (extended Berkeley Packet Filter) – a Linux kernel mechanism that enables secure execution of lightweight programs directly within the operating system kernel. It analyzes network requests, system calls, and process behavior in real time without modifying application code or requiring service restarts.

Role in Modern Monitoring and Use Cases

OBI does not replace traditional Application Performance Monitoring (APM) instrumentation or OpenTelemetry agents – it complements them. In environments where some services are already instrumented, OBI does not duplicate telemetry but instead fills the visibility gaps where conventional approaches are technically limited or impractical.

Within Splunk Observability Cloud, this makes it possible to combine traditional application monitoring with automated infrastructure-level telemetry collection, creating a unified operational view of the system.

OBI delivers the greatest value in complex and dynamic environments, including:

• large Kubernetes clusters;
• infrastructures with multiple technology stacks;
• legacy systems without source code access;
• scenarios where rapid visibility is required before deeper analysis or full-scale APM deployment.

Since OBI is based on eBPF and operates at the Linux operating system level, it requires system privileges to collect telemetry. However, it does not require unrestricted administrative access across the entire infrastructure, making it suitable even for controlled and regulated environments where strict access limitations and compliance requirements apply.

All in all, OBI within Splunk Observability Cloud changes the very approach to monitoring. Instead of relying on complex instrumentation for every individual service, telemetry collection is shifted to the infrastructure layer, where visibility is generated automatically. As a result, organizations gain complete visibility into system behavior without code modifications or service restarts. This reduces the number of “blind spots,” simplifies incident diagnostics, and provides a more comprehensive understanding of distributed system behavior.