Traditional application observability begins inside the application.

Engineering teams install libraries, initialise SDKs, modify framework configuration, add trace spans, propagate context, redeploy services and maintain instrumentation as the application evolves.

That model can produce extremely rich telemetry. It can also become difficult to apply consistently across hundreds of services, legacy systems, different programming languages and rapidly changing Kubernetes workloads.

Zero-code observability offers another starting point.

Instead of requiring every service to be modified first, eBPF can observe selected system, process and network activity from the Linux kernel and runtime boundary. OpenTelemetry can then standardise, process and export that telemetry to observability platforms.

The resulting architecture can provide:

• Service discovery
• Request traces
• Latency and error metrics
• Network relationships
• Database activity
• Infrastructure context
• Trace-to-log correlation
• Vendor-neutral telemetry export

without initially changing the source code of every monitored application.

This is not the end of application instrumentation.

It is a new baseline: obtain broad operational visibility automatically, then add code-level instrumentation only where deeper business or application meaning is required.

---

Quick answer: What is zero-code observability?

Zero-code observability is the collection of application and infrastructure telemetry without manually changing the application’s source code.

It can be implemented through several mechanisms, including:

• Runtime agents
• Bytecode instrumentation
• Monkey patching
• Framework injection
• eBPF-based kernel and process observation

In an eBPF and OpenTelemetry architecture:

1. eBPF programs observe supported Linux process, network and protocol activity.
2. Instrumentation derives traces and operational metrics from those events.
3. OpenTelemetry attaches standard resource and semantic information.
4. The OpenTelemetry Collector receives, processes and exports the telemetry.
5. Observability backends present traces, metrics, logs, service maps and alerts.

The most important limitation is:

Zero-code instrumentation can show how applications behave, but it cannot automatically understand every business decision occurring inside them.

Manual instrumentation remains useful for custom spans, business events, domain attributes and application-specific context. [3][4]

Key takeaways

1. Zero-code does not mean zero deployment or zero configuration. Instrumentation software still has to be installed, authorised, configured, monitored and upgraded.
2. eBPF provides visibility from Linux kernel, process and network observation points without modifying the application source.
3. OpenTelemetry provides vendor-neutral APIs, conventions, protocols and collection pipelines for traces, metrics and logs.
4. OpenTelemetry eBPF Instrumentation, commonly called OBI, can automatically capture web-transaction spans and RED metrics for supported Linux applications and protocols. [4]
5. OBI does not replace application-level instrumentation when teams need custom business spans, user-specific attributes or domain events.
6. eBPF-generated telemetry is strongest for infrastructure, networking, request flows and supported protocol activity.
7. The OpenTelemetry Collector allows teams to filter, enrich, sample, transform and route telemetry independently of the destination backend.
8. eBPF instrumentation can require substantial Linux permissions. Security teams should review capabilities, host access and data exposure before production deployment.
9. Distributed trace propagation has protocol, runtime, encryption and kernel-version limitations that should be tested against the actual environment.
10. The most effective long-term model is usually hybrid: broad zero-code coverage plus selective manual instrumentation.

What is observability?

Observability is the ability to understand the internal condition of a system through the signals it produces.

Traditional monitoring often asks predetermined questions:

• Is the service running?
• Is CPU usage high?
• Did an alert threshold trigger?
• How many requests failed?

Observability should also help teams investigate questions they did not define in advance:

• Why is latency increasing only for one customer journey?
• Which downstream dependency is delaying requests?
• Which deployment introduced a new failure pattern?
• Why is one Kubernetes node affecting several unrelated services?
• Which database operation dominates the total request time?
• Why does the application appear healthy while users experience timeouts?

The principal observability signals are:

Traces

Traces represent the path of a request or operation through one or more services.

They can reveal:

• Service dependencies
• Span duration
• Network delay
• Database time
• Error location
• Unexpected calls
• Retry behaviour

Metrics

Metrics represent measurements over time.

Examples include:

• Request rate
• Error rate
• Duration
• CPU consumption
• Memory usage
• Connection count
• Queue depth
• Saturation
• Dropped events

Logs

Logs represent timestamped records of events.

They may contain:

• Error details
• State changes
• Decisions
• Warnings
• Identifiers
• Debugging context

OpenTelemetry is designed to generate, collect, process and export telemetry signals through a vendor-neutral framework. [1]

What does zero-code really mean?

The term “zero-code” can be misunderstood.

It does not mean:

• No software is installed
• No agents or DaemonSets are required
• No privileges are needed
• No configuration is required
• No performance testing is necessary
• Every application is automatically understood
• Every trace is automatically complete
• Manual instrumentation becomes obsolete

It means that the application’s source code does not have to be manually edited to obtain an initial level of telemetry.

OpenTelemetry’s zero-code approaches use different techniques depending on the language and environment.

For example:

• Java agents can instrument bytecode.
• Python instrumentation can patch supported libraries.
• Node.js instrumentation can hook runtime modules.
• Kubernetes Operators can inject supported auto-instrumentation.
• eBPF can observe activity from Linux kernel and runtime boundaries.

The operational difference is important.

A platform team may be able to deploy zero-code coverage centrally across many workloads rather than asking every application team to modify and redeploy its code independently. [3][9]

What is eBPF?

eBPF is a technology originating in the Linux kernel that allows verified programs to run at selected kernel and system hooks.

It can be used for:

• Networking
• Security
• Tracing
• Performance analysis
• Observability
• Traffic control
• Runtime enforcement

eBPF programs can attach to observation points such as:

• System calls
• Kernel probes
• Tracepoints
• User-space probes
• Socket activity
• Network traffic-control hooks
• Process events

The kernel verifies eBPF programs before allowing them to run. The technology enables kernel-level extensibility without modifying the kernel source code or loading a conventional kernel module. [2]

Why is eBPF useful for observability?

Applications eventually interact with the operating system.

They:

• Open network connections
• Read and write sockets
• Access files
• Create processes
• Perform system calls
• Send database traffic
• Receive HTTP requests
• Schedule work
• Allocate resources

eBPF can observe many of these interactions beneath the application layer.

That creates several advantages.

Language independence

Kernel and network events exist regardless of whether the application is written in:

• Go
• Java
• Python
• Node.js
• PHP
• Ruby
• Rust
• C or C++
• Another Linux-compatible language

Protocol and runtime support still varies, but the observation point is less dependent on the application’s source-code framework.

Coverage of unmodified applications

eBPF can provide insight into applications that are:

• Difficult to rebuild
• Owned by another team
• Commercial or proprietary
• Near end of life
• Poorly documented
• Running in containers that should remain unchanged

Infrastructure context

Because the observation occurs close to the kernel and networking layer, eBPF can help correlate application traffic with:

• Processes
• Containers
• Pods
• Nodes
• Network endpoints
• Files
• Sockets
• Runtime activity

Reduced instrumentation inconsistency

Teams do not have to rely entirely on every application owner configuring SDKs in the same way.

What is OpenTelemetry?

OpenTelemetry, commonly abbreviated as OTel, is a vendor-neutral observability framework.

It includes:

• APIs
• SDKs
• Automatic instrumentation
• Semantic conventions
• The OTLP telemetry protocol
• The OpenTelemetry Collector
• Integrations with observability backends

Its purpose is to help applications and platforms generate, collect, process and export telemetry without making the instrumentation model dependent on one monitoring vendor. [1]

OpenTelemetry is not an observability backend

OpenTelemetry does not normally replace:

• Trace databases
• Log-storage systems
• Time-series databases
• Alerting systems
• Dashboard platforms
• Incident-management tools

It produces and transports telemetry to those systems.

What is the OpenTelemetry Collector?

The Collector is a vendor-agnostic telemetry pipeline.

Its core component types include:

• Receivers: Accept telemetry from sources and protocols
• Processors: Filter, enrich, transform, sample or batch data
• Exporters: Send data to one or more destinations
• Connectors: Link pipelines
• Extensions: Add supporting capabilities such as health checks

This allows an organisation to separate telemetry generation from telemetry storage.

For example, a company can send the same telemetry to:

• A managed observability platform
• An internal trace backend
• A security analytics system
• A long-term archive
• A temporary migration destination

without re-instrumenting every application. [5]

What is OpenTelemetry eBPF Instrumentation?

OpenTelemetry eBPF Instrumentation, or OBI, is the OpenTelemetry project’s eBPF-based automatic instrumentation capability.

OBI can inspect application executables and operating-system networking activity to derive telemetry without application-code changes.

Its documented capabilities include automatic capture of:

• Web-transaction traces
• Request rates
• Error rates
• Request duration
• Supported HTTP and gRPC activity
• Selected database operations
• Selected messaging and protocol activity
• Service and infrastructure metadata

OBI exports telemetry through OpenTelemetry or Prometheus-compatible paths, depending on configuration. [4]

What are RED metrics?

RED represents:

• Rate: How many requests are processed
• Errors: How many requests fail
• Duration: How long requests take

These measurements provide a practical starting point for service monitoring.

A platform team may gain visibility into service health before every service team has created custom metrics.

How eBPF and OpenTelemetry work together

eBPF and OpenTelemetry solve different parts of the problem.

• eBPF observes runtime behaviour.
• OpenTelemetry standardises and transports the resulting telemetry.

Step 1: Applications run normally

The application may be:

• A Kubernetes workload
• A Linux service
• A legacy application
• An API
• A database client
• A background processor

No source-code instrumentation is required for the initial eBPF visibility.

Step 2: OBI discovers target processes

Instrumentation can be scoped through selectors such as:

• Executable name
• Container name
• Kubernetes namespace
• Pod
• Deployment
• StatefulSet
• DaemonSet
• Labels
• Annotations

Explicit selection helps avoid instrumenting every process indiscriminately. [7]

Step 3: eBPF probes attach to observation points

Depending on the feature and environment, probes may observe:

• Network connections
• HTTP transactions
• System calls
• Runtime libraries
• Database protocols
• Messaging protocols
• File writes
• Process events

Step 4: Telemetry is created

The instrumentation derives:

• Spans
• Service attributes
• Request duration
• Response status
• Client and server relationships
• RED metrics
• Selected protocol attributes

Step 5: Trace context is propagated where supported

Distributed tracing requires requests to carry trace context between services.

OBI supports automatic propagation in several configurations, but behaviour varies by:

• Protocol
• Runtime
• Encryption
• Proxy
• Load balancer
• Linux kernel
• Container environment

The instrumentation can use the W3C traceparent format, but support is not identical across every language and traffic pattern. [6]

Step 6: The Collector processes telemetry

The Collector can:

• Batch spans
• Add resource information
• Remove sensitive fields
• Drop noisy telemetry
• Sample traces
• Normalise attributes
• Route different signals
• Export to multiple backends

Step 7: Backends store and present the signals

The organisation can use its preferred systems for:

• Tracing
• Metrics
• Logs
• Service maps
• Dashboards
• Alerts
• Incident analysis

Traditional instrumentation versus zero-code observability

Area	Traditional manual instrumentation	eBPF-based zero-code observability
Application changes	Usually required	Not required for initial coverage
Deployment coordination	Per application	Can be platform-managed
Language dependence	SDK and framework specific	Broader Linux and protocol perspective
Business context	Strong	Limited unless enriched
Service discovery	Application configured	Can be runtime discovered
Network visibility	Depends on instrumentation	Strong kernel and network perspective
Legacy coverage	May be difficult	Often a strong use case
Custom spans	Fully supported	Requires code-level supplementation
Business events	Fully supported	Usually not derivable automatically
Permissions	Application-level	May require powerful host capabilities
Cross-platform support	Broad, depending on SDK	Primarily Linux for OBI
Operational model	Distributed across teams	Can be centralised through a platform team
Best use	Deep application semantics	Fast, broad operational baseline

The choice is not necessarily one or the other.

A mature system often uses both.

What zero-code observability can see well

Request flows

For supported protocols, eBPF can identify:

• Incoming requests
• Outgoing requests
• Client and server spans
• Status codes
• Latency
• Dependencies

Service relationships

Runtime traffic can reveal which services actually communicate.

This is useful because architecture diagrams and service registries are frequently incomplete or outdated.

Network latency

Kernel-level observation can help distinguish:

• Application processing time
• Network delay
• Downstream waiting
• Client-visible total request time

OBI documentation describes the ability to derive total request time from lower-level connection, receive, write and close activity, not only the server’s internal processing duration. [11]

Database activity

Supported database-protocol instrumentation may expose:

• Database operation type
• Target system
• Duration
• Errors
• Selected query information

Support and detail vary by protocol, version, encryption and when instrumentation was attached.

Kubernetes workload activity

A DaemonSet-style model can observe workloads across nodes and enrich telemetry with Kubernetes metadata.

This can reduce the need to inject a separate instrumentation sidecar into every workload.

Legacy applications

Older Linux applications may be monitored even when:

• Source code is unavailable
• The build system is fragile
• The framework is unsupported by modern SDKs
• Redeployment is considered risky

Short-lived and dynamic workloads

Runtime discovery can help cover:

• Autoscaled pods
• Ephemeral jobs
• Frequently deployed services
• Containers created by several teams

What zero-code observability cannot automatically understand

Business meaning

The kernel may see an HTTP request to:

POST /payments

It cannot necessarily determine:

• Whether it is a first payment or renewal
• Which subscription plan is involved
• Whether a discount was accepted
• Which business rule selected the route
• Why an approval was required
• What commercial outcome occurred

Internal function boundaries

A request may spend time in:

• Eligibility evaluation
• Tax calculation
• Fraud review
• Document generation
• Recommendation logic

These internal steps may not produce separate kernel-visible interactions.

Manual spans are needed when those distinctions matter.

User and tenant context

Automatically collecting customer identifiers can create privacy risk.

It also usually requires application-level knowledge.

Business events

Examples include:

• Candidate shortlisted
• Order approved
• Subscription upgraded
• Product passport published
• Refund authorised
• Compliance exception accepted

These events should normally be created explicitly by the application or event platform.

Application state

Kernel observation cannot reliably infer every:

• Cache decision
• Feature flag
• Validation result
• In-memory queue
• Domain transition
• Algorithmic outcome

OpenTelemetry explicitly recommends code-based instrumentation as a complement when deeper, application-specific telemetry is required. [4]

Trace, metric and log behaviour

Traces

eBPF-based instrumentation is highly useful for automatically generating request spans.

However, complete distributed tracing depends on reliable context propagation.

Teams should test:

• HTTP versus HTTP/2
• gRPC
• Encrypted traffic
• Proxies
• Service meshes
• L7 load balancers
• Runtime-specific concurrency models
• Kernel-version requirements

A trace that looks complete in a simple test environment may become fragmented in production topology. [6]

Metrics

RED metrics provide a strong operational baseline.

Additional infrastructure metrics may come from:

• Kubernetes receivers
• Host metrics
• Prometheus scraping
• Cloud integrations
• Application SDKs
• Database exporters

eBPF should not be expected to replace every purpose-built metric source.

Logs

OBI does not automatically replace the normal logging pipeline.

Its trace-log correlation feature can intercept supported JSON log writes and add trace and span identifiers. The logs continue through the existing log pipeline, while traces are exported separately.

Documented limitations include:

• JSON-formatted logs are required for automatic enrichment
• Enrichment applies while a relevant span is active
• Logs outside the active span may not receive context
• OBI itself does not become the complete log exporter [8]

Where zero-code observability adds the most value

1. Establishing an observability baseline

A platform team may need visibility across hundreds of services with inconsistent instrumentation.

Zero-code deployment can quickly identify:

• Active services
• Request volumes
• Error rates
• Latency
• Dependencies
• Unmonitored workloads

Manual instrumentation can then be prioritised around the most important journeys.

2. Kubernetes platform engineering

Platform teams can offer observability as a shared capability.

Instead of requiring each team to choose and configure separate agents, the platform can provide:

• Workload discovery
• Standard telemetry export
• Resource enrichment
• Baseline dashboards
• Central filtering
• Data-governance controls

3. Legacy-system modernisation

Before changing an old application, teams need to understand:

• Which clients call it
• Which downstream services it uses
• Which endpoints dominate traffic
• Where latency occurs
• Which databases are active
• Whether the application is still business-critical

eBPF can help produce evidence for migration planning without modifying the legacy code first.

4. Microservice dependency mapping

Runtime traffic can reveal actual dependencies rather than intended dependencies.

This can identify:

• Undocumented service calls
• Circular dependencies
• Shared bottlenecks
• Unexpected external APIs
• Services bypassing approved gateways

5. Incident response

During an incident, zero-code signals can help teams move from:

The service is slow.

to:

Requests from Service A to Service B began waiting on database activity after the latest deployment.

The greatest value comes when traces, metrics, logs, deployment metadata and infrastructure context can be correlated.

6. Coverage during acquisitions or mergers

An organisation may inherit applications written in unfamiliar languages with limited documentation.

A common runtime-level observability layer can establish initial visibility while longer-term integration work proceeds.

7. Third-party or vendor applications

Applications may not expose the instrumentation hooks an organisation wants.

When they run on controlled Linux infrastructure, eBPF may still provide useful operational insight, subject to protocol and security constraints.

8. Temporary troubleshooting

A team may deploy eBPF instrumentation to investigate:

• Latency
• Network failures
• Database time
• Unexpected connections
• Request timeouts

without permanently altering the application.

Deployment patterns

Kubernetes DaemonSet

OBI can run as a DaemonSet across Kubernetes nodes.

Advantages include:

• Node-wide coverage
• Central deployment
• Automatic workload discovery
• Reduced per-pod injection

Considerations include:

• Host PID access
• Linux capabilities
• Kernel compatibility
• Resource limits
• Node security policy
• Upgrade coordination

Standalone Linux process

OBI can also run as a standalone process on a Linux host.

This can be useful for:

• Virtual machines
• Bare-metal services
• Legacy applications
• Non-Kubernetes infrastructure

The process requires sufficient permission to inspect target processes and load eBPF programs. [7]

OpenTelemetry Collector receiver

OBI can be integrated into a Collector build as a receiver.

Current documented limitations include:

• Observation of local processes on the same node
• Linux-only operation
• Required eBPF privileges
• Collector restarts for some configuration changes [7]

Language-level auto-instrumentation

OpenTelemetry also supports injected auto-instrumentation for languages including:

• Java
• .NET
• Node.js
• Python
• Go

This may provide deeper framework-level visibility than kernel-only observation.

Hybrid deployment

An organisation can combine:

• OBI for broad Linux coverage
• Language auto-instrumentation for supported services
• Manual instrumentation for critical business flows
• Existing logs
• Infrastructure receivers
• Cloud-provider telemetry

This is often the strongest production model.

Security and privilege considerations

eBPF observability operates at a sensitive layer.

It may be able to observe:

• Process metadata
• Network destinations
• Protocol fields
• File operations
• Runtime activity
• Database requests
• Kubernetes metadata

Required privileges

Loading eBPF programs and observing performance events require Linux permissions.

Some deployment examples use:

• Privileged containers
• CAP_SYS_ADMIN
• CAP_PERFMON
• Additional capabilities
• Host PID access

OpenTelemetry guidance recommends narrower capabilities where possible, but the exact requirements depend on the kernel, distribution, container runtime and instrumentation features. [7]

Apply least privilege

Security teams should:

• Enable only required capabilities
• Scope instrumentation through selectors
• Exclude sensitive namespaces
• Restrict who can modify the configuration
• Protect Collector endpoints
• Use signed and verified images
• Monitor the instrumentation itself
• Separate production and development policy

Sensitive data

Protocol-level telemetry may expose:

• URLs
• Database statements
• Hostnames
• User-agent information
• Service identifiers
• Messaging topics
• Error details

Teams should classify telemetry as production data.

Collector processors can help:

• Delete sensitive attributes
• Hash identifiers
• Filter endpoints
• Transform values
• Block prohibited data
• Reduce retention

Observability supply-chain risk

Instrumentation components run with elevated access.

Organisations should evaluate:

• Image provenance
• Software bill of materials
• Vulnerability management
• Release verification
• Configuration changes
• Update procedures
• Incident response

Performance and operational overhead

“Low overhead” should not be interpreted as “no overhead.”

Costs can include:

• CPU used by probes
• Memory used by instrumentation
• Kernel event processing
• Telemetry buffering
• Network export
• Collector processing
• Backend storage
• High-cardinality dimensions

Measure overhead in the real environment

Benchmark:

• Baseline CPU and memory
• Instrumented CPU and memory
• Request latency
• Tail latency
• Event drops
• Collector queue pressure
• Export volume
• Backend ingestion cost

Control high-volume telemetry

Possible controls include:

• Service selection
• Endpoint filtering
• Attribute filtering
• Sampling
• Batching
• Aggregation
• Excluding health checks
• Excluding internal observability components
• Limiting database details

OBI includes performance and high-volume configuration options, but trade-offs can affect timing accuracy or dropped-event behaviour. [7]

Observe the Collector

The Collector itself exposes internal telemetry including:

• CPU
• Memory
• Accepted items
• Refused items
• Processor input and output
• Export failures
• Queue health

An unmonitored telemetry pipeline can silently create observability gaps.

How to design a production architecture

A practical architecture may look like:

Applications and workloads
        ↓
eBPF / language auto-instrumentation
        ↓
Node or local OpenTelemetry Collector
        ↓
Gateway Collectors
        ↓
Processing, filtering and sampling
        ↓
Trace, metric and log backends
        ↓
Dashboards, alerts and incident workflows

Application layer

Contains:

• Microservices
• APIs
• Databases
• Legacy applications
• Background jobs
• External dependencies

Instrumentation layer

May include:

• OBI
• Java agent
• .NET auto-instrumentation
• Node.js auto-instrumentation
• Python auto-instrumentation
• Manual OpenTelemetry SDKs
• Prometheus exporters

Node Collector

Useful for:

• Local collection
• Host enrichment
• Buffering
• Reducing direct backend connections

Gateway Collector

Useful for:

• Central routing
• Tail sampling
• Policy enforcement
• Multi-tenant separation
• Export to several backends
• Load balancing

Observability backends

Store and analyse:

• Traces
• Metrics
• Logs
• Profiles
• Events

A practical implementation roadmap

Phase 1: Define the objective

Select a measurable problem such as:

• Reduce unmonitored services
• Discover dependencies
• Improve incident resolution
• Monitor legacy applications
• Standardise telemetry
• Reduce instrumentation effort

Do not begin with “deploy eBPF everywhere.”

Phase 2: Inventory the environment

Document:

• Linux distributions
• Kernel versions
• Kubernetes versions
• Container runtimes
• Languages
• Protocols
• Service meshes
• Proxies
• Encryption patterns
• Existing agents
• Current backends

Phase 3: Choose a narrow pilot

A good pilot includes:

• Several services
• Real traffic
• One database
• One external API
• Existing dashboards for comparison
• An application team willing to validate the results

Phase 4: Establish security requirements

Determine:

• Permitted Linux capabilities
• Whether privileged containers are allowed
• Which namespaces may be monitored
• Which fields are sensitive
• Which telemetry can leave the environment
• Who can change instrumentation scope

Phase 5: Deploy the collection pipeline

Configure:

• OBI or other zero-code instrumentation
• OTLP export
• Collector receivers
• Processors
• Exporters
• Resource enrichment
• Internal telemetry

Phase 6: Validate service discovery

Confirm:

• Correct service names
• Correct namespaces
• Correct pod and node attribution
• No accidental instrumentation of system components
• Stable identity across deployments

Poor service identity makes the rest of the telemetry difficult to use.

Phase 7: Validate traces

Test:

• Internal HTTP
• External HTTP
• HTTPS
• gRPC
• Proxies
• Load balancers
• Database operations
• Error responses
• Timeouts
• Retries

Phase 8: Compare with known truth

Compare eBPF results with:

• Application logs
• Existing APM
• Load tests
• Database monitoring
• Network tools
• Manual timing

Identify blind spots and discrepancies.

Phase 9: Add governance

Implement:

• Attribute allowlists
• Redaction
• Sampling
• Retention
• Tenant separation
• Cost limits
• Change review
• Audit logging

Phase 10: Add application-level telemetry

Instrument the business flows that eBPF cannot infer.

Examples:

• Checkout stage
• Candidate application status
• Product-passport approval
• Subscription change
• Risk decision
• Payment outcome

Phase 11: Define service-level objectives

Use the telemetry to define measurable service expectations such as:

• Availability
• Error rate
• Request latency
• Dependency performance
• Queue delay

Phase 12: Measure outcomes

Track:

• Percentage of workloads observed
• Time to onboard a service
• Trace continuity
• Data drop rate
• Incident detection time
• Mean time to resolution
• Manual instrumentation effort
• Telemetry cost
• False alerts
• Developer satisfaction

When zero-code observability is a strong fit

Consider it when:

• Many Linux services lack consistent instrumentation
• Kubernetes workloads change frequently
• Legacy systems are difficult to rebuild
• Platform teams need central coverage
• Service dependencies are unknown
• Rapid baseline visibility is required
• Several languages are in use
• The organisation wants vendor-neutral telemetry
• Existing manual instrumentation is inconsistent

When it is not enough

Zero-code observability should not be the only strategy when:

• Business transactions require detailed semantic tracing
• The application runs outside supported Linux environments
• Protocols or runtimes are not adequately supported
• Traffic is heavily encrypted or transformed by unsupported intermediaries
• Security policy prohibits the required host capabilities
• Client-side browser or mobile telemetry is required
• Domain events are more important than network calls
• Detailed in-process profiles are necessary
• Regulatory rules require explicit audit events from application logic

Zero-code versus automatic instrumentation

The terms overlap but are not identical.

Automatic instrumentation

Automatically inserts or activates telemetry generation through:

• Runtime agents
• Library hooks
• Bytecode changes
• Operator injection
• Framework integrations
• eBPF

eBPF instrumentation

Observes supported activity through Linux kernel, networking and selected runtime probes.

All eBPF application instrumentation is a form of automatic instrumentation.

Not all automatic instrumentation uses eBPF.

Zero-code versus agentless

Zero-code is not always agentless.

An eBPF-based solution commonly deploys:

• A node-level process
• A DaemonSet
• A privileged container
• A Collector
• A host service

The application may remain unchanged, but instrumentation software still operates in the environment.

“Agentless” should therefore be used carefully.

The strongest model is hybrid observability

A useful observability strategy can be layered.

Layer 1: Infrastructure telemetry

Collect:

• CPU
• Memory
• Disk
• Network
• Kubernetes state
• Cloud-service metrics

Layer 2: Zero-code application telemetry

Use eBPF or language agents for:

• Request traces
• RED metrics
• Dependencies
• Database timing
• Runtime coverage

Layer 3: Manual application telemetry

Add:

• Business spans
• Domain attributes
• Custom metrics
• Business events
• Explicit error context

Layer 4: User-experience telemetry

Measure:

• Browser performance
• Mobile performance
• Synthetic journeys
• Real-user experience

Layer 5: Business and product outcomes

Connect system behaviour to:

• Conversion
• Revenue
• Completion rate
• Retention
• Support demand
• Operational cost

eBPF helps teams climb the first part of this stack quickly.

It cannot complete the entire stack automatically.

The future of eBPF and OpenTelemetry

The direction of travel is toward a more unified instrumentation model.

Instead of every language, agent and vendor producing unrelated data, OpenTelemetry provides common signal formats and semantic conventions.

eBPF expands the range of systems that can generate useful telemetry without application changes.

The likely result is an observability architecture in which:

• Platform teams deploy baseline instrumentation
• Applications inherit common visibility automatically
• Developers add semantic instrumentation where it matters
• Collectors enforce data policy
• Telemetry remains portable between backends
• AI-assisted operations analyse correlated signals
• Monitoring becomes less dependent on application-by-application setup

OBI is actively evolving, and its documentation continues to identify runtime, protocol and distributed-tracing limitations. Production teams should validate the exact version and supported configuration rather than assuming universal coverage. [4][6][10]

Conclusion

Zero-code observability changes where application monitoring can begin.

Instead of waiting for every service team to:

• Select an SDK
• Add instrumentation
• Configure context propagation
• Rebuild the application
• Deploy a new version
• Maintain agent configuration

a platform team can establish broad visibility from the Linux runtime and network layer.

eBPF provides the observation capability.

OpenTelemetry provides the standard telemetry model and collection pipeline.

Together, they can reduce onboarding effort, expose service relationships, improve coverage and create a vendor-neutral foundation for traces and metrics.

But zero-code observability is not magical.

It cannot automatically understand every business transaction, internal decision or domain event. It introduces Linux privilege requirements, protocol limitations, telemetry-governance responsibilities and operational overhead.

The correct strategy is not:

Replace all application instrumentation with eBPF.

It is:

Use zero-code instrumentation to establish comprehensive operational visibility, then add precise code-level telemetry where business and application meaning requires it.

That approach gives organisations both breadth and depth:

• Breadth from eBPF
• Portability from OpenTelemetry
• Meaning from application instrumentation
• Control from a governed Collector pipeline

That is the practical future of application observability.

Frequently Asked Questions

What is zero-code observability?

Zero-code observability collects application telemetry without manually modifying application source code. It can use runtime agents, automatic library instrumentation or eBPF.

What is eBPF?

eBPF is a Linux technology that runs verified programs at kernel and system hooks for use cases including networking, security, tracing and observability.

What is OpenTelemetry?

OpenTelemetry is a vendor-neutral framework for generating, collecting, processing and exporting telemetry such as traces, metrics and logs.

What is OBI?

OBI is OpenTelemetry eBPF Instrumentation, an eBPF-based automatic instrumentation capability within the OpenTelemetry project.

Does eBPF require application-code changes?

No. eBPF-based instrumentation can observe supported application and network activity without editing the application source.

Does zero-code mean no agent is required?

No. A node process, DaemonSet, runtime agent or Collector may still need to be installed and operated.

Can eBPF produce distributed traces?

Yes, for supported protocols and environments. Trace propagation has runtime, encryption, proxy and kernel-version limitations.

Can eBPF collect logs?

OBI can enrich supported JSON logs with trace and span context, but existing logging pipelines are still needed to collect and export the logs.

Can eBPF replace manual instrumentation?

No. Manual instrumentation remains necessary for custom spans, business events, domain attributes and internal application context.

Is OBI limited to Linux?

The current OBI eBPF instrumentation model is Linux-based. Windows and macOS workloads require other instrumentation approaches.

Does OpenTelemetry store telemetry?

Usually not. The OpenTelemetry Collector processes and exports telemetry to observability backends that store and analyse it.

What signals can OpenTelemetry handle?

OpenTelemetry supports traces, metrics and logs, along with contextual metadata such as resources and baggage.

Is eBPF safe for production?

It can be used in production, but organisations must test overhead, kernel compatibility, permissions, protocol support and security controls.

What permissions does eBPF instrumentation require?

Requirements vary, but deployments may need Linux capabilities for loading eBPF programs, reading performance events and observing host processes.

What is the best use case for zero-code observability?

It is particularly useful for gaining rapid baseline visibility across Linux applications, Kubernetes workloads, microservices and legacy systems.

What is the recommended long-term strategy?

Use a hybrid approach: zero-code instrumentation for broad operational coverage and manual OpenTelemetry instrumentation for critical business and application context.