路线图很快就会过时。有关最新的路线图，请参见 OpenTelemetry 状态 页面。也就是说，以下是截至目前 OpenTelemetry 的状态。
核心组件
目前，OpenTelemetry 追踪信号已被宣布为稳定的，并且在许多语言中都有稳定的实现。
度量信号刚刚被宣布稳定，测试版的实施将在 2022 年第一季度广泛使用。
日志信号预计将在 2022 年第一季度宣布稳定，测试版实现预计将在 2022 年第二季度广泛使用。2021 年，Stanza 项目被捐赠给 OpenTelemetry，为 OpenTelemetry 收集器增加了高效的日志处理能力。
用于 HTTP/RPC、数据库和消息系统的语义公约预计将在 2022 年第一季度宣布稳定。
未来
完成上述路线图就完成了对 OpenTelemetry 核心功能的稳定性要求。这是一个巨大的里程碑，因为它打开了进一步采用 OpenTelemetry 的大门，包括与数据库、管理服务和 OSS 库的原生集成。这些集成工作大部分已经以原型和测试版支持的形式在进行。随着 OpenTelemetry 的稳定性在 2022 年上半年完成，我预计在 2022 年下半年将出现支持 OpenTelemetry 的宣言，使 2022 年成为 “OpenTelemetry 之年”。
但我们并没有就此止步。下一步是什么？
eBPF
Extended Berkeley Packet Filter（eBPF）是一种在 Windows、Linux 和其他类似 Unix 的操作系统上提供底层网络访问的机制。利用 eBPF 将给 OpenTelemetry 提供一种极其有效的网络监控形式，不需要任何开发人员的工具。
2021 年，Flowmill 项目被捐赠给了 OpenTelemetry。Flowmill 是一个基于 eBPF 的可观测性解决方案，专门设计用于观测分布式系统。Flowmill 的开发者与 Pixie 项目的开发者一起，正在努力为 OpenTelemetry Collector 增加 eBPF 支持。Pixie 是专门为 Kubernetes 设计的基于 eBPF 的观测工具，是 CNCF 旗下 OpenTelemetry 的一个姊妹项目。我们还在一起研究如何将底层（第 2 层）eBPF 数据与高层（第 7 层）分布式追踪数据进一步关联起来，这在业界尚属首次。
RUM
真实用户监控（RUM）是一种可观测性工具，用于描述用户在长期运行的用户会话中如何与移动、网络和桌面客户端进行交互。RUM 与分布式追踪不同，因为图形用户界面（GUI）往往是基于反应器的系统，与数据库和网络服务器等基于事务的系统有根本的架构差异。长话短说：你不能把一个用户会话建模为一个追踪，然后就收工了。
Client Instrumentation SIG 目前正在开发一个新的 RUM 设计，它将扩展并与 OpenTelemetry 现有的分布式追踪、指标和日志信号完全整合。
OpenTelemetry 控制平面
目前，OpenTelemetry 收集器和 SDK 是作为独立的单元来管理的，必须重新启动才能改变它们的配置。目前，Agent Management SIG 正在开发一个控制平面，它可以报告这些组件的当前状态，并允许实时改变配置。它将允许运维人员或自动服务动态地控制整个遥测管道的处理。
动态配置将允许对采样、日志水平和其他形式的资源管理进行细粒度、反应灵敏的控制，从而减少成本。最终，这个控制平面可以实现更先进的基于尾部的采样形式，即需要在整个部署中协调的采样技术。
列式编码的 OTLP
目前的 OpenTelemetry 协议是对 OpenTelemetry 数据模型的一种有效而直接的编码。跨度、度量和日志被编码为跨度、度量和日志。这可以被认为是一个基于行的模型，每个跨度、度量和日志都被编码为元素列表中的一个离散元素。基于列的模型则将每个元素编码为一个单一的表格，其中所有元素共享相同的列，用于重叠的概念，如时间戳和属性。
这种列式表示法有望优化数据批次的创建、大小和处理。这种方法的主要好处是：
- 更好的数据压缩率（一组相似的数据）。
- 更快的数据处理（更好的数据定位意味着更好地使用 CPU 缓存线）。
- 更快的序列化和反序列化（更少的对象需要处理）。
- 更快的批量创建（更少的内存分配）。
- 更好的 I/O 效率（传输的数据更少）。
这种方法的好处与批次的大小成比例地增加。使用现有的 “面向行” 的表示方法很适合小批量的情况。因此，列式编码将扩展当前的协议。目前提出的实施方案是基于 Apache Arrow，这是一种成熟的列式内存格式。
这种优化的重点是允许高容量的数据源，如 CDN 和大型多租户系统，像常规服务一样参与可观测性。列式编码也将减少跨网络边界的遥测出口的成本。