Skip to main content
Code-based and library-based instrumentation require changing application source code: you need access to the code and knowledge of where to add instrumentation. In many real-world situations you may not have source access or permission to modify the application. In those cases, automatic (zero-code) instrumentation is often the fastest and least intrusive way to add observability. In zero-code instrumentation, an agent injects telemetry at runtime so an application begins producing traces, metrics, and logs without any source changes. You do not need to learn the OpenTelemetry API/SDKs or modify the application to get basic observability.
The image illustrates "Automatic / Zero-Code Instrumentation" with a person examining code on a computer screen and others working on a syringe-like instrument. It conveys the concept of automatic telemetry data generation without code changes.
What does zero-code instrumentation look like in practice? Here are two common, practical examples for JVM and Python applications.
  • Java (JVM): attach the OpenTelemetry Java agent when starting the JVM:
The Java agent instruments supported frameworks and libraries at class-load time by modifying bytecode. No source changes are required.
  • Python: use the OpenTelemetry CLI wrapper to instrument supported libraries at runtime:
The CLI performs monkey-patching of common libraries (Flask, Django, Requests, etc.) so the running process emits telemetry without modifying app.py. Both examples turn an existing application into a telemetry-producing source with no code edits. This makes automatic instrumentation a fast way to add observability—often in minutes. The main advantage is speed: enable it quickly without touching the code. It’s ideal for legacy apps, third-party binaries, or environments where developers cannot modify source. The trade-off is that domain-specific or business-logic spans are generally not created automatically; automatic instrumentation covers widely used frameworks and libraries but cannot infer custom business operations.
The image shows a comparison of pros and cons for a concept. Pros include zero code changes and compatibility, while cons mention limitations with domain-specific operations.
How does the agent inject instrumentation without changing source code? Common techniques include:
  • Monkey patching: used in dynamic languages such as Python and JavaScript. At runtime, the agent replaces or wraps library functions to call telemetry APIs.
  • Bytecode manipulation: used in statically compiled runtimes such as Java and .NET. The agent modifies bytecode as classes/assemblies are loaded to insert telemetry before/after method execution.
  • eBPF-based instrumentation: OpenTelemetry’s eBPF initiative observes system-level events (network, syscalls) from the kernel, providing language-agnostic and non-intrusive telemetry—useful in containerized or polyglot environments (see https://github.com/open-telemetry/opentelemetry-ebpf).
Each technique has different trade-offs in terms of fidelity, overhead, and visibility into application internals.
The image outlines three techniques used in zero-code instrumentation: monkey patching (Python, JavaScript), bytecode manipulation (Java, .NET), and OpenTelemetry eBPF instrumentation (OBI).
When these techniques run, agents typically provide the OpenTelemetry API and SDK implementations at runtime (or hook into existing ones). That means exporters, processors, and resource configuration become available so spans, metrics, and logs can be produced and exported without touching application source code.
The image shows a diagram of injected OpenTelemetry capabilities at runtime, featuring the OpenTelemetry API and SDK.
What parts of an application get instrumented automatically? Typical coverage includes:
CategoryTypical Examples
HTTP clientsRequests, http.client, axios
Web frameworksFlask, Django, Express, Spring Boot
Database clientsSQLAlchemy, JDBC drivers
Messaging systemsKafka, RabbitMQ, AMQP libraries
Automatic instrumentation usually does not capture application-specific business logic—those spans must be added with code-based instrumentation if you need fine-grained, domain-specific traces.
The image depicts categories of services that are instrumented automatically: HTTP Clients, Web Frameworks, Database Clients, and Messaging Systems. It notes that custom business logic requires code-based instrumentation.
Configuration: even without source access, zero-code instrumentation still offers flexibility. Typical mechanisms include:
  • Environment variables (most common)
  • System properties (common for Java/.NET)
  • Startup arguments (runtime customization)
Using these you can set service metadata, exporters, propagators, resource attributes, sampling, and other runtime behaviors. Example configuration options you might set via environment variables:
  • Service name (so traces are grouped under a logical service in your observability backend)
  • Exporter (OTLP, console, etc.)
  • Propagators (W3C trace-context, B3)
  • Resource attributes (environment, region, team, etc.)
Example environment variable snippets:
The image displays a graphic titled "Common Configuration Settings" with four sections labeled: Service Name, Exporter, Propagator, and Resource Attributes, each with icons and examples.
Why is zero-code instrumentation popular?
  • Fast and non-invasive: enables telemetry quickly without code changes.
  • Great for initial observability: provides immediate visibility into production systems.
  • Low developer effort: only change how the app is started or its runtime environment.
  • Configurable and extensible: environment variables and startup options let you tailor behavior.
The image presents the advantages of zero-code instrumentation, highlighting four benefits: fast and non-invasive setup, suitability for initial observability, no developer effort required, and being configurable and extensible.
Zero-code instrumentation is an excellent first step for gaining observability quickly. Use it to get baseline telemetry, then add code-based instrumentation selectively where you need domain-specific traces or richer context.
That covers the essentials of zero-code automatic instrumentation. Use it to bootstrap observability, and augment with code-based instrumentation when you need custom, business-level spans. Links and references

Watch Video