OpenTelemetry如何改变应用追踪与设计方式

NGINX | 2022年7月21日

运行云原生应用时，可观测性至关重要。这类应用的功能由分布在多个位置的大量微服务相互协作实现。由于微服务应用采用松耦合架构，每个微服务可能会以不同方式报告自身活动。如果没有工具汇总并关联这些遥测数据，就很难甚至无法跟踪请求从开始到结束的整个处理过程，而这对故障排除至关重要。

在寻找多功能可观测性工具时，NGINX Modern Apps Reference Architecture（MARA）项目团队选择了OpenTelemetry。鉴于我们的开源软件团队选择了这个新兴项目，我们希望进一步深入探讨。在GlueCon 2022上，我与F5首席技术官办公室架构师Granville Schmidt共同探讨了OpenTelemetry的现状和未来功能为何令我们充满期待。您可以在下方观看我们的对话，并通过本博客进一步了解OpenTelemetry为何能为云原生应用生态带来重要价值。

OpenTelemetry 为可观测性 2.0 提供支持

OpenTelemetry于2019年在巴塞罗那举行的KubeCon上首次发布，OpenTelemetry吸引了众多热情的贡献者。按贡献数量计算，它是云原生计算基金会（CNCF）中受欢迎程度位居第二的项目，过去6个月的贡献速度更是创下新高。如此众多的贡献者表明，OpenTelemetry已经成熟，并开始跨越早期采用者（愿意走在趋势前沿）与实用主义者（希望使用成熟产品）之间的鸿沟。

OpenTelemetry专注于数据，具体而言，就是充分了解应用、排查应用问题并改进应用所需的数据和数据流（遥测数据）。只有能够大规模聚合、分析和可视化，数据才有用。虽然OpenTelemetry并不指导如何将数据可视化，但它让我们不必再担心能获取哪些数据，而是专注于如何利用这些数据。

OpenTelemetry还支持在这些数据源之间自然建立关联，无需我们自行尝试关联。OpenTelemetry能够关联不同应用中的事件，正推动我们迈向可观测性2.0，这是衡量云端应用活动的新基准。数据已完成关联，这改变了我们审视应用环境的方式。我们不再只能了解应用是否正在运行，现在还可以掌握任何请求在应用中的完整路径。

在OpenTelemetry之前，有两个备受关注的开源项目：OpenTracing（OT）和OpenCensus（OC）。这两个项目都致力于标准化追踪数据的格式，以便获取必要信息，并了解这些信息对现代应用的影响。虽然两个项目有相似之处，但它们会争夺资源，企业通常只能选择其中一个。2019年3月，两个项目宣布合并为OpenTelemetry，旨在统一追踪数据的生成和格式。OpenTelemetry项目还在进一步制定相关标准，以便通过与追踪数据相同的遥测通道获取其他类型的可观测性数据（指标和日志），从而提高集成度和清晰度。

接下来，我们来了解OpenTelemetry的两项重要功能：分布式追踪和应用智能。

现代应用架构为何需要分布式追踪

尽管分布式追踪已存在多年，但过去十年的诸多变化使其变得愈发必要。借助Cynefin框架，我们可以重点说明现代应用目前面临的一些变化和挑战：

Cynefin框架说明了在从简单走向复杂的过程中，我们可以如何调整实践方式。挑战在于，这一转变沿着两条各具特点的独立路径展开；试图从简单直接跨越到复杂，往往会造成混乱，导致转变无法彻底完成。

下面来确定现代应用和云原生之旅中的两条路径分别由哪些要素构成。在第一条路径（Cynefin 图中的 Y 轴）上，现代应用通常采用微服务架构，其中每个应用都执行特定任务。在第二条路径（X 轴）上，复杂环境具有临时性：微服务实例会根据需求启动或停止，并在出现网络问题时迁移到其他主机。

我们还必须考虑Amazon Web Services (AWS)、Microsoft Azure和Google Cloud Platform (GCP)等云环境的兴起和大规模增长。这类云的一项优势是能够弹性响应，即扩展或缩减资源，以适应当前的需求水平。再加上容器编排（最常使用Kubernetes）的影响，随着资源数量和位置不断变化，系统开始呈现混沌行为。（即使这种相对受限的情形也具有混沌性，而无服务器函数等因素可能会进一步加剧这种混沌性。）

在现代架构中，许多独立组件都会生成监控和维护应用所需的遥测数据，导致数据量庞大且复杂。由于我们无法完全控制基础设施和通信路径，问题可能不会稳定复现，也不易重现。我们需要借助技术跟踪所有活动及相关要素，从而了解和分析不断变化的环境。

这正是OpenTelemetry发挥作用的地方。

OpenTelemetry赋能分布式追踪的未来

分布式追踪正在推动行业发生重大变化，尤其体现在如何通过指标，根据请求生成内部性能视图。借助分布式追踪，我们可以跟踪多种新的指标，其中最常见的是单位时间内的请求数、单位时间内的错误数，以及该时间单位内聚合请求的耗时。

指标已存在一段时间。它们易于管理和存储，也易于聚合，适合进行数学分析。在OpenTelemetry中，所有生成指标的应用都可以通过遥测（传输）层将指标发送到统一的收集点，这有助于对齐由松耦合服务生成的数据，包括与底层基础设施的数据对齐。简而言之，OpenTelemetry让指标的获取和发送变得更加容易。

OpenTelemetry还有助于解决时间戳漂移和偏差问题，这些问题会增加事件关联的难度。OpenTelemetry会为每个请求分配一个TraceId，但数据仍可能受到漂移和偏差的影响，这种情况在云原生架构中很常见。漂移和偏差可能是由报告路径耗时不一，或不同主机的时钟未能严格同步所致。分布式追踪通过跟踪流量处理期间各组件之间的通信，使OpenTelemetry无需对相关应用进行深度插桩，即可测量各个跨度，即追踪的工作单元和构成要素。

结合这三类信号（遥测数据类别），可以帮助我们修复问题，使应用恢复到生产质量水平：

指标：“是否存在问题？”
追踪，问题出在哪里？”
日志： “问题是什么？”

这就回到了可观测性2.0。通过获取追踪数据，并立即查看各项指标分别对应哪条追踪，我们可以获得强大的问题分析能力。例如，当指标显示存在问题时，分布式追踪可以帮助我们回溯到最初引发问题的具体请求，并跟踪该请求在处理过程中每个步骤的进展。由于追踪由按发生顺序排列的跨度组成，因此可以逐步跟踪请求的完整处理过程。了解发生了什么以及事件的先后顺序，包括从初始事件到指标所显示的问题，再到最终结果，有助于准确定位应用中需要重点关注的位置。

虽然听起来很简单，但OpenTelemetry的分布式追踪功能可以帮助我们深入了解用户体验，并通过请求是否成功及其执行时间来间接反映这种体验。作为用户，我关心自己的请求。作为站点可靠性工程师（SRE），我关心汇总的请求。OpenTelemetry兼顾这两方面，并支持从汇总数据深入查看具体信息，因为它旨在提供跨所有应用所需的全部数据。

借助AI和机器学习实现应用智能

来自OpenTelemetry的这一新数据流还让我们能够以自适应和自动化的方式开展开发和运维响应。借助所有这些积累的数据，我们可以让应用更加智能。F5目前专注于帮助客户开发和部署我们所称的“自适应应用”。顾名思义，自适应应用能够根据环境变化，自动、智能地调整自身行为。

正因如此，各类解决方案越来越多地采用人工智能（AI）和机器学习（ML）。但这并不只是因为它们是热门术语。AI和ML之所以有用，是因为我们现在拥有足够的数据，可以准确判断因果关系并设计适当的响应措施。

OpenTelemetry让遥测数据易于访问并实现标准化，从而大幅简化了构建自适应应用的过程。随着不同类型的产品开始输出相似的指标，并采用OpenTelemetry中既有的语义约定，关联这些产品在请求处理过程中的操作将变得更加容易。随后，可将这些信息提供给机器学习和人工智能算法，使应用和基础设施能够动态适应变化。

了解这一切背后的数据科学，并确保遥测数据与AI和机器学习相关联，才能充分发挥自适应应用的数据驱动特性。

总结

将遥测标准化，对OpenTelemetry用户以及将其用作遥测通道的应用程序而言，都能带来显著优势。数据可以从多个来源收集，并转发到任何兼容的聚合和分析工具。此外，OpenTelemetry Collector让供应商无需自行实现收集器。这样，他们可以专注于增强代码，以开展有意义的分析并采取智能行动，还可以构建新工具，帮助理解这个复杂而混乱的新世界。事实上，在开源创新的支持下，OpenTelemetry Collector能够处理几乎所有现有格式，同时推动相关技术面向未来发展。

OpenTelemetry专注于帮助我们了解应用所需的主要数据类别，使应用能够更深入地洞察复杂的现代应用环境中的性能和问题。通过关联数据并遵循语义和标准约定，OpenTelemetry让现代应用转型之路更加顺畅。随着项目不断成熟、采用率持续提升，OpenTelemetry为我们提供了一种清晰的方法，既能加深理解，也能运用AI和机器学习技术来解析这种复杂性。

要进一步了解NGINX的开源软件工程师如何使用OpenTelemetry，请试用现代应用参考架构和示例应用程序（Bank of Sirius）。