Observability is no longer solely the responsibility of site reliability teams; developers are increasingly expected to add traces, logs, and metrics to the code they write so they can diagnose failures and understand application behavior before and after it reaches production. In a post published on the CNCF blog on August 25, 2026, Adriana Villela, an OpenTelemetry community manager and CNCF Ambassador, and Diana Todea, an OpenTelemetry documentation contributor and CNCF Ambassador, present a practical path for reducing the burden of this task using OpenTelemetry.
The authors begin with a familiar objection among developers: adding instrumentation means more code to maintain, additional complexity, and the possibility of errors or technical debt. However, they connect this cost to direct practical benefits, most notably reduced debugging time, faster feature completion and deployment, the discovery of slow paths, hidden retries, and edge cases, as well as a better understanding of distributed systems. The authors also believe that observability helps deconstruct applications produced with the assistance of artificial intelligence tools when their quality varies.
Start with automation, then add what is missing
The first recommendation is to use zero-code instrumentation whenever it is available. This mechanism adds instrumentation to an application without modifying its source code by intercepting calls to common frameworks and libraries at runtime or during compilation. According to the article, this type of support is available for Java, .NET, Python, JavaScript, PHP, and Go.
The authors do not consider automation a complete solution; it does not necessarily know what matters in the application’s own logic. It should therefore be supplemented with manual instrumentation to add traces, metrics, logs, context propagation, and attributes specific to the code. They also suggest practicing observability-driven development, meaning adding observability while writing new code rather than returning to it days later, when the details of the design are less present in the developer’s mind.
What deserves measurement?
- Important units of work: Add spans for incoming requests such as HTTP calls, outgoing connections to databases, caches, APIs, and queues, as well as business-critical operations. The article warns against creating a span for every small call, because this may generate noise that conceals important signals.
- Impactful events: Use logs to explain why something happened, focusing on errors, validation failures, retry and fallback paths, and security events such as authentication failures and authorization denials.
- Response time: Latency metrics help determine why a particular request takes longer than usual, especially in multistep paths such as adding an item to a shopping cart and then completing the purchase.
- Internal frameworks and libraries: Instrumenting frameworks and libraries developed by the team itself may provide broad coverage because large parts of the application pass through them.
Use AI as an assistant, not as a substitute for review
The authors believe that AI-powered programming tools can reduce the time spent exploring the interfaces of different OpenTelemetry APIs and SDKs, and can also help with legacy code. However, using them effectively requires precise guidance. They suggest specifying the assistant’s role, the objective, the code location and language used, and the desired output, while including links to relevant documentation or code examples.
They also recommend asking the agent to explain its decisions, using another agent as a judge to challenge those decisions when possible, and then iterating and improving the results rather than accepting the first modification suggested by the tool. These recommendations reflect the authors’ views and experience; they are not a guarantee that code produced by AI will be correct or suitable for the application.
A local path to understanding telemetry data
Instrumentation is not complete without a way to read the resulting data. The article explains that the OpenTelemetry Collector operates as a vendor-neutral agent, receiving traces, logs, and metrics from multiple sources, processing them when necessary, and then sending them to one or more destinations. It consists of Receivers for receiving data, Processors for modifying, hiding, or sampling attributes, Exporters for sending it, and Pipelines for defining the path of each signal type, in addition to Connectors for linking two pipelines.
For development purposes, the article suggests a simple setup that receives data over OTLP using gRPC or HTTP and exports it to a Debug component, while using the SpanMetrics Connector to convert span duration into metrics data that helps monitor latency problems. It then reviews three open-source tools that can run with the Collector and Docker Compose: OTel Desktop Viewer for displaying traces, otel-tui for displaying traces, logs, and metrics and service relationships through a terminal interface, and OTel Front for displaying the same three types with a dashboard.
Limitations to account for
The experience shows that these tools are not free of obstacles. Setting them up was easier for the authors because of their previous experience with the OpenTelemetry Collector and Docker, while beginners may face greater difficulty. The tools also depend on third-party open-source projects, which may not always keep pace with the latest versions of the OpenTelemetry API and SDK or achieve complete feature parity.
The article highlights broader challenges in the ecosystem, including varying levels of activity among the special interest groups for each language, the absence of automation for some languages such as Rust and Elixir, and the abundance of choices among SDKs, eBPF, and compile-time instrumentation, in addition to API stability issues, dependency upgrades, and high cardinality in some attributes.
Editorial perspective: The practical value here is not in adding another tool, but in turning observability from a deferred task into part of the code development cycle. The guide identifies a low-friction starting point and then clearly defines what automation cannot know. However, the source does not provide a quantitative performance comparison among the tools and does not establish that one path suits all languages or environments; recommendations should therefore be treated as a starting framework, with configurations tested and data volume, cost, and suitability for the actual application reviewed.