OTel发展不佳（我为此制作了一个电子表格）

# OTel 发展不顺（为此我做了一个电子表格） 来源：https://matduggan.com/otel-isnt-going-well-and-i-made-a-spreadsheet-about-it/ 多年来，当我试图将团队从供应商特定的SDK迁移到OpenTelemetry时，最常听到的抱怨总是类似这样： *“为什么感觉这东西好像还没完成？”* 供应商提供的可观测性SDK，说得好听点，是**傻瓜式**的。你只需安装它，仪表盘就会自动加载数据，其他所有组件如何协同工作都有人操心，你只需过好自己的生活。而OpenTelemetry，相比之下，在你入门时就给了你一堆“实验性”标签，以及大约六种完成任何特定任务的方式。 为OpenTelemetry辩护一下，这从来不是该项目的初衷。我一直很尊重他们坚持尝试构建一个*真正*与供应商无关、完全不关心你如何使用数据的系统。在OTel项目中，我从未感觉到某个供应商被强烈偏好，考虑到可观测性生态系统曾经如此利润丰厚且竞争激烈，这是一项相当了不起的成就。尤其考虑到这个项目的维护者大多受雇于这些公司。 随着时间的推移，我开始感到担忧。语义约定仓库中的讨论无休止地拖延。不同语言的实现有着天壤之别。Golang和Dotnet是一等公民，而其他语言则落后数年。 在向那些没有时间、预算或心理承受能力的小团队推荐OpenTelemetry之前，我开始提出很多深入的问题。自动检测确实很神奇，但“自动检测能用”和“现在我需要手动检测某些东西”之间的鸿沟如此之陡，以至于在把他们推下去之前，你必须先给出警告。 在可观测性领域，这种叙事已经存在一段时间了，一种模糊的感觉是“OTel世界出了点问题”。但让我们试着生成一些实际的数据。是真的有问题，还是社区对缓慢进展的感知是想象出来的？问题是维护者不足、范围过大，还是介于两者之间？ 我一开始的猜测是“哦，这是经典的开源项目摊子铺得太大的情况”。维护者不足，预算不够。现在确实存在这些情况，但还有别的问题。 OpenTelemetry内部实际发生的问题是三方面的冲突。存在一个二进制稳定性门槛，再加上实际维护者队伍非常小，这意味着对于将某个功能标记为非实验性然后投入使用的做法存在可理解的担忧，而他们试图覆盖的语言和框架范围又*极其庞大*。这创造了一场完美风暴：人们有动机去争论某个功能可能引发的潜在问题，因为一旦功能锁定并作为稳定版发布，就永远无法更改了。 ### OpenTelemetry 如何运作 因此，OpenTelemetry目前正试图支持数量惊人的语言和框架。 OpenTelemetry是一个*庞大*的项目。它跨越数十种语言、数百个库和无数个后端。为了保持条理性，项目将工作分为两个部分： - **核心** → 由OTel项目直接维护。小巧、稳定、供应商中立，并经过严格审查。这是“定义规范”的层面。 - **贡献** → 由社区和供应商贡献。范围更广、迭代更快，覆盖了长尾的集成。 存在otel-collector，它可以与你的应用并行运行，用于传输日志、指标和追踪数据。它也遵循类似的大致模式。但对于语言部分，当我们谈论核心与贡献时，我们指的是： `opentelemetry-python`（核心）API、SDK、OTLP导出器、上下文传播、资源检测原语。 `opentelemetry-python-contrib`用于Flask、Django、requests、psycopg2、Redis、Kafka、boto3等的检测库。 会出问题的东西放在contrib里，不会出问题的东西放在核心里。 现在，问题在于这种模式导致的冲突。对于大多数项目来说，`contrib`都大得离谱。你不需要300个导出器，只需要添加你通常需要的那一个。在语言方面，这还不是大问题。`pip install opentelemetry-instrumentation-flask`就能给你Flask所需的东西。然而在*采集器*方面，你最终不得不使用OpenTelemetry Collector Builder来构建自己的采集器（或者只能随波逐流，希望它能正常工作）。虽然这个东西存在很酷，但要求团队承担这么多范围是很困难的。 ### 添加新功能的流程 因此，我*相信*我总结了向OTel添加新功能的流程。你可以在https://github.com/open-telemetry/opentelemetry-specification/tree/main/oteps/检查我的“作业”： 1. OpenTelemetry增强提案（OTEP）(https://github.com/open-telemetry/opentelemetry-specification/tree/main/oteps/) 2. OTEP被接受后，文本进入同一仓库的规范目录。 3. 之后似乎进入语义约定阶段。这似乎是我们落实具体细节的地方，也是大多数长篇讨论的所在地。此时，我们谈论的或多或少是对这种设计的永久承诺，锁定过程变得极难更改。 4. 各个SDK实现规范中定义的API接口。现在一些SDK已经做了2.0版本的破坏性变更，所以早期“不惜一切代价避免2.0版本”的想法似乎已被放弃（我认为这很明智且有益）。 5. 贡献/检测库。这部分稍微模糊一些。它们应该跟踪最新的API/SDK，但每个贡献包可能独立版本管理，因此在设计上更灵活。 6. 采集器 + OTLP。数据需要实际传输到某个地方。OTLP（线缆协议）有自己的稳定性生命周期和规范（此处(https://opentelemetry.io/docs/specs/otlp/)）。采集器组件在它们的README中有自己的稳定性说明，据我所知，这些说明相当混乱。 **我不太清楚的事情** - OTEP → 规范过程需要多长时间，尚不清楚。我查看了Git历史记录，但似乎没有可预测的时间或周期。 - 我没有完全理解这些稳定性承诺之间的关系。采集器 + OTLP组是同步工作吗？如果某个语言落后太多，会“超出范围”吗？ ### 尝试测试它 因为OpenTelemetry是CNCF项目，我认为将其与其他CNCF项目进行比较最为合理。我的比较基准是Envoy和Prometheus。我使用了一个以前用过的、有点简陋的Python脚本来衡量开源项目的“健康状况”，这可能不是最好的方法。不过，我会提供原始数据的链接（没有图表），以便大家查看并（很有可能）找出我生成结果中的问题。 我们来看Envoy在24个月内的活动，它是一个相当健康的项目。作者、合并者、问题关闭者的分布都很均衡。`phlax`显然对项目很重要，但总的来说，有足够的人员储备，必要时可以接手。我已尝试过滤掉所有已知的机器人流量。 让我们将它与OpenTelemetry的一个语言项目进行比较。我最有专业经验的是Golang和Python，但我从社区里很多人那里听说Ruby和PHP的实现很吃力。这是PHP在相同时间段的情况。 我们非常清楚地看到，活动过度集中在2个人身上。这不是一个健康的开源项目，他们显然没有足够的人来覆盖OTel需要覆盖的范围。Ruby的情况也类似。 相比之下，在我看来“最强”的OpenTelemetry SDK——Golang和Dotnet（尽管Python也不弱）——看起来更健康。 Golang 所以第一个问题也许是最不奇怪的。维护者太少，责任过于集中。你的作者不应该同时也是你的合并者和问题关闭者。理想情况下，这些任务应该更均匀地分配。 话虽如此，我认为维护者们在尝试保持讨论公开性方面做得很好。我很容易找到不同维护者小组的公开会议记录，通读它们并了解进展。我的感觉是，这些维护者并非试图*阻止*人们参与，而是对稳定性的期望在某种程度上使项目停滞不前了。 问题更是一个经典的“必须有人支付维护者报酬”的案例。这个项目太复杂了，有人想把它当作爱好来做是不现实的。我认为任何签署了如此长期稳定性承诺的项目，都不能指望业余爱好者社区提供帮助。我无法免费加入电话会议，并为如此重要和规模庞大的项目做那些预期的事情。但这也意味着，从事这项关键工作的人面临着他们所属组织的期望。 | 仓库 | 24个月合并的PR数 | 独立合并者数 | 第1名合并者占比 | 顶级合并者角色 | | :--- | :--- | :--- | :--- | :--- | | `opentelemetry-cpp` | 544 | 4 | **86.1%** | 单人（`marcalff`） | | `opentelemetry-kotlin` | 281 | 2 | **79.7%** | 单人（`fractalwrench`） | | `opentelemetry-browser` | 102 | 4 | **79.5%** | 单人 | | `opentelemetry-ruby` | 213 | 5 | **78.7%** | 单人 | | `opentelemetry-js` | 829 | 14 | **64.9%** | 高度集中 | | `opentelemetry-python` | 486 | 4 | **61.4%** | 单人（`xrmx`） | | `opentelemetry-php` | 181 | 2 | **53.0%** | 总共仅2名合并者 | | `semantic-conventions` | 911 | 9 | **49.7%** | 单人（`lmolkova`） | | `opentelemetry-go` | 686 | 5 | 36.9% | 分布式团队 | | `opentelemetry-dotnet` | 657 | 6 | 31.5% | 分布式团队 | | **`prometheus`** | **1,849** | **31** | **14.4%** | **广泛团队** | | **`envoy`** | **5,432** | **28** | **35.8%** | **广泛团队** | 所以这些SDK的维护者太少了。但这并不能完全解释为什么新功能似乎需要如此之长的时间才能贯穿整个技术栈。我对此的猜测是，在新想法提交和正式化之间的某个环节，存在长达百万年的漫长讨论。 ### 关于语义的约定 因此，在如此跨框架和语言的广泛范围内，在一个地方集中讨论约定是有意义的。这个地方在：https://github.com/open-telemetry/semantic-conventions 如果供应商争论导致了延迟，我们（理论上）应该在`semconv`的PR中看到这种延迟。然后这种延迟应该会向外扩散。剧透：我错了。非常感谢OpenTelemetry的人们在标记PR方面有良好的约定，这让分析变得容易多了。 所以如果`semconv`是瓶颈，让我们看看那里最慢的PR。 | PR | 天数 | 评论数 | 审查数 | 标签 | 主题 | | :--- | :--- | :--- | :--- | :--- | :--- | | [#2083](https://github.com/open-telemetry/semantic-conventions/pull/2083) | 277.5 | 17 | **115** | area:gen-ai | MCP 语义约定 | | [#2617](https://github.com/open-telemetry/semantic-conventions/pull/2617) | 258.6 | 29 | 13 | area:gcp | GCE 实例标签 | | [#1698](https://github.com/open-telemetry/semantic-conventions/pull/1698) | 187.9 | 37 | area:azure, **breaking** | 重命名 `azure_` → `azure.` | | [#2619](https://github.com/open-telemetry/semantic-conventions/pull/2619) | 174.6 | 24 | 8 | area:gcp | GCE 实例组管理器 | | [#3118](https://github.com/open-telemetry/semantic-conventions/pull/3118) | 147.1 | 19 | 8 | area:graphql, **breaking** | GraphQL 推荐 vs 可选 | | [#1741](https://github.com/open-telemetry/semantic-conventions/pull/1741) | 141.0 | 42 | 3 | changelog.opentelemetry.io | 大型机 | | [#1784](https://github.com/open-telemetry/semantic-conventions/pull/1784) | 127.3 | 74 | 8 | area:k8s | k8s.container.status 指标 | | [#2287](https://github.com/open-telemetry/semantic-conventions/pull/2287) | 118.5 | 12 | **95** | area:rpc | ONC/Sun RPC + NFS 指标 | | [#2179](https://github.com/open-telemetry/semantic-conventions/pull/2179) | 117.0 | 7 | **114** | area:gen-ai, **breaking** | Gen-AI 聊天历史记录属性 | 是的，有些PR进展相当缓慢，但讨论的主题确实复杂。然而有趣的是，这种延迟并没有真正渗入SDK/API领域，这表明OpenTelemetry在隔离这些对话方面做得不错。 如果我们看Python，会发现他们最慢的PR与`semconv`无关。 | PR | 天数 | 评论数 | 审查数 | 标签 | 主题 | | :--- | :--- | :--- | :--- | :--- | :--- | | [#4646](https://github.com/open-telemetry/opentelemetry-python/pull/4646) | 361.1 | 5 | 19 | — | OpAMP 集成草图 | | [#4576](https://github.com/open-telemetry/opentelemetry-python/pull/4576) | 314.0 | 11 | 27 | Stale | OTLP HTTP max_export_batch_size | | [#4609](https://github.com/open-telemetry/opentelemetry-python/pull/4609) | 253.7 | 29 | — | env carrier | | | [#4709](https://github.com/open-telemetry/opentelemetry-python/pull/4709) | 172.1 | 84 | 0 | — | http 导出器错误处理 | | [#4333](https://github.com/open-telemetry/opentelemetry-python/pull/4333) | 164.9 | 64 | — | GRPC 导出器退避配置 | | | [#4654](https://github.com/open-telemetry/opentelemetry-python/pull/4654) | 161.7 | 71 | 4 | **log-breaking-changes** | 弃用 events API/SDK | | [#4863](https://github.com/open-telemetry/opentelemetry-python/pull/4863) | 155.0 | 53 | 6 | — | 运行时添加/移除 metric readers | | [#4647](https://github.com/open-telemetry/opentelemetry-python/pull/4647) | 152.9 | 49 | **Approve Public API check**, log-breaking-changes | 重命名 Log → LogRecord | | [#4854](https://github.com/open-telemetry/opentelemetry-python/pull/4854) | 150.5 | 79 | hold | W3C traceparent random-trace-id | | | [#4676](https://github.com/open-telemetry/opentelemetry-python/pull/4676) | 126.4 | 203 | 0 | **Approve Public API check**, log-breaking-changes | 日志SDK重构 | 实际上，这些PR延迟的原因是`Approve Public API check`施加了额外的必要检查，这需要另一位维护者。但这似乎是合适的，这又把我们带回了最初的问题——“维护者不足”。 ### 可能的解决方案 所以，在审视了所有这一切之后，模式变得清晰了。在OpenTelemetry中，一个新功能需要很长时间才能到达最终用户手中，因为他们非常重视稳定性，再加上可供调遣的人才相对有限。一旦事情通过了整个技术栈，实现API并将这些API变更传递给最终用户的工作就落在了不堪重负的维护者池身上。那么我们该怎么做？ 我认为一个值得探讨的想法是增加某种有时间限制的Beta层级。基本上是在下图的“实验性”和“稳定”之间。问题在于，对于最终用户来说，由于使用实验性功能需要额外的步骤，它们还不如不存在。我们中99%的人不知道何时添加了一个实验性功能，我们也永远不会去使用它。但如果我知道这个功能至少会保留12个月不会被移除，并且作为最终用户我能更方便地使用它，这实际上可以帮助项目获得更多可操作的反馈。 基本上，一个功能会经历：实验性（使用率相当低）→ Beta（比实验性更面向最终用户）→ 12个月 → 移除或稳定。 现在令人困惑的是，Beta*存在*于OTel中，但用于SDK，而不是组件。比如Rust是Beta，但看起来Profiles不能是Beta。老实说，我几乎搞不清楚什么标签应该用于什么东西。我怀疑没人真的知道。我认为以下是仅适用于SDK的Beta定义的解释。 ``` 开发 组件的某些部分尚未就位，可能尚未对用户开放。预计会报告错误和性能问题。我们希望获得关于组件用户体验的用户反馈，例如配置选项、组件可观测性、技术实现细节以及组件的计划用例。配置选项可能会随着事情的发展而经常中断。组件不应在生产中使用。组件可以