OpenTelemetry Collector v1 版本路线图

博客文章在发布后不会更新。这篇文章已经发布一年多了,其内容可能已过时,部分链接可能无效。在依赖任何信息之前,请务必核实。

OpenTelemetry Collector 是 OpenTelemetry 中一个非常受欢迎的组件,经过长时间的大力开发。它是一个二进制文件,允许将多种格式的遥测数据发送到其中,进行转换,然后导出到目标。在过去的几年里,关于 Collector 的各种博文和演讲已经有很多介绍了。如果您还没有机会了解它,这里有一份关于 Collector 的演讲列表:

Collector 一直是希望将 OpenTelemetry 作为其改进系统遥测数据策略一部分的组织的骨干组件。世界各地的组织已经采用了它,并通过管道成功处理了大量数据,正如这些各种演讲所记录的那样:

几个月前,社区有人提出要求,希望将 OpenTelemetry Collector 宣布为稳定版。

Can haz Collector v1?

现在您可能会问自己:“为什么会有人想让 Collector 被宣布为稳定版?你刚才不是说它已经在生产中使用了吗?” 确实,对于核心组件而言,Collector 及其配置在一段时间内一直相当稳定。然而,“非官方稳定”对于希望采用 Collector 的各类组织来说仍然不够。

  • 正式的 v1 版本将标志着 OpenTelemetry 社区已准备好提供长期支持,并且不会在不升级主版本号的情况下引入向后不兼容的更改。
  • 有政策规定不使用预发布软件的组织将能够开始采用 Collector。
  • Collector 的稳定性有助于推动 OpenTelemetry 成为 CNCF 毕业项目。

维护者对稳定化的请求做出了回应,因为将任何东西称为 1.0 版本都会在一定程度上无限期地设定预期。这导致了一系列讨论和会议,汇集了 Collector 的维护者,以决定 1.0 版本对 Collector 究竟意味着什么。

经过反复讨论,我们确定了想要关注的范围:

  1. 一个只包含 OTLP 接收器和 OTLP 导出器的 Collector 发行版。
  2. Collector 所依赖的单个 Go 模块也必须按照项目的 版本指南 标记为稳定。

除此之外,根据用户的反馈,贡献者还希望改进几个方面:

  • Collector 关于自身生成的遥测数据
    • 必须通过 OTLP 提供 traces、metrics 和 logs。
    • 遥测数据的配置必须遵循配置 schema。
  • Collector 的可扩展性
    • 必须改进队列、背压和错误处理。
    • 为最终用户提供明确的基准和性能预期。
  • 整体文档应符合关键基础设施稳定版的标准。

已在 Collector 的存储库中发布了 路线图,并创建了里程碑来跟踪正在进行的工作。为了确保工作能够成功,我们将可交付成果的范围限定在提供:

  • 一个清晰且可实现的目标
  • 所需的专注度,以免分心
  • 向新贡献者表明项目关注的方向

正如您在 项目看板 上看到的,还有很多工作要做,但这项工作充满了令人兴奋的进展。如果您有兴趣提供帮助,请通过评论 GitHub 上的任何开放问题,或参加每周三举行的 Collector SIG 会议来联系我们。要快速了解 1.0 的进展,您可以查看跟踪 问题