Why Developers Should Own Their Own Observability (And How to Start)

Observability is not new to developers. Stack traces, log statements, and profiling tools have been part of the development workflow for decades. What is new is the expectation that developers instrument distributed systems with the same discipline they apply to unit tests—before the code ships, not after it breaks.

Why This Matters

The CNCF’s argument is pragmatic rather than principled: instrumenting your code while writing it makes your own job easier in five specific ways. Debugging becomes faster because you have the signal you need rather than reconstructing what happened from user reports. Deployment cycles accelerate because slow paths and edge cases surface in development rather than production. Code quality improves because the instrumentation reveals real runtime behavior. Microservice interactions become legible because traces capture the actual request flows rather than the intended ones. And AI-generated code—which is becoming an increasing share of what engineers are reviewing rather than writing—is easier to audit when its behavior is observable.

The fifth point is underappreciated. An AI coding agent that produces a function with a subtle latency problem under load is considerably easier to identify when that function emits traces than when it does not.

How to Do It

The practical entry point is zero-code instrumentation through OpenTelemetry. For Java, Python, .NET, and Go, the OpenTelemetry SDKs provide automatic instrumentation that captures traces, logs, and metrics without requiring instrumentation code in the application itself. This establishes a baseline of observability for any service that uses these languages with effectively no implementation overhead.

Manual spans supplement the baseline for business-critical operations—specific transactions, external API calls, or processing steps where the default trace granularity is insufficient. The guidance is to instrument these while writing the code, while the business context is still present in working memory, rather than retroactively adding observability to code that has already been reviewed and merged.

For local development, three open-source tools make the signal visible without requiring a full observability stack: OTel Desktop Viewer for traces in a web interface, otel-tui for traces, logs, and metrics with service topology in a terminal UI, and OTel Front for all signal types in a dashboard. Each connects to the OpenTelemetry Collector and is designed for developer use rather than production SRE workflows.

AI-assisted instrumentation is also worth noting: specifying the instrumentation goal, service context, and expected signal types in a prompt generates functional instrumentation code that would otherwise take meaningful time to write manually.

Source: Cloud Native Computing Foundation

Content created with AI assistance and reviewed for accuracy.