Automatic Instrumentation

Automatic instrumentation creates telemetry for supported frameworks and libraries without requiring tracing calls throughout application code. It provides useful baseline visibility, but teams often add manual spans for business-specific operations and must configure export, sampling, and privacy.

Automatic instrumentation produces telemetry—commonly spans, and sometimes metrics or logs—by integrating with supported frameworks and libraries. In a Python service, instrumentation may observe incoming web requests, database calls, or outgoing HTTP requests without requiring tracing calls at each operation in application code.

A typical setup uses an instrumentation library or agent that wraps, patches, or integrates with library APIs. It records operation boundaries and attributes, and may propagate trace context across supported network clients and servers. Exact coverage depends on the instrumentation package, library versions, and configuration.

The resulting spans can be exported through an observability pipeline, often using OpenTelemetry-compatible components. Automatic instrumentation reduces repetitive work and helps establish end-to-end traces, but it cannot reliably infer every business operation or domain-specific attribute.

Teams commonly combine it with manual instrumentation. Automatic hooks capture common infrastructure activity, while explicit spans or attributes identify meaningful business steps, such as validating a payment or reserving inventory. Production use still requires decisions about sampling, sensitive data, overhead, and exporter configuration.

Key points

Interview questions

What is automatic instrumentation in distributed tracing?

It is an approach where integrations for supported frameworks and libraries generate telemetry around operations such as handling a web request or calling a database. The application can gain useful spans without developers placing tracing calls around every such operation. Coverage and behavior depend on the installed instrumentation and configuration. Developers may still add manual spans for business-specific work.

How does automatic instrumentation produce spans and connect them across services?

Common approaches include patching or wrapping library APIs, installing framework hooks, or using an agent that configures integrations at startup. These mechanisms observe operation boundaries and can attach attributes such as the operation name or destination. Some integrations also inject and extract trace context at network boundaries. The specific mechanism and supported operations are implementation-dependent.

What would you evaluate before enabling automatic instrumentation in production?

I would identify supported integrations and their version constraints, then enable only the needed instrumentation and export to the intended telemetry pipeline. I would verify span names, parent-child relationships, propagated context, and useful attributes using a test request. I would also assess sampling, telemetry volume, sensitive-data handling, and runtime overhead. Gaps in domain visibility can be addressed with targeted manual spans rather than enabling indiscriminate capture.

Can automatic instrumentation replace all manual tracing?

No. Automatic instrumentation can capture common infrastructure operations, but it generally lacks enough domain knowledge to explain the meaning of every application step. A database span might show that a query ran, while a business span can indicate that the operation was reserving a seat or authorizing a payment. Combining both gives infrastructure detail and application-level intent.