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.
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.