浏览 941
原文作者：Dave McAllister of F5
原文链接：OpenTelemetry 正在改变我们跟踪和设计应用的方式
转载来源：NGINX 官方网站
可观测性是运行云原生应用的关键，而云原生应用的功能依赖于在多个位置运行的大量微服务之间的交互。微服务应用的松散耦合性可能意味着每个微服务都在以自己的方式报告自己的活动情况。全程跟踪请求的处理过程对于故障排除至关重要，然而如果没有一款合适的工具来编译和关联这些遥测数据，跟踪会变得非常之困难——即便没有到不可能的地步。
经过多番考量，NGINX 现代应用参考架构 (MARA) 项目团队从一众多功能可观测性工具中选中了 OpenTelemetry。我们的 OSS 团队选择 MARA 这个新兴项目也激发了我们的研究兴趣。在GlueCon 2022大会上，我与 F5 CTO 办公室的架构师 Granville Schmidt 一起讨论了 OpenTelemetry 的现状以及未来值得期待的一些亮点。请观看下方我们的对话视频，深入了解为何 OpenTelemetry 是云原生应用领域的重要资产。
OpenTelemetry 赋能 Observability 2.0
自 2019 年在巴塞罗那 KubeCon 大会上首次亮相以来，OpenTelemetry已经吸引了大批热心的贡献者。从贡献数量来看，它是云原生计算基金会 (CNCF) 的第二大热门项目，其贡献率在近六个月来达到了历史最高。这么多的贡献者表明，OpenTelemetry 已经成熟，开始从早期的采用者（愿意尝鲜）向实用主义者（想要成熟的产品）普及。
OpenTelemetry 的核心是数据 —— 具体来说是更好地理解、排障和改善应用所需的数据和数据流（遥测）。数据只有能在大规模聚合、分析和可视化的情况下才有用。虽然 OpenTelemetry 并没有提供数据可视化的方向，但它让我们不再担忧可以获得哪些数据，而是可以专注于使用数据创造的价值。
OpenTelemetry 能够实现这些数据源之间的自然关联，而不是期望我们自己尝试这种关联。OpenTelemetry 这种跨应用关联事件的能力催生了 Observability 2.0（可观测性 2.0） —— 一种衡量云端应用活动的新基准。关联好的数据增强了我们对应用的了解。以前我们只知道应用是否正在运行，而现在有哪些请求流经我们的应用、它们的路径是什么 —— 我们都一清二楚。
在 OpenTelemetry 之前有两个著名的开源项目：OpenTracing (OT)和OpenCensus (OC)，两者都着力于解决数据跟踪格式的标准化问题，目的是让我们能够轻松获取必要的信息并了解这些信息对现代应用的影响。虽然它们有着相似之处，但也难免会争夺资源，公司往往只能从中挑选一个。2019 年 3 月，为了统一跟踪数据的生成方式和格式，OpenTracing 和 OpenCensus 宣布合并，OpenTelemetry 就此诞生。OpenTelemetry 项目进一步定义了通过与 Traces（链路跟踪）相同的遥测信道获取其他类别的可观测性数据（Metrics 指标和Logs日志）的标准，从而实现更高程度的集成和清晰度。
接下来我们来了解一下 OpenTelemetry 的两个令人惊喜的功能：分布式跟踪和应用智能。
为什么现代应用架构需要分布式跟踪
虽然分布式跟踪已经存在多年，但近十年来的许多变化都增加了对它的需求。我们可以使用Cynefin 框架找出现代应用架构的变化及面临的挑战。
Cynefin 框架描述了如何在从简单到复杂的过程中改变我们的实践。其中的问题在于，我们的演进有两条不同的路线，每条路线都有自己的特点，而试图从简单到复杂直接走捷径往往会造成混乱和不完整的进展。
我们来看看哪些元素决定了现代应用和云原生之旅的路线。在第一条路线（Cynefin 图中的 Y 轴）中，我们拥有通常采用微服务架构的现代应用，其中每个应用都执行着特定的任务。在第二条路线（X 轴）中，我们的复杂环境是短暂的，因为微服务实例会根据需求不断增减，并移动到不同的主机以解决不同的网络问题。
我们还必须考虑亚马逊云科技 (AWS)、Microsoft Azure 和谷歌云平台 (GCP) 等云环境的出现和大规模增长。此类云平台的一大优势是弹性响应 —— 它们能够通过扩展或缩减资源来匹配当前的需求水平。加之受容器编排（最常用的工具是 Kubernetes）的影响，资源的数量和位置随着时间发生变化，混乱开始出现。（即使是这种相对受限的视图也是混乱的，无服务器函数等元素更是会让它雪上加霜。）
在现代架构中，许多分散的组件产生了我们监控和维护应用所需的遥测数据，数据负载无疑是庞大且复杂的。由于我们无法全面控制基础架构和通信路径，因此很难可靠地重现问题或者轻松触发问题。我们需要借助一定的技术来跟踪所有活动和相关元素，以便了解和分析不断变化的环境。
这就是 OpenTelemetry 诞生的意义。
使用 OpenTelemetry 实现分布式跟踪的未来
分布式跟踪引发了一场行业大地震，其中尤为明显的是请求通过 Metrics（指标）生成内部性能视图的方式。通过分布式跟踪，我们可以跟踪许多类型的新指标，但最常见的是与单位时间内的请求数、单位时间内的错误数、聚合请求占用的时间长度（同一时间单位）相关的指标。
Metrics 并非是新鲜事物 —— 它们易于管理、存储和汇总，因此非常适合数学分析。在 OpenTelemetry 中，所有生成 Metrics 的应用都可以通过遥测（传输）层将它们发送到一个公共收集点，从而帮助规范那些松散耦合的服务生成的数据，包括让它们与底层基础架构的数据保持一致。简而言之，OpenTelemetry 可以让 Metrics 的获取和发送变得更简单。
OpenTelemetry 还可以帮助解决时间戳漂移和偏斜问题 —— 这类问题会增加事件关联的难度。OpenTelemetry 为每个请求分配一个TraceId，但数据仍然会受漂移和偏斜的影响，这是云原生架构下经常出现的问题。漂移和偏斜的原因可能在于报告路径具有不同的持续时间，或者不同主机的时钟之间缺乏紧密同步。通过在流量处理期间跟踪组件之间的通信，分布式跟踪允许 OpenTelemetry 无需深度检测相关应用即可衡量各个span—— span 是 trace 的工作单元和构建块。
结合使用这三个信号（遥测类别），我们能够纠正问题并将应用恢复到生产级质量：
说到这儿，我们就又不得不提 Observability 2.0 了。获取 Traces 并立即查看哪些 Metrics 对应哪个 trace 是一项很强大的能力。举例来说，当 Metrics 表明存在问题时，分布式跟踪可让您一直追溯到引发初始问题的特定请求，并跟踪请求执行到了哪个步骤。由于 trace 是由 spans 组成的（按照 spans 发生的顺序），我们可以跟踪请求经历的每个步骤。通过了解整个事件的来龙去脉，包括导火索、问题隐患以及最终后果等等，我们可以在应用中精准发力，重点突破。
这可能听起来很简单，但 OpenTelemetry 的分布式跟踪功能可以充当请求成功和执行时间的代理，帮助我们深入了解用户体验。作为一名用户，我关心的是我的请求；作为一名站点可靠性工程师 (SRE)，我关心的是“聚合”的请求。
OpenTelemetry 可以兼顾两者，并且为了让所有应用的所有必要数据都变得可用，它还赋予了我们从整体到细节、从宏观到微观的分析能力。
利用人工智能和机器学习实现应用智能
OpenTelemetry 的这一新数据流还可以使我们在开发和运营响应中实现自适应和自动化。有了所有这些累积的数据，我们可以让我们的应用变得更智能。F5 目前专注于帮助客户开发和部署我们所说的“感知可控、随需而变的应用”。顾名思义，“感知可控、随需而变”是指应用能够自动和智能地调整其行为，以响应环境中的变化。
这也就不难理解为什么您会在许多解决方案中看到越来越多的人工智能 (AI) 和机器学习 (ML) 元素了。除了是大势所趋之外，这也跟人工智能和机器学习本身就很给力有关，因为现在有足够的数据支撑我们得出关于因果关系的准确结论并设计合适的应对方案。
通过使遥测数据变得易于访问和标准化，OpenTelemetry 可以让“感知可控、随需而变的应用”旅程变得更加容易。随着不同类型的产品开始输出类似的 Metrics，我们可以利用 OpenTelemetry 中已建立的语义约定，更轻松地在请求处理期间关联它们的操作，并将这些信息提供给 ML 和 AI 算法，让应用和基础架构实现动态适应。
当您了解这一切背后的数据科学并确保您的遥测数据与您的 AI 和 ML 相关时，“感知可控、随需而变的应用”的数据驱动性质就可以持续进化、大显身手了。
结语
遥测数据编码对于 OpenTelemetry 用户和使用它作为遥测信道的应用来说都是一个制胜法宝。这种方式可以收集多个来源的数据，并将它们转发到任何兼容的聚合和分析工具。此外，OpenTelemetry Collector解决了厂商自己实施收集器的麻烦，让他们可以专注于增强代码以执行有意义的分析并采取智能行动，并且构建新工具来帮助理解这个复杂而混乱的新世界。事实上，以开源创新为后盾的 OpenTelemetry Collector 蕴藏着巨大的潜能，几乎能够处理当前的所有格式，同时对接未来的新技术。
OpenTelemetry 重点关注我们了解应用所需的主要数据类别，使我们的应用能够对复杂的现代应用世界的性能和问题提供更深入的洞察。通过关联我们的数据并统一语义和标准约定，OpenTelemetry 让我们离现代应用的未来更近了一步。随着项目的不断成熟和采用率的持续增加，OpenTelemetry 无疑是我们深入理解和应用 AI 和 ML 技术、让复杂的问题简单化的有效途径。
如欲进一步了解 NGINX OSS 工程师是如何利用 OpenTelemetry 的，请试用现代应用参考架构（MARA）和示例应用(Bank of Sirius)。
更多资源
想要更及时全面地获取 NGINX 相关的技术干货、互动问答、系列课程、活动资源？
请前往 NGINX 开源社区：
按点赞数排序
按时间排序
点赞 6
浏览 6.3k点赞 1浏览 3.4k点赞 10浏览 4.9k
微信公众号
加入微信群
