> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/opentelemetry/from-missing-events-to-complete-visibility-tracing-enterprise-transactions-with-opentelemetry/day-14-34-the-challenge-of-opentelemetry.md).
# Day 14/34 The Challenge of OpenTelemetry
## 1. Otel Development
OTel has reached significant milestones with stable releases for both tracing and metrics. The process of incorporating trace IDs and span IDs into application logs is simple, necessitating only a few configuration adjustments.
Despite these advancements, the widespread adoption of OTel in production environments may encounter a delay of another year or two. This timeline extension is influenced by various factors, such as technology coverage and security considerations. Consequently, there may still be limited instances of OTel implementation in large organizations or financial institutions.
OTel remains in an active development phase, with several factors influencing its future success:
* **Technology Coverage**: OTel's current support for different technologies and frameworks continues to evolve. While it caters to numerous popular languages and platforms, incomplete coverage could impede its adoption in specific settings.
* **Stability and Maturity**: As a relatively new technology, OTel must establish a robust track record of stability and maturity to foster broad trust and acceptance. Early adopters might encounter challenges related to bugs or functional limitations.
* **Ease of Integration**: The implementation of OTel should be seamless and demand minimal developer effort. Complex integration procedures or inadequate documentation can deter adoption and impede its advancement.
* **Performance Overhead**: Integrating tracing and log instrumentation may introduce performance overhead to applications. OTel must undergo optimization to minimize its impact on system performance and ensure smooth operation.
## 2. OpenTelemetry Coverage is not Enough
The success and relevance of OTel will be greatly influenced by the range of programming languages and protocols it accommodates.
Programming Languages: Diverse programming language support is crucial for generating trace data effectively. With broader language support, OTel becomes more accessible to developers working across different ecosystems. Currently, OTel is compatible with 11 programming languages. However, it's important to acknowledge that this coverage may not encompass all widely-used languages like C or mobile app development languages such as React Native. In such instances, developers may need to resort to vendor-specific libraries or frameworks to enhance tracing and observability capabilities.
The level of support for each language can vary, and it's advisable to consult the official OTel documentation for the latest information on language compatibility. The OTel community is actively expanding language support and enhancing existing integrations.
Protocols: OTel facilitates comprehensive observability by supporting a diverse array of protocols for data capture within an application's environment. Some key protocols include:
* HTTP: A fundamental protocol for web communication, crucial for tracing requests and responses in applications.
* gRPC: A high-performance RPC framework extensively utilized in microservice architectures. OTel offers tracing capabilities for gRPC communication.
* Kafka: A widely-used distributed streaming platform enabling efficient trace data capture and processing across various services.
* AMQP: Another prevalent messaging protocol for inter-process communication. OTel supports tracing for AMQP messages, ensuring end-to-end visibility into data flow.
For a more detailed understanding of OTel's language and protocol support, it's recommended to refer to the official documentation for the latest updates and advancements in integration. The OTel community is dedicated to broadening language compatibility and enhancing integration functionalities.
## 3. Legacy systems doesn’t support OpenTelemetry
It is true that many legacy systems still directly use TCP/IP and UDP on the server side, while REST is widely used for communication between clients and servers. In the IoT environment, MQTT has gained popularity as a lightweight open protocol, while AMQP is a full-function open protocol commonly used in data centers.
However, when it comes to protocol support, OTel currently has limitations. While it does support REST and AMQP, as well as some proprietary protocols like Solace’s SMF (Solace Message Format) through specific SDKs or libraries, there are gaps in terms of protocol coverage.
OTel’s protocol support is evolving, and the community is actively working with the corresponding protocol community to expand the range of supported protocols. As the project continues to mature, it is expected that support for additional protocols will be added in the future. This will enable OTel to cater to a wider variety of systems and communication patterns, including those using TCP/IP, UDP, MQTT, and other protocols commonly used in various environments.
## 🚀 Let's Connect Beyond GitBook!
If you found this article helpful, you can find more of my technical insights, daily discussions, and deep dives across these platforms:
* **Read more of my work:** Check out my articles on [dev.to](https://dev.to/stephen_tsoi_5b2c4055f3a9) and [Hashnode](https://stephentsoi.hashnode.dev/).
* **Join the daily conversation:** Connect with me directly on [LinkedIn](https://www.linkedin.com/in/stephen-tsoi-16309730/).
***
#### 📬 Stay Ahead of the Curve
Enjoyed this piece? I break down complex technical topics into bite-sized, actionable insights every week.
👉 **Subscribe to my** [**LinkedIn Newsletter**](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7487299517642612736) to never miss an update and get the latest articles delivered straight to your feed!
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/opentelemetry/from-missing-events-to-complete-visibility-tracing-enterprise-transactions-with-opentelemetry/day-14-34-the-challenge-of-opentelemetry.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
