随着可观测性领域对 AI ML 的炒作，公司比以往任何时候都更有可能获得将数据存储在一个系统中以在另一个系统中查看和训练 ML 模型的好处。
作者 Andy Hoffman 翻译自《为什么 OpenTelemetry 的最新进展很重要》，拥有超过 16 年的技术经验，并为独角兽初创公司和成熟组织构建并领导了多个 DevOps 项目、云迁移和架构改革。 他从深入的技术工作和团队建设中找到了乐趣。 今年的云原生计算**最受欢迎的项目之一是 OpenTelemetry 和 OpenTelemetry Collector。 这个项目在可观测性领域是一个非常令人兴奋的发展，因为它是一项跨行业的合作，旨在标准化可观测性和遥测的数据格式。 这本身就很重要，因为它允许从多个可观察对象收集数据，而以前，如果团队想要一个事件的单张图片，他们就被迫多次转换数据。 随着 AI ML 在可观测性方面的热潮，公司比以往任何时候都更有可能从一个系统中存储和查看数据以及在另一个系统中训练 ML 模型中受益。
最棒的是，由于行业领导者和个人与 OpenTelemetry Collector 的合作，这个项目正在向前推进，OpenTelemetry Collector 是一种提供高吞吐量遥测收集的标准化遥测收集器。 下面，我将分享该项目的一些新功能，以及为什么它们对社区很重要。
我发现许多语法使得如果不使用一些奇怪的 yaml 或 toml 就很难进行有意义的转换。 OpenTelemetry Collector 仍然依赖于 YAML 格式，但其新的转换语言允许基于函数的语句执行得相当快，并允许管理复杂性。 查看该语法的一些示例。 经过大约一年的开发，日志收集现已正式发布。 有几种方法可以收集此实现的日志：
首先，它作为独立运行**，并从文件系统收集日志。 它可以直接发送到最终目标，也可以发送到在收集器模式下运行的 OpenTelemetry Collector，在该模式下可以动态计算日志指标。
其次，有许多日志 SDK 可以直接在应用程序中实现并发送到中央收集器或直接发送到最终目标，这有助于将磁盘 IO 的影响降至最低。
自动检测是指自动连接应用程序以发出跟踪和指标的能力，而很少或没有更改。 j**a 和 .完全支持 .net，其他语言正在各个阶段开发和发布。 该专有解决方案一直将这种能力展示为差异化优势，因为它通过最大限度地减少开发人员时间来降低部署的复杂性，现在这为 OpenTelemetry 生态系统带来了同样强大的功能。
这是巨大的，并且受益于 Elasticsearch 向 OpenTelemetry 项目捐赠的 ECS（弹性通用架构）。 标准化遥测结构具有挑战性，因为似乎几乎每个人都在以略有不同的格式生成遥测数据; 但是，为了能够以人性化的方式进行分析、创建警报和呈现数据，需要以某种方式映射所有遥测字段。
如果每个人和每个系统都略有不同，那么制作可重用的仪表板和组件就带来了挑战。 软件供应商现在可以负责在许多平台上创建仪表板，并有理由相信数据将在多个平台上以正确的格式显示。
同时，我们这些管理大量遥测数据的人可以提高引入和查询效率，并且如果大多数客户发送的内容依赖于已知字段名称，我们可以以更少的计算资源和内存开销提供更高级的功能。
完整的模型距离最终确定还有一段路要走，但公约正在逐步获得批准。 例如，在 Kubecon 上，他们宣布了 HTTP 模式的最终确定。
生态系统正在成熟。 扩展性框架允许自定义引入管道的任何阶段。 越来越多的接收器适用于各种系统，处理器具有越来越多的高级功能，以及目的地。 我对新版本的 OpenSearch 扩展感到特别兴奋，它以简化的可观测性模式或 ECS 格式预先打包了日志数据的发送。
从开发人员的角度来看，我发现架构的结构和内部的“p”消息架构经过深思熟虑，并内置到 protobuf 中。 它在功能自由度和最小复杂性之间取得了良好的平衡。
这对 CNCF 社区来说并不新鲜，但该项目的速度和影响力体现了 CNCF 社区理念的精神。 相互竞争的公司正在共同努力，为我们其他人提供更好、更轻松的计算机。 有些人可能担心取消供应商锁定会导致客户流失，或者共享可能会泄露专有知识产权。
然而，在遥测领域，收集器的核心架构往往是一个已解决的问题。 那么，为什么不做一些遵循惯例并跨平台工作的东西，这样公司就不再需要维护***，其中 80% 是重复的呢？ 这允许公司开发共享插件以实现互操作性和专有处理器，其中可以通过该框架提供创新。
*企业和所有运营商也从中受益。 使用标准化的 OpenTelemetry Collector SDK，供应商可以创建一个集成来检测其应用程序中的遥测数据，并大大简化收集过程，并尝试让所有主要的可观测性提供商实现对应用程序的支持。
承运商还受益于“随处取货”和“随处发送”的心态。 标准配置文件格式简化了设置，同时最大限度地减少了新系统的复杂性。 我还怀疑，由于该项目对可观测性数据的语义约定，许多日志系统操作员将看到此问题的字段映射问题的基数显着减少。
向所有项目贡献者和社区成员表示衷心的“感谢”！ ”!我无法在这里一一列出，但你可以在 GitHub 上的 OpenTelemetry 项目中跟踪它们。 OpenTelemetry 和 OpenTelemetry Collector 的功能和发展道路正在迅速发展，过去的一年是 CNCF 产品组合中仅次于 Kubernetes 的第二大贡献项目。 由于有如此多的贡献者保持井井有条并一起工作，成熟度将继续加速。 希望这将通过提高互操作性和提高遥测收集检测系统的能力来解锁可观测性的创新。
编者注：本文已经过修订，以阐明 OpenTelemetry 的作用。 )