文章讨论了 OpenTelemetry (OTel) 在可观察性方面面临的挑战和局限性。
OpenTelemetry 是一个开源项目，旨在对不同可观察性后端之间遥测数据（度量、日志和跟踪）的收集和传输进行标准化。
虽然 OTel 已被广泛采用，但作者认为它在以下几个方面存在不足：
- 复杂性：OTel 的配置非常复杂，需要花费大量精力才能正确设置。
- 性能开销： 额外的仪器会影响应用性能。
- 数据质量问题： OTel 试图实现通用性可能会导致不同后端数据质量不一致
作者建议，对于许多组织而言，更有针对性、更有目的性的可观察性方法可能更有效，而不是依赖像 OTel 这样的通用标准。
文章额承认 OTel 在供应商中立性和可移植性方面的优势，但质疑这些优势是否能弥补大多数用户的缺点。
文章最后建议，尽管 OTel 有其一席之地，但组织在完全投入 OpenTelemetry 生态系统之前，应该仔细考虑自己的具体需求和所涉及的权衡。
摘要：
我经常抱怨 OpenTelemetry，所以为了成为一个不那么无用的代码贡献者，今天我决定动笔写下这篇文章。如果你是一名实施者，我请你阅读这篇文章，消除你对工作的个人偏见，客观地看待给出的反馈。
我创建了 Sentry。出于显而易见的原因，Sentry 在这场“测量你的应用程序”竞赛中占有一席之地。
2015 年，Armin和我制定了分布式跟踪规范。这不是一个难题，只是需要大量的协调和努力。它的核心是带有两个 GUID 的结构化事件：跟踪 ID 和父事件 ID。这只是构建一棵树。更难的部分是将这些注释稳定在无限增长的应用程序、库和各种服务的生态系统中。
在我们制定规范的同时，Lightstep 的人们开始着手制定规范。他们建立了一个名为 OpenTracing 的开放规范。据我所知，目标是创建一种标准的仪表方法，使供应商和客户避免重写仪表。
在此过程中，OpenTracing 变成了 OpenTelemetry，并与 OpenCensus 合并。我对这个决定是如何做出的，或者假设的目标是什么，不太感兴趣，但我关心开放跟踪标准最初目标的结果。
你看，在某个时候，OpenTelemetry 成为了一个超越跟踪目标的更广泛的规范。它试图为跨度注释、日志和指标的通用传输以及谁知道未来还会有什么构建规范和 SDK。
我个人认为——不是 Sentry 的观点——它已经迷失了方向，是委员会设计失败的典型例子。这是缺乏远见和缺乏领导力的一个例子。