多年来，当我试图将一个团队从他们特定供应商的 SDK 迁移到 OpenTelemetry 时，最常听到的可靠抱怨之一就是一些变体："为什么感觉这还没有完成？" 供应商的可观察性 SDK 客观上来说是傻瓜式的。你只需安装这个东西，仪表盘就可以加载数据，其他人则担心所有这些部分如何组合在一起，而你可以继续你的生活。相对而言，OpenTelemetry 在大门口迎接你的是许多“实验性”标签和大约六种不同的方法来完成任何给定的任务。在 OpenTelemetry 的辩护中，这绝不是他们作为项目所追求的目标。我一直尊重他们坚持自己立场，试图构建一个真正与供应商无关的系统，实际上并不关心你如何处理数据。尽管考虑到可观察性生态系统的盈利性和争议性，我从来没有感到对 OTel 有强烈偏好的供应商。不过，考虑到这个项目的维护者基本上是那些公司独家雇用的。我开始感到紧张。语义约定库中的对话拖延得很长。不同的语言有着截然不同的故事。Golang 和 Dotnet 是第一公民，但其他语言却滞后于其他语言数年。在向那些没有时间、预算或情感带宽的小团队推荐 OpenTelemetry 之前，我开始问了很多探讨性的问题。自动仪器的确是神奇的，但“自动仪器工作”和“现在我必须手动仪器某个东西”之间的悬崖是足够陡峭的，以至于在将人推下去之前，你欠他们一个警告。这个叙述在可观察性领域已经持续了一段时间，大家隐约感觉到“在 Otel-land 似乎有什么不对劲”。但是让我们试着生成一些实际的数据。是否真的存在问题，还是社区对进展缓慢的看法是虚构的？这个问题是维护者不足、范围太大，还是两者之间？我开始时的猜测是“哦，这是经典的开源项目多吃了自己无法咽下的食物”。维护者不足，预算不足。现在确实有一些这样的情况，但还有其他事情在发生。OpenTelemetry 内部发生的实际问题是三者相撞。你有一个二进制稳定性门槛，而当它与很少的实际维护者相结合时，就会出现关于标记某个功能为非实验性的可理解担忧，再加上他们试图覆盖的大量语言和框架。这创造了一个完美的风暴，造成了激烈争论的动机，因为一旦某个功能被锁定并作为稳定版发布，就永远不能更改它们。OpenTelemetry 如何工作 OpenTelemetry 目前正试图支持令人眼花缭乱的众多语言和框架。OpenTelemetry 是一个庞大的项目。它跨越数十种语言，数百个库，以及无数的后端。为了保持事情的理智，该项目将工作分成两个部分：核心 → 由 OTel 项目直接维护。小而稳定，与供应商无关，并经过严格审查。这是“规范定义”的表面。贡献 → 社区和供应商贡献的。覆盖更广，运转更快，并涵盖长尾集成。存在一个 otel-collector，它与这些功能并行运行，以便你可以发送日志、指标和追踪。它复制了相同的粗略模式。但是，当我们谈论核心与贡献的语言时，这就是我们在讨论的内容。 opentelemetry-python（核心） API、SDK、OTLP 导出器、上下文传播、资源检测原语 opentelemetry-python-contrib Flask、Django、requests、psycopg2、Redis、Kafka、boto3 等的仪器库。出现问题的内容进入贡献，不出现问题的内容进入核心。现在这就是造成冲突的原因。贡献对大多数项目来说是过度设计。你不想要 300 个导出器来添加通常需要的一个。在语言方面，这并不是大问题。pip install opentelemetry-instrumentation-flask 便可以得到 Flask 所需的内容。然而，在收集器方面，你最终不得不使用 OpenTelemetry Collector Builder 来制作自己的收集器（或者干脆随波逐流，希望它能发挥作用）。尽管这个存在很酷，但对于一个团队而言，要求承担如此巨大的范围是很大的挑战。添加新功能的过程 我相信我已经捕捉到了添加新功能到 OTel 的工作流程。你可以在这里查看我的作业：OpenTelemetry 增强提案（OTEP）（https://github.com/open-telemetry/opentelemetry-specification/tree/main/oteps/）一旦 OTEP 被接受，文本就会被放入同一库的规范目录中。之后似乎会进入语义约定。这似乎是我们进入具体细节以及大部分长篇讨论的地方。