OTel Isn't Going Well (And I Made A Spreadsheet About It)

7.3 relevance

Critical analysis of OpenTelemetry challenges, highly relevant to observability and data engineering.

General matduggan.com

Answer the board on AI readiness

Arrive with evidence, not opinion. See how your foundation benchmarks against your peers, get a clear read, and leave with a ranked place to start.

Why It Matters

As a solutions architect evaluating observability stacks, this analysis quantifies the hidden cost of OTel's vendor-neutral promise—the stability gate and maintainer bottleneck create real latency and risk for teams that can't absorb the manual instrumentation cliff.

Key Takeaways

Audit your team's observability maturity and language support before committing to OTel; treat the core/contrib split as a risk boundary for production rollouts.

Summary

OpenTelemetry's struggles stem from a three-way collision: a binary stability gate that makes marking features as stable irreversible, a small maintainer bench, and an enormous scope spanning dozens of languages and frameworks. This creates perverse incentives to endlessly debate potential problems rather than ship, leaving languages like Python and JavaScript years behind Go and .NET. The result is a steep cliff between magical auto-instrumentation and painful manual instrumentation, making OTel a risky bet for smaller teams without dedicated observability engineering bandwidth.

Author

Mathew Duggan