Very unfortunate that this article is written by an LLM. Reading over, the premise and the conclusion are what a chat session filled with RAG and MCP calls would bring about. Disapointed in the OTel leadership, the blog is usually a nice place to read about what is happening with the community.
Nothing less than that was expected if one knows anything about OTel project. This is Enterprise FizzBuzz observability. It is perfect template for AI to generate endless docs and code.
OTel-native sounds great in theory, but every vendor still finds a way to pull you into their proprietary query dialect or storage tax once you hit scale at production.
> but every vendor still finds a way to pull you into their proprietary query dialect
We just finished adding support for OTel in our own product, and from the "vendor" side, I think there are two reasons for this.
The most important one is that query performance is tightly-coupled with the storage engine. While being OTel-compatible does limit vendors to follow certain specific storage/representation implementation choices, on the query side each vendor can (should?) use the query language/approach that fits best their own storage engine in terms of performance. After all, OTel standardizes the data transfer + wire model, not storage/query.
The second one is hidden within the blog post:
> Support for Semantic Conventions: Adherence to the Semantic Conventions ensures that telemetry data remains standardized and is easily interpretable by any compatible backend. It also reduces the cognitive burden on the end-user to reason about how the software system works, be it a first-party or third-party system.
Conventions are just conventions :)
We are long way to go towards making OTel's conventions the established norm across projects that provide their own OTel signals. Take for example HAProxy + Traefik. Each one has variable support for OTel data and require you to go through different hoops to set them up properly. On the receiving end you have to separately normalize the data of each one, in order to be able to provide a nice experience for a user who might be interested in finding, eg. all access logs for everything serving http.
I have been working observability world more than 10 years and what I can say is that OTEL is one of the biggest step in this space even though different vendors have their own things.
Very unfortunate that this article is written by an LLM. Reading over, the premise and the conclusion are what a chat session filled with RAG and MCP calls would bring about. Disapointed in the OTel leadership, the blog is usually a nice place to read about what is happening with the community.
Nothing less than that was expected if one knows anything about OTel project. This is Enterprise FizzBuzz observability. It is perfect template for AI to generate endless docs and code.
What alternative would you choose for this kind of observability?
Pangram indeed marks the first 100 words as 100% AI
OTel-native sounds great in theory, but every vendor still finds a way to pull you into their proprietary query dialect or storage tax once you hit scale at production.
> but every vendor still finds a way to pull you into their proprietary query dialect
We just finished adding support for OTel in our own product, and from the "vendor" side, I think there are two reasons for this.
The most important one is that query performance is tightly-coupled with the storage engine. While being OTel-compatible does limit vendors to follow certain specific storage/representation implementation choices, on the query side each vendor can (should?) use the query language/approach that fits best their own storage engine in terms of performance. After all, OTel standardizes the data transfer + wire model, not storage/query.
The second one is hidden within the blog post:
> Support for Semantic Conventions: Adherence to the Semantic Conventions ensures that telemetry data remains standardized and is easily interpretable by any compatible backend. It also reduces the cognitive burden on the end-user to reason about how the software system works, be it a first-party or third-party system.
Conventions are just conventions :)
We are long way to go towards making OTel's conventions the established norm across projects that provide their own OTel signals. Take for example HAProxy + Traefik. Each one has variable support for OTel data and require you to go through different hoops to set them up properly. On the receiving end you have to separately normalize the data of each one, in order to be able to provide a nice experience for a user who might be interested in finding, eg. all access logs for everything serving http.
Yeah also different vendors have different limitations.
I have been working observability world more than 10 years and what I can say is that OTEL is one of the biggest step in this space even though different vendors have their own things.
Genius! “level, timestamp, message”
I wish the format wasn't so ass, it's so wasteful and annoying to modify
Fake engagement... LOL