演进 OpenTelemetry 的稳定性和发布实践
摘要
OpenTelemetry 在任何方面都是云原生领域最大、最令人兴奋的项目之一。在过去的五年里，这个社区汇集在一起，构建了历史上最关键的可观测性项目之一。然而，我们并没有止步不前。该项目持续寻求并倾听来自广泛利益相关者的反馈。我们从你们那里听到的信息是，为了更上一层楼，我们需要调整我们的优先事项，并专注于项目发布和文档、示例等工件的稳定性、可靠性和组织性。
在过去的一年里，我们进行了一系列用户访谈、调查，并在各种场合进行了公开讨论。这些讨论表明，OpenTelemetry 的复杂性和缺乏稳定性给生产部署带来了障碍。
这篇博文概述了治理委员会认为至关重要的目标和宗旨，以应对这些反馈。我们从这篇博文开始，以便公开进行这些讨论。
我们的目标
- 确保所有 OpenTelemetry 发行版“默认稳定”，并提供标准化的机制供用户选择加入实验性或不稳定的功能。
- 制定一套单一、清晰、一致的稳定性标准，包括文档、性能测试、基准测试等。
- 使仪器库更容易稳定，并鼓励语义约定的联合。
- 引入更易于最终用户组织使用的“纪元发布”。
我们期待您的反馈！
对于维护者和贡献者，我们很希望听到您对此提案的总体反馈，以及关于具体实施时间表、稳定级别迁移的要求以及如何处理遥测输出迁移等方面的反馈。
对于最终用户，我们很希望了解您倾向于如何采用 OpenTelemetry 的发布，以及您目前是如何做的。在我们评估不同的版本和发布策略时，了解您目前如何推出变更（尤其是在多语言环境中）将非常有帮助。我们还希望听取您关于组件（如仪器库、Collector 等）的文档和性能基准测试的反馈。
对于集成商、供应商和更广泛的生态系统，我们希望听到关于仪器和语义约定元数据及发现的反馈和建设性建议。对于构建在 OpenTelemetry 之上或与 OpenTelemetry 并行的集成商，我们很希望了解如何让您和您的用户更容易使用 OpenTelemetry，以及如何让您更容易发布和维护自己的仪器。
这篇博文的后续部分还有其他具体的要求，我们希望得到您的反馈。请记住，实现这些目标的具体方式并非一成不变——这就是为什么我们需要您对这些提案发表意见！如果您认为有更好的方法来实现这些目标，请在讨论中告知我们。
我们为什么要这样做？
OpenTelemetry 已发展成为一个庞大而复杂的生态系统。我们支持四种不同的遥测信号（跟踪、指标、日志和配置文件），涵盖十几种编程语言。每种语言都有其自身的运行时要求和执行环境。该 规范合规性矩阵 展示了我们试图完成的工作量——这确实令人不知所措。
这种复杂性带来了真实的采用障碍。准备在生产环境中部署 OpenTelemetry 的组织会遇到意想不到的障碍：次要版本之间的配置中断、仅在大规模部署时出现的性能回归，以及协调跨越数百或数千个服务的发布所带来的挑战。许多团队因此推迟或缩减了 OpenTelemetry 的部署。
对于维护者来说，这种复杂性使他们的工作比实际情况更困难。缺乏明确的里程碑和关于在任何给定时间“最重要”的事物的指导。稳定性工作涉及大量变动，并且关于应该在哪里投入时间的指导常常相互冲突。
解决这些问题应该是项目的一个高优先级事项，这既是为了我们维护者和贡献者的健康，也是为了让我们能够随着项目的成熟继续发展和扩展，尤其是在我们与云原生生态系统的集成越来越深入的情况下。
治理委员会认为，要取得成功，这些变革需要社区的参与和讨论，因此我们借此机会宣布我们的意图，并开启一个 GitHub 讨论，以收集用户、维护者和贡献者的反馈。我们不期望这些变革会一夜之间完成，并向大家保证，即使在考虑项目整体福祉和成熟度所需的必要变革时，我们也将继续优先满足用户和维护者现有的承诺。
1. 默认稳定
稳定性保证一直是 OpenTelemetry 的一个长期原则，其标准极高。这一点与用户需求之间存在一种需要讨论的张力。
背景
OpenTelemetry 是一种关于云原生软件（库、框架、基础设施抽象、可执行代码等）如何生成和通信关于其操作的遥测数据的规范。该规范旨在详尽、全面且低级。规范的许多元素都源于其作者在构建、操作或设计行星级规模遥测系统方面数十年经验的集体智慧。
然而，没有实现的规范对最终用户来说并没有用。开发人员和运营商通过各种视角来处理遥测；一些组织对可观测性有很高的标准，拥有专门构建内部监控和仪器框架的团队。其他组织则将可观测性和监控视为次要或第三优先事项——这是需要完成的事情，但并不受激励。OpenTelemetry 作为一项规范，需要服务于所有这些用户及其用例。
为了使 OpenTelemetry 有用，我们需要提供一个从现有方法和模式、现有工具和策略中“上车”的途径，这意味着我们需要提供不仅是规范的实现，还有对规范的应用。实际上，这意味着我们需要分发库来为现有的 HTTP 服务器和客户端添加 OpenTelemetry 仪器，或者 Collector 接收器来从 MySQL 抓取指标并将其翻译成 OTLP。
我们的社区从 OpenTelemetry 中获得的大部分价值直接来自仪器库和 Collector 组件——而不是核心 SDK。虽然我们将它们组织在 contrib 仓库中以区别于核心组件，但最终用户看不到或不关心这种区别。他们只想要能正常工作的仪器。
对于维护者和项目领导者来说，我们的稳定目标和 contrib 的性质提出了重大挑战。用户希望获得稳定、经过充分测试且性能良好的发布——这些发布也能执行与商业仪器代理相同的函数。
目标与宗旨
总的来说，在这一领域有三个要点：
- 所有仓库中的所有组件（包括语义约定）都应通过元数据文件/信息，以一致的方式传达稳定性，并且这种信息可以以编程方式发现和解析。确切的格式应通过 OTEP 定义并纳入规范。
- 稳定性要求应扩展到包括更多关于文档及其托管地点、示例代码、性能基准（如适用）、实施指南和其他必要工件的要求。
- 稳定的 OpenTelemetry 发行版默认应只启用稳定的组件。用户应能够通过有记录且一致的配置选项选择所需的最低稳定性级别。
我们认识到这对维护者来说将是一个巨大的变化，尤其是那些已经发布了 v1+ 版本的库的维护者。我们非常希望在 讨论 中获得您对这些目标的反馈。
2. 仪器稳定性和语义约定
为了实现我们的稳定目标，我们也需要解决语义约定稳定性和流程问题。
语义约定挑战
语义约定演进缓慢且审慎，因为它们必须在各种遥测系统之间通用。虽然 OpenTelemetry 设计用于信号相互连接并协同工作，但用户部署了许多不同的存储和分析引擎来消费这些数据。每个后端都有其自身的限制和功能。维护者必须在相互竞争的顾虑之间取得平衡——保持基数的可管理性，确保属性有用但不过于具体，并制定无论数据最终去向何处都能良好工作的约定。
其缺点是，语义约定方面的进展可能缓慢，而这种缓慢会影响到所有约定消费者。许多仪器库目前仍停留在预发布版本，因为它们依赖于实验性语义约定。外部贡献者要么被卡在发出未经规范的遥测数据，要么试图参与这个过程，这需要长期的投入。最后，我们在项目内部的仪器方面也存在不一致；有些库已映射到约定，有些则独立于约定存在。
仪器和约定目标
我们的目标是实现三个结果。
- 仪器稳定性应与语义约定稳定性分离。我们有许多稳定的仪器，可以在生产环境中安全运行，但其数据在未来可能会发生变化。用户告诉我们，混淆这两种稳定性级别令人困惑，并限制了他们的选择。
- 语义约定应更加联合化；OpenTelemetry 不应是约定存在的最终决定者，而应专注于创建核心约定，这些约定可以进行扩展和构建。
- 语义约定开发和迭代不应成为发行版维护者的障碍。
为此，我们有几项建议希望将其编入规范。首先，我们对 OpenTelemetry 中仪器库的定位是，它们作为语义约定的具体实现。这为我们希望在发行版中支持的“第一方”仪器库提供了一个具体的目标。此外，维护者应优先支持与现有约定一致的仪器，并降低其他仪器的优先级。
其次，我们希望使维护者更容易发布稳定的仪器。如果一个仪器的 API 表面是稳定的，那么我们认为语义约定稳定性不应阻止该仪器库的稳定化。这意味着我们需要谨慎地提供遥测迁移路径，以便操作员能够升级到仪器库的新主要版本。
最后，我们希望通过正式化和稳定语义约定的必要部分，使第三方更容易发布自己的语义约定，以便其他组织能够为他们的库、框架、技术栈等发布约定。
为了实现这一点，我们正在寻求维护者和最终用户的反馈，尤其是在语义约定的成熟度/生命周期方面，以及在联合化语义约定方面缺少什么。我们对这里的提案更灵活，但我们的结果不是。请记住，项目的一个核心目标是鼓励其他库、工具和框架 原生采用 OpenTelemetry ——语义约定是其中的重要组成部分。
3. 可靠且稳定的发布
挑战
OpenTelemetry 不仅仅是一个部署在 Kubernetes 集群中的单个二进制文件。从配置到不同版本仪器库、Collector 接收器和 SDK 的遥测输出之间的细微差别，都可能给采用者带来真正的麻烦。此外，许多组件快速的发布节奏给最终用户带来了真正的困难，尤其是在 Collector 方面。企业级部署和升级是缓慢而审慎的——团队根本没有精力以我们发布的节奏来验证和推出变更。
发布目标和策略
最终，我们的目标是让大型组织更容易部署 OpenTelemetry。请记住，在许多组织中，“部署”和“升级”是重要的任务，涉及多个团队和利益相关者，分布在不同的业务部门或职责领域，包括安全。
我们目前的提议是创建一个发布 SIG（Special Interest Group），负责制定 OpenTelemetry 的“纪元”发布时间表。这些纪元版本本质上是一个清单，指向一组经过测试、记录良好且稳定的组件，这些组件符合项目的稳定性要求。
要明确地说，这不是一项微不足道的任务。这些努力将传达这些纪元版本必须遵循的许多要求。毕竟，对于我们的维护者和贡献者来说，这项工作无意改变单个组件、SDK 或 API 的版本控制或发布方式。相反，我们希望为需要稳定性的最终用户提供经过测试、稳定的组件组合。
对于最终用户，我们很希望了解您目前是如何管理升级的，您希望在这一领域看到什么，以及您目前在 SDK 和 Collector 部署和升级方面面临的挑战。
展望
这些变革反映了 OpenTelemetry 对云原生软件社区的影响和重要性。在过去几年中，OpenTelemetry 一直是 CNCF 中增长速度第二快的项目，并且 近 50% 的受访云原生用户公司已采用该项目。这些变革正在为我们下一个成功篇章奠定基础，并真正实现普及。
我们作为一个项目的使命没有改变，但我们的优先事项在改变。
- 为所有开发人员和用户提供稳定性和易用性。
- 清晰的打包、安装和使用路径。
- 可预测性和一致性。
对于贡献者和维护者来说，这意味着什么？我们将加速符合这些优先事项的提案。如果存在不符合这些优先事项的功能工作或仪器，那也没关系——我们要求您在项目之外进行工作，并发现我们现有的集成点和模式在哪里不起作用。这是一个很好的反馈，将帮助我们改进规范，使所有人受益。
对于维护者、贡献者和集成商——我们很希望在 此 GitHub 讨论 中就此处提出的主题和提案提供反馈。您也可以将对此提案的反馈发送至 feedback@opentelemetry.io，或在 CNCF Slack 的 #opentelemetry 频道中提供。我们也很期待下周在 KubeCon 上与云原生社区会面——请届时与我们一起进行交流！