OTel Isn’t Going Well (And I Made A Spreadsheet About It)

OTel 进展不顺（我为此做了一张电子表格）

For years now one of the most reliable complaints I hear when I try to drag a team off their vendor specific SDK and onto OpenTelemetry is some variation of: “why does it seem like this isn’t done yet?” 多年来，当我试图说服团队放弃特定供应商的 SDK 转而使用 OpenTelemetry 时，我听到最常见的抱怨总是大同小异：“为什么感觉这东西还没做完？”

Vendor SDKs for observability are, to put it charitably, idiot-proof. You install the thing, dashboards just load data, someone else worries about how all those pieces fit together, and you get on with your life. OpenTelemetry, by contrast, greets you at the door with a lot of “experimental” stamps and roughly six different ways to accomplish any given task. 客气地说，可观测性领域的供应商 SDK 是“傻瓜式”的。你安装好它，仪表板就会自动加载数据，其他人会负责处理所有组件如何协同工作，而你只需继续你的工作。相比之下，OpenTelemetry 迎接你的却是大量的“实验性”标签，以及完成同一任务的大约六种不同方法。

In OpenTelemetry’s defense this was never what they were going for as a project. I’ve always respect that they stuck to their guns by attempting to build a truly vendor agnostic system that really doesn’t care what you do with the data. I have never gotten a sense of a vendor being strongly preferred with OTel, which is quite the feat considering how lucrative and contentious the observability ecosystem was. Also considering that the maintainers of this project are largely employed by exclusively those companies. 为 OpenTelemetry 辩护一下，这从来不是该项目的初衷。我一直很敬佩他们坚持初心，试图构建一个真正与供应商无关的系统，完全不在乎你如何处理数据。在使用 OTel 时，我从未感觉到有哪个供应商被特别偏袒，考虑到可观测性生态系统是多么有利可图且充满争议，这确实是一项了不起的成就。更何况，该项目的维护者大多受雇于这些竞争激烈的公司。

As the years wore on, I started to get nervous. Conversations in the semantic-conventions repo drag on and on and on. Different languages had dramatically different stories. Golang and Dotnet were first class citizens, but other languages lagged years behind the others. I started asking a lot of probing questions before recommending OpenTelemetry to smaller teams who didn’t have the time, budget, or emotional bandwidth for it. Auto-instrumentation was genuinely magical, but the cliff between “auto-instrument works” and “now I have to manually instrument something” was steep enough that you owed people a warning before you pushed them off it. 随着时间的推移，我开始感到不安。语义约定（semantic-conventions）仓库中的讨论没完没了。不同语言的进展情况大相径庭。Golang 和 Dotnet 是“一等公民”，但其他语言却落后了几年。在向那些没有时间、预算或精力去折腾的小型团队推荐 OpenTelemetry 之前，我开始提出许多尖锐的问题。自动埋点确实非常神奇，但从“自动埋点能用”到“现在我必须手动埋点”之间的落差非常大，在把别人推向这个深坑之前，你有义务提醒他们。

This narrative has been going on for awhile in the observability space, a vague sense of “something is wrong in Otel-land”. But let’s try to generate some actual data here. Is there an actual problem, or is this something where the perception by the community of slow progress is imaginary? Is the problem not enough maintainers, too big of a scope, or something in-between? 这种说法在可观测性领域已经流传了一段时间，大家隐约觉得“Otel 那边出问题了”。但让我们尝试生成一些实际数据来看看。是真的有问题，还是社区对进展缓慢的感知只是错觉？问题是维护者不足、范围太大，还是介于两者之间？

My guess when I started was “oh this is your classic open-source bit off more than they can chew”. Not enough maintainers, not enough budget. Now there is some of that, but there’s also something else going on. The actual problem happening inside of OpenTelemetry is a three way crash. You have a binary stability gate which, when combined with a very small bench of actual maintainers means there is understandable worry about marking a feature not experimental then add on just a massive scope of languages and frameworks they are attempting to cover. This creates a perfect storm where there is an incentive to argue about potential problems a feature might create since once it is locked in and shipped as stable you can never change them. 我刚开始猜测是“典型的开源项目贪多嚼不烂”。维护者不够，预算不足。现在看来确实有这方面原因，但还有其他因素。OpenTelemetry 内部真正的问题是一场“三方碰撞”。你有一个二元的稳定性门槛，再加上极少数的实际维护者，这导致人们在将功能标记为“非实验性”时会有合理的担忧；再加上他们试图覆盖的语言和框架范围极其庞大。这创造了一场完美的风暴：人们有动力去争论一个功能可能带来的潜在问题，因为一旦它被锁定并作为稳定版发布，你就永远无法更改它了。

How does OpenTelemetry Work

OpenTelemetry 是如何工作的

So OpenTelemetry currently is attempting to support a dizzying number of languages and frameworks. OpenTelemetry is a giant project. It spans dozens of languages, hundreds of libraries, and countless backends. To keep things sane, the project splits work into two buckets: 目前，OpenTelemetry 试图支持令人眼花缭乱的语言和框架。OpenTelemetry 是一个庞大的项目，跨越了几十种语言、数百个库和无数的后端。为了保持项目可控，它将工作分为两类：

• Core → Maintained directly by the OTel project. Small, stable, vendor-neutral, and tightly reviewed. This is the “spec-defining” surface.

• Core → 由 OTel 项目直接维护。小巧、稳定、供应商中立，且经过严格审查。这是“定义规范”的核心层面。

• Contrib → Community- and vendor-contributed. Broader, faster-moving, and covers the long tail of integrations.

• Contrib → 由社区和供应商贡献。范围更广、迭代更快，涵盖了长尾的集成需求。

There exists the otel-collector, the thing that runs along the thing so that you can ship logs metrics and traces. That copies the same rough pattern. But for the languages when we’re talking about core vs contrib this is what we’re talking about. 存在一个 otel-collector，它是与应用程序一起运行的组件，用于传输日志、指标和追踪数据。它遵循大致相同的模式。但当我们谈论语言层面的 core 与 contrib 时，我们指的是：

• opentelemetry-python (core): The API, SDK, OTLP exporter, context propagation, resource detection primitives.

• opentelemetry-python (core)：API、SDK、OTLP 导出器、上下文传播、资源检测原语。

• opentelemetry-python-contrib: Instrumentation libraries for Flask, Django, requests, psycopg2, Redis, Kafka, boto3, etc. Stuff that breaks goes in contrib, stuff that doesn’t break goes into core.

• opentelemetry-python-contrib：针对 Flask、Django、requests、psycopg2、Redis、Kafka、boto3 等的埋点库。容易出问题的放在 contrib，稳定的放在 core。

Now the reason this causes a conflict. contrib is massive overkill for most projects. You don’t want 300 exporters to add the one you typically need. On the language side, this isn’t that big of a problem. pip install opentelemetry-instrumentation-flask gives you the stuff you need for flask. However on the collector side you end up having to do the OpenTelemetry Collector Builder to make your own collector (or just kinda ride the wave and hope it works out). While cool that this exists, it’s a lot of scope to ask a team to take on. 这就是冲突的来源。对于大多数项目来说，contrib 的规模过于庞大。你不需要 300 个导出器，只需要你常用的那一个。在语言层面，这问题不大。pip install opentelemetry-instrumentation-flask 就能给你提供 Flask 所需的一切。然而在 collector 层面，你最终不得不使用 OpenTelemetry Collector Builder 来构建你自己的 collector（或者只能随波逐流，祈祷它能正常工作）。虽然这个工具很酷，但要求一个团队去承担这么大的工作量确实有些过分。

Process of adding a new feature

添加新功能的流程

So I believe I have captured the workflow of adding a new feature to OTel. You can check my homework here: OpenTelemetry Enhancement Proposal (OTEP). 我相信我已经梳理出了向 OTel 添加新功能的流程。你可以查看我的作业：OpenTelemetry 增强提案 (OTEP)。

Once the OTEP is accepted, the text goes into the Specification directory in the same repo. After that it seems to go to Semantic conventions. This seems to be where we get down to the specific details and where most of the long discussions seem to live. At this point we’re talking about more or less a permanent commitment to this design and where the lock-in process becomes very hard to change. 一旦 OTEP 被接受，文本就会进入同一仓库的 Specification 目录。之后似乎会进入“语义约定”阶段。这似乎是我们深入具体细节的地方，也是大多数漫长讨论发生的地方。到了这一步，我们基本上是对该设计做出了永久性的承诺，锁定过程也变得难以更改。

Each of the SDKs implements the API surface that is defined in the specification. Now some of the SDKs have done 2.0 breaking changes, so it does seem like the earlier “please no 2.0 at all costs” sentiment has been abandoned (which I think is smart and good). 每个 SDK 都会实现规范中定义的 API 接口。现在一些 SDK 已经进行了 2.0 的破坏性更新，所以早先那种“不惜一切代价避免 2.0”的情绪似乎已经被放弃了（我认为这是明智且正确的）。

• Contrib / instrumentation: This is slightly more mushy. Looks like they should track latest API/SDK but each contrib package may version independently so its more flexible as a design.

• Contrib / instrumentation：这部分稍微模糊一些。看起来它们应该追踪最新的 API/SDK，但每个 contrib 包可以独立版本化，因此设计上更灵活。

• Collector + OTLP: The data has to actually go somewhere. OTLP (wire protocol) has its own stability lifecycle and specification. Collector components have their own stability in their READMEs and as far as I can tell that’s kinda all over the place.

• Collector + OTLP：数据最终必须传输到某个地方。OTLP（传输协议）有其自己的稳定性生命周期和规范。Collector 组件在各自的 README 中有自己的稳定性说明，据我观察，这方面显得有些混乱。

Things I’m not really clear on

我不太清楚的地方

It’s unclear how long the OTEP -> Specification process takes. I’ve looked through the Git history but there doesn’t seem… 目前还不清楚从 OTEP 到 Specification 的流程需要多长时间。我查阅了 Git 历史记录，但似乎……