Instrumentation Strategies: OBI and zero-code instrumentation

Zero-code instrumentation enables you to instrument applications and export telemetry data without modifying application source code. There are currently two primary approaches to zero-code instrumentation:

  • Traditional language-specific instrumentation agents, which integrate with the application runtime
  • Out-of-process eBPF-based Instrumentation (OBI), which operates at the kernel level

Traditional instrumentation agents configure the application to automatically generate and export telemetry data in a supported format (typically OTLP) to a compatible endpoint, such as an OTLP receiver or Splunk Observability Cloud.

In contrast, OBI operates out-of-process, using eBPF to capture telemetry at the kernel and network level, while still exporting data to OTLP-compatible endpoints.

Traditional zero-code instrumentation is available for languages such as Java, Node.js, .NET, Go, Python, and PHP, and provides deep visibility into applications using supported libraries and frameworks. OBI expands this coverage to a broader set of environments, including compiled languages such as C, C++, and Rust, as well as third-party and legacy systems.

These two approaches are not mutually exclusive. Instead, they provide complementary capabilities, combining rapid, low-overhead deployment with deep application-level insights.

The sections below compare these models across key dimensions such as instrumentation model, visibility, compatibility, operational characteristics, and available features.

OBI and traditional language-specific zero-code instrumentation comparison

Instrumentation Model
Aspect OBI Traditional zero-code instrumentation
Execution model Out-of-process In-process
Instrumentation layer Linux kernel / network layer Application runtime
Requires code changes No No or minimal
Requires application restart No Yes
Security profile Isolated Same permission scope as the application
Level of Visibility
Capability OBI Traditional zero-code instrumentation
Distributed tracing Protocol-level Full fidelity
RED metrics Yes Yes
Application logs collection No Yes
Log-trace correlation Yes Yes
Application internals (frameworks, functions) Limited (primarily Go) Yes
Custom spans / business attributes No Yes
Runtime metrics (JVM, memory, threads) Not available (yet) Yes
Coverage and Compatibility
Scenario OBI Traditional zero-code instrumentation
Multi-language environments Strong (protocol-based) Language-specific
Third-party applications Supported Limited
Legacy systems Supported Limited
Compiled languages (C/C++/Rust) Supported* (with limitations in async scenarios) Limited
Async / complex frameworks Partial limitations Strong
Operational Characteristics
Aspect OBI Traditional zero-code instrumentation
Deployment effort Low (drop-in) Medium (agent attachment)
Time to first visibility Minutes Longer (agent setup required)
Impact on application lifecycle None Requires restart or configuration changes
Performance overhead Minimal and isolated Varies by language and runtime
Splunk Distribution Features
Feature OBI Traditional zero-code instrumentation
Always-on Profiling Not yet (potentially via eBPF profiler in the future) CPU (most), Memory (some)
Call graphs No Available
File-based configuration In progress Supported (Java, Node.js, .NET, Python)
No-code instrumentation support N/A Yes