可观察性是运行云原生应用程序的关键,应用程序功能源于在多个位置运行的大量微服务之间的交互。 微服务应用程序的松散耦合特性可能意味着每个微服务都以自己的方式报告其活动。 如果没有一个可以编译和关联遥测数据的工具,那么从头到尾跟踪请求的处理过程就会变得非常困难(甚至不可能),而这对于故障排除至关重要。
在寻找多功能可观察性工具时, NGINX 现代应用参考架构(MARA)项目背后的团队选择了 OpenTelemetry 。 我们的 OSS 团队选择了这个新兴项目,我们希望进一步深入研究。 在GlueCon 2022上,我与 F5 首席技术官办公室架构师 Granville Schmidt 聚在一起讨论了我们为何对 OpenTelemetry 的现状和未来产品感到兴奋。 您可以在下面观看我们的对话,并在这篇博客中进一步了解为什么 OpenTelemetry 对云原生应用领域来说是一笔巨大的财富。
OpenTelemetry在巴塞罗那的 KubeCon 2019 上首次发布,吸引了一批热情的贡献者。 就贡献数量而言,它是云原生计算基金会 (CNCF) 中第二受欢迎的项目,并且在过去六个月中,贡献率一直高于以往任何时候。 如此大量的贡献者表明 OpenTelemetry 已经成熟,并且开始跨越早期采用者(愿意走在时代前列)和实用主义者(渴望成熟产品)之间的鸿沟。
OpenTelemetry 专注于数据——具体来说,是最好地理解、排除故障和改进我们的应用所需的数据和数据流(遥测)。 数据只有能够大规模地聚合、分析和可视化才有用。 虽然 OpenTelemetry 没有提供如何可视化数据的指导,但它让我们不再担心我们可以获得什么数据,而是专注于我们可以用这些数据做什么。
OpenTelemetry 还实现了这些数据源之间的自然关联,而不是期望我们自己尝试这种关联。 OpenTelemetry 跨应用程序关联事件的能力将引领我们走向 Observability 2.0——衡量云端应用活动的新基准。 数据对我们来说已经是关联的,这改变了我们看待应用空间的方式。 我们不再仅限于了解应用程序是否正在运行;我们现在可以了解任何请求通过我们的应用程序所采用的路径。
在 OpenTelemetry 之前有两个值得注意的开源项目: OpenTracing(OT)和OpenCensus(OC) 。 这两者都面临着标准化跟踪数据格式的挑战,以便我们能够获得必要的信息并了解它如何影响我们的现代应用程序。 虽然每个项目都有相似之处,但它们会争夺资源,因此公司通常只能选择一个项目。 2019 年 3 月,这两个项目宣布合并为 OpenTelemetry ,目标是统一跟踪数据的生成和格式化方式。 OpenTelemetry 项目正在进一步定义通过与跟踪相同的遥测通道获取其他类别的可观察性数据(指标和日志)的标准,从而实现更高的集成度和清晰度。
接下来我们来看看OpenTelemetry的两个令人兴奋的功能方面:分布式跟踪和应用智能。
虽然分布式跟踪已经存在多年,但过去十年的许多变化增加了对它的需求。 使用Cynefin 框架,我们可以强调我们现在在现代应用中面临的一些变化和挑战:
Cynefin 框架说明了我们如何在从简单到复杂的过程中改变我们的实践。 挑战在于,我们的运动沿着两条不同的道路前进,每条道路都有自己的特点,而试图直接从简单到复杂走捷径往往会导致混乱和不完整的进展。
让我们确定哪些元素在我们的现代应用和云原生之旅中创建了路径。 在我们的第一条路径(Cynefin 图中的 Y 轴)中,我们有现代应用程序,它们通常是微服务架构,其中每个应用程序都执行特定的工作。 在第二条路径(X 轴)中,我们复杂的环境是短暂的,因为微服务实例会根据需求启动和关闭,并根据网络问题移动到不同的主机。
我们还必须考虑到亚马逊网络服务 (AWS)、Microsoft Azure 和谷歌云平台 (GCP) 等云环境的出现和大规模增长。 这种云的一个优点是弹性响应——扩大或收缩资源以满足当前的需求水平。 随着容器编排(最常用的是 Kubernetes)的影响,我们开始看到混乱的行为,因为资源的数量和位置随着时间的推移而发生变化。 (即使这种相对受限的视图也是混乱的,而无服务器功能等元素会使其变得更加混乱。)
在现代架构中,有许多独立的部分产生我们监控和维护应用程序所需的遥测数据,数据负载巨大且复杂。 由于我们无法完全控制基础设施和通信路径,因此问题可能无法可靠地重复出现或不易引发。 我们需要能够追踪所有活动和相关元素的技术,以便我们能够了解和分析不断变化的环境。
这就是 OpenTelemetry 的作用所在。
分布式跟踪正在引起行业的巨大变化,尤其是在请求如何通过指标生成性能的内部视图方面。 通过分布式跟踪,我们可以跟踪多种类型的新指标,但最常见的是与每单位时间的请求数、每单位时间的错误数以及聚合请求在该时间单位上占用的时间相关的指标。
指标已经存在了一段时间——它们易于管理和存储、易于聚合,并且适合数学分析。 在 OpenTelemetry 中,所有生成指标的应用程序都可以通过遥测(传输)层将它们发送到一个公共收集点,这有助于协调来自生成数据的松散耦合服务的数据。 这包括与底层基础设施的协调。 简而言之,使用 OpenTelemetry,获取和发送指标变得更加容易。
OpenTelemetry 还可以帮助解决时间戳漂移和偏差的问题,这个问题使得事件关联变得困难。 OpenTelemetry 为每个请求分配一个TraceId ,但数据仍然会受到漂移和偏差的影响,这在云原生架构中经常出现。 漂移和偏差可能是由于报告路径的持续时间不同或各个主机之间的时钟缺乏紧密同步造成的。 通过在流量处理期间跟踪组件之间的通信,分布式跟踪允许 OpenTelemetry 测量单个跨度(工作单元和跟踪的构建块),而无需对相关应用程序进行深度检测。
结合这三种信号(遥测类别)使我们能够纠正问题并使我们的应用恢复到生产质量:
这就是我们回到可观察性 2.0 的地方。 获得跟踪并立即看到哪些指标与哪些跟踪相对应,这种能力赋予了我们很大的权力。 例如,当指标表明存在问题时,分布式跟踪可以让您一路回到导致初始问题的特定请求,并跟踪请求履行的每个步骤的进度。 由于我们的追踪是由按发生顺序排列的跨度组成的,因此我们可以跟踪请求在整个旅程中的每个步骤。 了解发生了什么,按照什么顺序——从最初的事件到指示的问题,一直到最终的结果——使我们能够准确地定位应用程序中需要关注的“位置”。
尽管听起来很简单,但 OpenTelemetry 的分布式跟踪功能可以让我们深入了解用户的体验,作为请求成功和执行时间的代理。 作为用户,我关心我的请求。 作为站点可靠性工程师 (SRE),我关心聚合请求。 OpenTelemetry 为我提供了这两种功能,以及从汇总深入到细节的能力,因为它旨在使所有需要的数据在所有应用程序中可用。
OpenTelemetry 的这一新数据流还使我们能够在开发和运营响应中实现自适应和自动化。 利用这些累积的数据,我们可以使我们的应用更加智能。 F5 目前专注于帮助我们的客户开发和部署所谓的“自适应应用”。 自适应应用程序正如其名称所示:应用可以根据环境的变化自动且智能地调整其行为。
这就是为什么你会在各种解决方案中看到越来越多的人工智能(AI)和机器学习(ML)。 但这不仅仅是因为它们是流行术语——人工智能和机器学习之所以有用,是因为我们现在有足够的数据来得出关于因果关系的准确结论并设计适当的反应。
通过使遥测数据可访问且标准化,OpenTelemetry 使得自适应应用程序的旅程变得更加容易。 随着不同类型的产品开始输出类似的指标,通过利用 OpenTelemetry 中已建立的语义约定,在请求处理期间关联它们的操作并将该信息提供给 ML 和 AI 算法变得更加容易,以使应用和基础设施能够动态适应。
当您理解这一切背后的数据科学并确保您的遥测数据与您的 AI 和 ML 相关时,自适应应用程序的数据驱动特性就可以发展和发光。
编码遥测对于 OpenTelemetry 的用户和使用它作为遥测通道的应用来说都是一个明显的胜利。 可以从多个来源收集数据并转发到任何兼容的聚合和分析工具。 此外, OpenTelemetry Collector使供应商无需自己实现收集器。 相反,他们可以专注于增强他们的代码以执行有意义的分析并采取智能行动,并可以构建新的工具来帮助理解这个复杂而混乱的新世界。 事实上,在开源创新的支持下,OpenTelemetry Collector 能够与几乎所有现有格式协同工作,同时将该技术与未来联系起来。
OpenTelemetry 专注于我们了解应用所需的主要数据类别,使我们的应用程序能够更深入地了解复杂的现代应用世界的性能和问题。 通过关联我们的数据、符合语义和标准约定,OpenTelemetry 使得现代应用的旅程更加平易近人。 随着项目不断成熟和采用率不断增长,OpenTelemetry 显然有助于我们更深入地理解并应用 AI 和 ML 技术使复杂性变得易于理解。
要了解有关 NGINX 的 OSS 工程师如何使用 OpenTelemetry 的更多信息,请尝试现代应用程序参考架构和示例应用(Bank of Sirius)。
“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息,请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”