The lazy developer’s guide to observing your own code
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
Developers are increasingly asked to instrument their own code with OpenTelemetry, and this piece makes the case for why that benefits developers directly: faster debugging, quicker shipping, better code quality, clearer understanding of distributed systems, and easier untangling of AI-generated code. It covers common instrumentation pain points (SDK maturity gaps, lack of auto-instrumentation for languages like Rust/Elixir, verbose APIs, cardinality issues), practical tips (start with zero-code instrumentation, supplement manually, practice observability-driven development, use AI carefully), what to instrument (spans, logs, latency metrics, home-grown frameworks), and how to use AI coding assistants effectively for instrumentation. It also walks through setting up the OpenTelemetry Collector with sample YAML configs and compares three open-source desktop visualization tools: OTel Desktop Viewer, otel-tui, and OTel Front, including Docker Compose setups and their respective trade-offs.
Table of contents
How does observability help developers?Instrumentation pain pointsMaking OpenTelemetry instrumentation work for youWhat to instrumentAI-assisted instrumentationObservability tools for developersChallenges with OpenTelemetry tooling for developersFinal thoughtsQuestions this post answers
What open source desktop tools can I use to view OpenTelemetry traces, logs, and metrics locally without a SaaS vendor?
Three open source desktop tools exist for locally visualizing OpenTelemetry signals: OTel Desktop Viewer (traces only, web UI, started October 2022), otel-tui (traces, logs, metrics plus a service topology view, terminal UI, started March 2024), and OTel Front (traces, logs, metrics, web UI with a non-clickable dashboard, started November 2025). All three can be run via Docker Compose alongside an OpenTelemetry Collector instance. daily.dev surfaces practical comparisons like this for developers choosing local observability tooling.
Which programming languages support zero-code OpenTelemetry instrumentation?
Zero-code (auto) instrumentation for OpenTelemetry is available for Java, .NET, Python, JavaScript, PHP, and Go. Languages like Rust and Elixir lack zero-code support, meaning developers must write manual code-based instrumentation from scratch for those languages. Even where zero-code instrumentation exists, manual instrumentation is still needed to fill in gaps specific to an application. Track which languages gain OpenTelemetry auto-instrumentation support as teams plan their observability rollout on daily.dev.
What is the SpanMetrics connector in the OpenTelemetry Collector and what does it do?
The SpanMetrics connector calculates the duration of an OpenTelemetry span and feeds that duration into a metrics pipeline as a receiver, acting as an exporter in a traces pipeline and a receiver in a metrics pipeline simultaneously. This helps developers spot latency issues when a span takes longer than usual to complete, without needing a separate metrics instrumentation step. Developers configuring Collector pipelines can find setup details like this through daily.dev.