来自Kubecon的OpenTelemetry项目和路线图更新

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

2022 年对 OpenTelemetry 来说是非凡的一年。指标(Metrics)已成为一流的信号类型,并与 OpenTelemetry 现有的分布式跟踪(distributed tracing)支持一起,在生产服务和基础设施上使用,以将关键性能数据发送到任何可观测性后端进行处理。我们到处都能看到 OpenTelemetry 被测试、推出或已经在各种规模的组织中投入使用,从最大到最小,从最前沿到传统保守的组织。

自一月以来,我们已交付:

  • 指标:在规范中定义,并在 Java、JS、.NET 和 Python SDK 及相关工具中交付,支持一直延伸到 Collector 和协议。更多语言的实现正在路上。
  • 为所有语言提供更多工具。
  • 一个很棒的演示应用程序,其中包含用所有支持的语言编写的服务,并已通过 OpenTelemetry 进行了检测。这是一个了解 OpenTelemetry 实际应用并从中学习或进行实验的好方法,该演示应用程序还可用于测试不同的可观测性分析系统。
  • C++、Erlang 和其他许多新语言中的跟踪(tracing)稳定性。
  • Ruby、Erlang、Swift 和 .NET 自动检测方面的进展。
  • 日志(Logs)方面取得重大进展,这是 OpenTelemetry 的第三种信号类型。
  • 文档!
  • 对所有组件的各种改进。

社区也在持续显著增长。我们现在拥有GitHub 上超过 800 名月活跃开发者,来自 150 个不同的组织。越来越多的贡献者是最终用户——我们排名前 25 的贡献组织中有 10 个——这是一个项目非常健康的信号。人们和公司从 OpenTelemetry 中获得了巨大的价值,他们回馈社区,使其对每个人都更有用。

我们在 KubeCon 期间发布此文,届时许多社区成员和最终用户将聚集在一起讨论 OpenTelemetry 及其使用方式、如何改进以及未来发展方向。今年五月,在 KubeCon EU 上,我们启动了创建一个更正式的 OpenTelemetry 路线图的流程,我们将在底特律继续这个流程。我提前写这篇帖子,因此无法发布最终结果,但以下是我们认为最重要的几项:

  • 完成日志:完成完整的规范,然后在每种语言中实现该规范。
  • 使 OpenTelemetry 更易于使用,包括技术上(如 OpenTelemetry 控制平面等新功能)以及通过文档、收集用户反馈等。
  • 客户端检测:将 OpenTelemetry 扩展到捕捉 Web、移动和桌面客户端应用程序的性能数据。这可用于捕捉真正的用户导向 SLO(Service Level Objectives)数据,显示跟踪中的端到端延迟等。
  • 性能剖析(Profiling),它将服务性能(今天通过指标和跟踪捕获)与代码中的实际函数性能联系起来。
  • 改善贡献者和维护者的体验。

我们今年剩余时间和明年一年的重点将是完善 OpenTelemetry 在所有语言、场景和集成中的现有功能,以及上述路线图项目。如前所述,在未来几周内,我们将发布一个更正式的路线图文档,其中包含这些内容,但需要注意的是,每个项目上的优先顺序和进度取决于投入的努力和参与的社区成员数量。

其中许多项目,如日志、客户端检测和性能剖析,已在进行中。我们对这些新举措感到兴奋,因为它们不仅扩展了项目的可用性,使其更接近其原始愿景,而且吸引了一批新成员加入社区,他们已经将他们的知识、经验和热情融入 OpenTelemetry。这是项目激动人心的日子,看到它如此迅速地发展和被采用,让所有参与者都感到振奋。

最后修改于 2023 年 5 月 25 日:Textlint 修复博客文章 (#2790) (36914714)