OTel isn’t going well
OpenTelemetry (OTel) is emerging as the de facto observability standard, but many engineers find it overengineered, slow, and complex compared to simpler, focused tools like Prometheus, Jaeger, or vendor-specific solutions such as Datadog and AWS X-Ray. Critics point to heavy SDKs, confusing documentation, performance and cold-start penalties (especially in serverless environments), and awkward integration patterns, while supporters argue that a common open standard for traces, metrics, and logs is still the best way to avoid vendor lock-in and enable interoperability. The exchange highlights a broader tension between flexible, ambitious standards and lean, purpose-built tooling, as well as a desire for better developer experience and more coherent abstractions across observability pillars.
Overall sentiment on OTel
- Many see OTel as overengineered, complex, and immature, especially compared to simpler, focused tools.
- Others argue it’s “fine” or “important” as a common standard; not perfect, but the best available path to interoperability.
- A recurring tension: ambitious goals and heavy design vs. practical usability, performance, and clarity.
Complexity, APIs, and developer experience
- SDKs and instrumentation are described as “dizzyingly complex,” “Java/XML maximalist,” and “design by committee.”
- Auto-instrumentation often breaks non-trivial apps; contrib packages are seen as fragile and hard to customize.
- Global state, static methods, hidden “inject” logic, and cross-language uniformity are criticized; many want simple, explicit, DI-style clients.
- Docs are widely considered poor, inconsistent, and sometimes wrong; some users lean on reading source, sniffing traffic, and debug exporters instead.
Performance, cost, and serverless
- Several users report substantial CPU/memory overhead, especially in Python/Ruby and Lambda; cold-start penalties can be severe.
- For Lambda, OTel layers and AWS’ OTel distro are seen as heavy compared to older X-Ray tooling or vendor agents.
- Concern that monitoring can cost more than running the app; “OTel tax” vs. vendor lock-in tradeoff.
Tracing, metrics, logs model
- Debate over whether tracing, metrics, and logs should be unified or are fundamentally distinct.
- Some suggest instrumenting once with generic “events/spans” and deriving logs/metrics/traces dynamically; others say that’s conceptually neat but practically brittle, expensive, or unscalable.
- Adaptive sampling and ingest-side aggregation are cited as real-world strategies; cost typically dominated by storage.
Alternatives and ecosystems
- Many praise Prometheus (with exporters, node/blackbox exporters, Mimir/VictoriaMetrics) and Jaeger/Tempo for simpler mental models and reliability.
- Some prefer self-hosted stacks (Grafana + Loki/Tempo/Mimir, VictoriaMetrics, ClickHouse-based stacks, SigNoz), but note fragmentation and multiple query languages as pain points.
- For low-friction, “it just works” setups, proprietary vendors (Datadog, AWS CloudWatch/X-Ray, etc.) are seen as easier but lock-in heavy.
Standards vs. reality
- OTel’s value as a vendor-neutral OTLP spec and common schema is acknowledged.
- Frustration that, despite the standard, exporters still need per-vendor quirks and many vendors only offer partial, buggy, or second-class OTel support.