随着可观测性领域中对AI/ML的热炒，公司比以往任何时候都更有可能从将数据存储在一个系统中进行查看，并在另一个系统中训练ML模型中获得利益。
译自 Why the Latest Advances in OpenTelemetry Are Significant，作者 Andy Hoffman 拥有 16 年以上的技术经验，并为独角兽创业公司和成熟组织建立和领导了多个 DevOps 项目、云迁移和架构大修。他在深入的技术工作以及团队建设中都找到乐趣......
一件今年云原生计算基金会关注的热门项目是 OpenTelemetry 和 OpenTelemetry Collector。这个项目在可观测性领域是一个非常激动人心的进展，它是跨行业合作，就可观测性和遥测的数据格式达成标准化。
这本身就很重要，因为它允许从多个可观测性工具收集数据，而以前如果团队想要事件的单一画面，他们会被迫多次转换数据。随着可观测性中对 AI/ML 的热潮，公司比以往任何时候都更有可能从将数据存储和查看在一个系统中，并在另一个系统中训练 ML 模型中受益。
很棒的是，这个项目得以持续推进，归功于行业供应商和个人对 OpenTelemetry Collector 的合作，这是一个标准化的代理和遥测收集器，提供高吞吐量的遥测收集。
下面，我分享这个项目的一些新特性以及为什么它们对社区很重要。
我发现许多代理的语法使得在不使用一些怪异的 yaml 或 toml 的情况下进行有意义的转换非常困难。OpenTelemetry Collector 仍然依赖于 yaml 格式，但它的新转换语言允许基于函数的语句，这些语句执行速度相当快，并允许管理复杂性。查看该语法的一些示例。
在大约一年的开发后，日志收集现已达到 GA。该实现有几种日志收集方式:
- 首先，它作为一个独立的代理运行，并从文件系统收集日志。它可以直接发送到最终目标，也可以转发到以收集器模式运行的 OpenTelemetry Collector，在那里可以即时计算日志指标。
- 其次，存在许多日志 SDK，可以直接在应用程序中实现，并发送到中心收集器或直接发送到最终目标，这可以帮助最小化磁盘 IO 的影响。
自动插桩是指自动连接应用程序以发出跟踪和指标的功能，而代码更改很小或没有。Java 和 .Net 完全支持，其他语言正在开发和发布的各个阶段。专有解决方案一直将此功能作为差异化因素展示，因为它通过最小化开发人员的时间来减少了推出的复杂性，现在这为 OpenTelemetry 生态系统带来了同样强大的功能。
这个是巨大的，并且从 ElasticSearch 捐赠 ECS(Elastic Common Schema)给 OpenTelemetry 项目中受益。标准化遥测结构具有挑战性，因为似乎几乎每个人都以稍微不同的格式产生遥测数据；然而，为了能够分析、创建警报并以人类友好的方式呈现数据，所有遥测字段都需要以某种方式进行映射。
如果每个人和每个系统都只是稍有不同，这就提出了制作可重用仪表盘和组件的挑战。软件供应商现在可以合理确信数据将以正确的格式出现在多个平台上，从而负责在许多平台上创建仪表板。
与此同时，我们这些管理大量遥测数据的人可以改进摄取和查询效率，并且如果大多数客户发送的内容依赖于众所周知的字段名，我们可以使用较少的计算资源和内存开销提供更高级的功能。
完整的模式距离最终确定还有一段距离，但约定正在逐步批准。例如，在 KubeCon 上，他们宣布了 HTTP 模式的最终确定。
生态系统正在成熟。可扩展性框架允许自定义摄入管道的任何阶段。越来越多的接收器适用于各种系统，处理器具有越来越高级的功能，以及目的地。我特别兴奋的是 OpenSearch 扩展的新版本，它以简化的可观测性模式或 ECS 格式预打包发送日志数据。
从开发人员的角度来看，我发现模式和内部“p”消息模式的结构经过了非常周到的思考，并内置于 protobuf 中。它在功能自由度和最小复杂性之间取得了很好的平衡。
这对 CNCF 社区来说并不新鲜，但这个项目的速度和影响体现了 CNCF 社区理念的精神。竞争的公司正在共同努力，使一块计算机对我们其他人来说更好、更容易。一些人可能担心，消除供应商锁定会导致客户流失，或者共享代码可能会泄露专有知识产权。
然而，在遥测领域，代理和收集器的核心架构通常是一个已解决的问题。那么为什么不制作一些遵循约定并跨平台工作的东西，这样公司就不再需要维护代理代码，其中 80%都是重复的?这使公司可以致力于共享的插件以实现互操作性和专有处理器，其中创新可以通过这个框架交付。
供应商和所有运营商也从中受益。使用标准化的 OpenTelemetry Collector SDK，供应商可以创建一个集成来检测其应用程序中的遥测，并大大简化收集过程以及试图让所有主要的可观测性提供商为您的应用程序实现支持。
运营商也从“任何地方收集”和“任何地方发送”的心态中受益。标准配置文件格式简化了设置，同时加入新系统的复杂性最小化。我还怀疑许多日志系统运营商将看到这个问题的字段映射基数问题大大减少，这要归功于该项目对可观测性数据的语义约定。
向所有项目贡献者和社区成员表示巨大的“感谢!”!这里无法一一列举，但您可以在 GitHub 上的 OpenTelemetry 项目中追踪到他们。
OpenTelemetry 和 OpenTelemetry Collector 的功能和前进道路正在迅速推进，过去的一年是 CNCF 组合中继 Kubernetes 之后的第二大贡献项目。有这么多贡献者保持组织性并共同努力，成熟度将继续加速。希望这将通过增加互操作性和改进检测系统以进行遥测收集的能力，来释放可观测性领域的创新。
(编者注:本文已修改，明确了 OpenTelemetry 的作用。)