The problem with OpenTelemetry
OpenTelemetry’s growing role as a vendor-neutral standard for application telemetry is praised for reducing lock-in and unifying traces, metrics, and logs, but many engineers find its APIs, SDKs, and documentation overly complex and hard to adopt. Several commenters argue that the project’s broad scope and attempt to cover every signal and language has led to bloated implementations, confusing abstractions, and inconsistent behavior across SDKs, especially in languages like Python and JavaScript. Others counter that, despite rough edges and unfinished parts, OpenTelemetry already works well in practice, continues to improve, and delivers enough flexibility and cost control to justify its complexity.
Complexity and Developer Experience
- Many commenters describe OpenTelemetry (OTel) as conceptually heavy and hard to get started with, especially from the docs.
- Python and JavaScript SDKs are called out for confusing global state, “god objects,” surprising behavior (e.g., header encoding), and silent failures.
- Collector configuration is seen as powerful but hard to understand; multiple transport options (HTTP, protobuf-over-HTTP, gRPC) add to confusion.
- Others report smooth experiences, particularly in Go, .NET, and JVM, saying basic tracing took under a few hours and that DX is improving over time.
Traces vs Metrics vs Logs
- Strong disagreement on whether logs and metrics should be first-class alongside traces.
- One camp argues logs are just events and metrics are aggregations over span data; rich tracing plus aggregation should be enough for most debugging and performance analysis.
- Another camp insists logs, metrics, and traces are fundamentally different primitives with distinct semantics, performance characteristics, and regulatory constraints; collapsing them into a single “event” abstraction is seen as naive.
- Metrics are praised for cheap, continuous visibility and for surfacing “missing” behavior (e.g., requests that never happen), while traces are praised for detailed root-cause analysis but criticized for cost and sampling issues.
Scope, API/SDK Design, and “Bundling”
- Several people think OTel tries to solve too many problems (all signals, all languages, transport, collectors, semantics), leading to bloated SDKs and a steep learning curve.
- Others counter that the API/SDK split already exists, language SDKs are allowed to differ, and a unified project improves interoperability and cross-signal correlation.
- There is debate over whether logs/metrics should live in the same project as tracing or as separate but related efforts.
Vendor Neutrality and Lock‑in
- Many see OTel’s main value as breaking vendor lock‑in: standard APIs, one agent/collector per host, and the ability to route data to different commercial or open-source backends.
- Some observers suspect commercial vendors whose products overlap tracing may be biased against OTel; others argue vendors should contribute more to the standard they benefit from.
Adoption Patterns and Gaps
- Success stories include small projects using single-binary backends and large orgs standardizing on OTel to escape opaque pricing.
- Pain points include short‑lived processes, span size limits, unclear semantics (e.g., trace events vs log records), and the feeling that tracing-specific goals are slowed by the broader “everything telemetry” ambition.