4 min read
|
Saved February 14, 2026
|
Copied!
Do you care about this?
The article discusses the current state of OpenTelemetry, highlighting its growing adoption but also the significant hurdles it faces, especially in supporting Rust and integrating with Prometheus. It addresses the complexities of implementation, issues with semantic conventions, and the challenges of adopting OpenTelemetry alongside existing Prometheus setups.
If you do, here's more
OpenTelemetry is gaining traction as a key standard for observability, but it still faces hurdles. While the project, linked to the Cloud Native Computing Foundation (CNCF), has seen contributions aimed at improving usability and features, its adoption isn’t universal. Support for Rust, a newer language, remains in beta for traces, metrics, and logs, making it less reliable compared to other major languages that already support at least metrics. Rust’s later adoption at scale and the existing effectiveness of other instrumentation methods contribute to this lag.
Implementation complexity is a significant barrier for many organizations. OpenTelemetry can be challenging to set up, especially in large, multi-cluster cloud environments. Ted Young from Grafana Labs highlighted that while the goal of standardizing observability signals is vital, the nuances of semantic conventions for labels and attributes complicate tracing. Large teams must maintain uniformity in these conventions, which can lead to poor data quality. The lack of established protocols for various data types further complicates matters.
For organizations already using Prometheus, integrating OpenTelemetry poses risks. Prometheus has compatibility issues, especially with the data formats and design philosophies that differ from OpenTelemetry. Despite improvements with Prometheus 3.0, challenges remain, particularly with how metrics are collected. Efforts are ongoing to refine data structures and labels to align better with both Prometheus and Mimir.
Rust's integration with OpenTelemetry is slow due to its existing tooling, like Tokio tracing, which doesn’t fully meet distributed tracing requirements. Young mentioned the awkward position of the OpenTelemetry community considering adopting Tokio tracing as the official solution, despite its limitations. The lack of momentum from the original developers of Tokio raises concerns about future integration and support. The ongoing discussions within the Rust community highlight the technical gaps and uncertainties that still need addressing.
Questions about this article
No questions yet.