文章指出OpenTelemetry（OTel）项目进展缓慢，存在大量“实验性”标记、多种实现方式导致混乱，以及语义约定讨论拖延等问题，与即装即用的厂商SDK形成鲜明对比。

好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了核心细节，并删减了与主题无关的冗余内容。

标题：OpenTelemetry 进展不顺（我为此做了个表格）

多年来，当我试图让团队从厂商特定的 SDK 迁移到 OpenTelemetry（OTel）时，最常听到的抱怨是：“为什么它看起来还没准备好？”

厂商的监控 SDK 通常简单易用，安装后仪表盘就能加载数据，无需操心集成细节。而 OTel 则相反，一上来就带着大量“实验性”标签，并且完成同一任务有大约六种不同方式。

平心而论，OTel 项目的初衷并非如此。我始终敬佩他们坚持构建一个真正厂商无关的系统，不关心你如何处理数据。考虑到监控生态系统的盈利性和竞争性，OTel 能做到不偏袒任何厂商，这很了不起。然而，随着时间推移，我开始感到担忧。语义约定仓库里的讨论没完没了，不同语言的支持程度也天差地别。Go 和 .NET 是一等公民，但其他语言落后了好几年。

在向没有时间、预算或精力折腾的小团队推荐 OTel 前，我会问很多问题。自动埋点确实神奇，但从“自动埋点可用”到“必须手动埋点”之间的落差太大，需要提前警告用户。

这种“OTel 领域出了问题”的模糊感觉在监控领域已经持续了一段时间。让我们尝试用数据来验证：问题到底出在哪里？是社区对进展缓慢的感知是错觉，还是真的存在维护者不足、范围过大等问题？

我最初的猜测是“经典的开源项目贪多嚼不烂”，即维护者和预算不足。但深入分析后，我发现还有别的问题。OTel 内部存在一个三重困境：一个二进制稳定性门禁，加上极少的实际维护者，导致大家对标记一个功能为“稳定”非常谨慎；同时，项目试图覆盖的语言和框架范围又极其庞大。这造成了一个完美风暴：由于功能一旦锁定并发布为稳定版就永远无法更改，人们有动力去争论潜在问题。

OpenTelemetry 如何运作

OTel 是一个庞大的项目，涵盖数十种语言、数百个库和无数后端。为了保持条理，项目将工作分为两部分：

• 核心：由 OTel 项目直接维护，小巧、稳定、厂商中立，审查严格。这是“定义规范”的部分。
• 贡献：由社区和厂商贡献，范围更广、迭代更快，覆盖长尾集成。

例如，opentelemetry-python 是核心，包含 API、SDK、导出器等；而 opentelemetry-python-contrib 则包含 Flask、Django 等库的埋点库。出问题的代码放在贡献部分，稳定的放在核心部分。

这种划分导致了冲突。对于大多数项目来说，贡献部分过于庞大。在语言层面，这问题不大（pip install 即可），但在收集器层面，用户需要使用 OpenTelemetry Collector Builder 来构建自己的收集器，这对团队来说要求过高。

添加新功能的流程

添加新功能的流程大致如下：

1. 提交 OpenTelemetry 增强提案 (OTEP)。
2. OTEP 被接受后，内容进入规范目录。
3. 之后进入语义约定阶段，讨论具体细节。这似乎是大多数冗长讨论发生的地方，因为此时几乎是对设计的永久承诺，很难更改。
4. 各个 SDK 实现规范中定义的 API 接口。一些 SDK 已经做了 2.0 的破坏性变更，表明早期“不惜一切代价避免 2.0”的想法已被放弃。
5. 贡献/埋点部分。这部分更灵活，每个贡献包可以独立版本化。
6. 收集器 + OTLP。数据最终需要发送到某个地方。OTLP（线路协议）有自己的稳定性生命周期，收集器组件的稳定性则比较混乱。

我不太清楚的地方：OTEP 到规范的流程需要多长时间？收集器 + OTLP 组是否同步工作？如果某种语言落后太多，是否会被“淘汰”？

尝试测试

我将 OTel 与其他 CNCF 项目（Envoy 和 Prometheus）进行了比较，使用一个 Python 脚本测量开源项目的“健康度”。

数据显示，Envoy 是一个相当健康的项目，作者、合并者、问题关闭者分布良好。而 OTel 的 PHP 和 Ruby SDK 则明显不健康，工作过度集中在少数人身上。相比之下，Go 和 .NET SDK 看起来更健康。

第一个问题并不令人意外：维护者太少，工作过于集中。作者不应该同时是合并者和问题关闭者，这些任务应该更均匀地分配。

我认为维护者已经尽力保持讨论公开。问题更多是经典的“必须有人付钱给维护者”。这个项目太复杂，无法作为爱好来维护。任何承诺如此长期稳定性的项目都不能指望业余爱好者的帮助。但这也意味着，从事这项关键工作的人会受到其所属组织的期望约束。

数据显示，多个 OTel SDK 的合并工作高度集中在个别人手中，而 Prometheus 和 Envoy 则拥有更广泛的维护者基础。

语义约定

如果厂商争论是导致进展缓慢的原因，那么我们应该在语义约定仓库中看到 PR 的延迟。但事实并非如此。语义约定中一些最慢的 PR 涉及复杂主题，但这种延迟并没有明显传导到 SDK/API 层面，说明 OTel 在隔离这些讨论方面做得不错。

Python SDK 中最慢的 PR 与语义约定无关，其延迟主要源于“批准公共 API 检查”所需的额外审查，这又回到了“维护者不足”的初始问题。

潜在解决方案

模式很清晰：新功能需要很长时间才能到达最终用户，因为 OTel 非常重视稳定性，同时维护者人才库有限。一旦功能通过整个流程，实现 API 并将其交付给用户的重担就落在了过度劳累的维护者身上。

一个值得探索的想法是增加一个有时间限制的“Beta”层级，介于“实验性”和“稳定版”之间。目前，实验性功能对 99% 的用户来说形同虚设。但如果我知道某个功能至少会保留 12 个月，并且更容易使用，那么它就能帮助项目获得更多有价值的反馈。

具体来说，一个功能可以走：实验性（使用率低）-> Beta（比实验性更面向用户）-> 12个月 -> 移除或稳定。

目前 OTel 中“Beta”这个概念存在且令人困惑，它似乎只用于 SDK，而不用于组件。例如，Rust 是 Beta，但 Profiles 不能是 Beta。这需要澄清。

此外，声称 Go 和 Ruby 的维护标准相同是具有误导性的。承认维护层级的存在，让人们做出明智的选择，并可能通过公开问题来吸引更多帮助。

最后，OTel 应该更公开地提出“我们需要更多维护者”的问题。做这项工作的人可能知道问题所在，但整个社区似乎并不清楚对更多（最好是独立的）维护者和贡献者的迫切需求。

OpenTelemetry 是一个伟大的项目，正在做着伟大的工作。但为了真正取代厂商特定的 SDK，我们需要在稳定性承诺和语言数量方面更加务实。只要沟通得当，破坏性变更对社区的破坏力可能没有这些承诺所暗示的那么大。在如此单薄的维护者基础上，必须有所取舍。

根据评论内容，总结主要观点如下：

支持观点（认可度中等）： - 开放标准避免厂商锁定，OTLP源与第三方接收器兼容性强（评论3："anyone can write an OTLP source... it'll just work with dozens of third-party sinks"） - 可自行实现缺失功能（评论8："I was able to implement them myself"）

批评观点（认可度较高）： - 性能开销大，需双倍计算资源（评论4："performance hit is substantial... need twice as much compute/RAM"） - 设计过度工程化，代码混乱（评论5："badly designed abstraction... code gets very very messy"） - 厂商支持仍处alpha/beta阶段（评论4："every major vendor is still in some weird alpha/beta support"） - 采样决策机制僵化（评论8："sampling decision is made at the start of the segment"） - 自动检测对复杂应用无效（评论11："full auto instrumentation breaks most non-trivial apps"）

中立观点： - 类似K8s，是构建框架的框架（评论9："it's a framework to build a framework on top of"） - 追踪、指标、日志独立设计不合理（评论6："tracing, metrics and logs are all designed independently"） - 对分布式长时函数支持不足（评论10："breaks down when your functions are distributed"）

建议： - 避免完全锁定OTel（评论12："make sure you don't lock yourself into OTel"） - 考虑更轻量替代方案如Prometheus（评论12："just going with Prometheus... works better"）