无论编程语言、基础设施或运行时环境如何,OTel 均可简化遥测数据的采集方式,并支持开发人员为任何可观测性后端生成、收集和导出标准化遥测数据。这一标准化框架可加强并扩展可观测性功能,并为 IT 和 DevOps 团队提供更高的灵活性。
OTel 在应用程序、系统和设备以及后端解决方案之间实现,存储空间和可视化有意留给其他工具,让组织可以自由选择最适合自己的工具。
可观测性是指通过分析系统的外部输出来深入了解系统内部运作的能力。在 IT 运营 (ITOps) 和云计算中,遥测数据(例如日志、指标和跟踪)用于评估系统性能和健康状况。DevOps 专业人员依靠仪器化(向应用程序和系统添加代码以生成和捕获遥测数据)来创建可观测系统。
在混合云和多云环境、基于微服务的应用程序、Kubernetes 容器和当前计算环境的其他功能的现代环境中工作时,这种检测通常是一项复杂的工作。这些分布式系统及其包含的各种编程语言和运行时,为后端存储空间、可视化和分析提供了复杂的检测、收集和导出阵列。
为全面了解网络服务和应用程序性能,工程师必须针对整个基础设施中的应用程序和系统配置自定义检测工具。OpenTelemetry 有助于解决这一问题。
OTel 提供收集和传输可观测性数据的标准方法,有助于简化分布式系统中的监控。它使用供应商中立的统一库和 API 来收集遥测数据并将其发送到后端平台。通过采用 OpenTelemetry,团队可以跨复杂系统统一收集和处理遥测数据,无论其管理哪些应用程序或使用哪种可观测性工具。
所用的仪器化代码差异很大。此外,由于没有一家商业供应商提供能够从网络上的每个应用程序和服务中收集数据的工具,因此公司很难以不同的语言和格式收集数据或更改后端。
例如,如果开发团队想要切换后端工具,他们必须完全重新检测代码并配置新代理,以将遥测数据发送到新服务器。此外,这种分散的方法造成了数据孤岛和混乱,加大了故障排除和有效解决性能问题的难度。
OpenTelemetry 代表了可观测性工具的重大进步,因为它实现了遥测数据的收集、分析和传输到后端平台的方式的标准化。它提供了基于社区驱动标准的开源解决方案,用于收集有关系统行为和安全性的数据,帮助团队简化分布式生态系统中的监控和可观测性。因此,OTel 为企业提供了一种开放、一致的方法来收集来自网络应用程序和服务的关键数据。
OpenTelemetry 通过将 OpenTracing 和 OpenCensus 的分布式跟踪功能组合到一个工具中而创建。OpenTracing 是云原⽣计算基⾦会 (CNCF) 设计的⼀个开源项⽬,旨在为⼯程师提供供应商中⽴的 API,⽤于向应⽤程序添加分布式跟踪检测。它建立了一组语义约定,以帮助确保遥测数据的一致性。
但是,与 OpenTelemetry 不同,OpenTracing 本身并不是一个跟踪实现方法。相反,它提供了跟踪系统可以实施的接口,以最大限度地提高跨平台的兼容性。OpenTracing 是一个已经不复存在的项目(现在鼓励用户迁移到 OpenTelemetry),但各种软件和跟踪解决方案仍然依赖于其 API。
OpenCensus 是一组由 Google 开发的检测工具库,可用于收集应用程序指标和进行分布式跟踪,将数据实时导出到不同的后端。它采用统一的传播标签和元数据采集数据,这一概念现已作为“资源”存在于 OpenTelemetry 中。
借助 OpenCensus,应用程序可以根据其特定要求导入和导出数据,确保如何灵活地将指标和跟踪发送到可观测性后端。OpenCensus 尚未像 OpenTracing 那样正式停产;它仍会收到定期维护和安全更新。但是,活跃开发已在很大程度上转移到 OpenTelemetry。
这两个项目都旨在解决同一个问题。当时,开发团队没有标准方法来检测代码并将遥测数据传输到后端可观测性工具。
不过,这两个项目都无法单独解决这个问题。因此,CNCF 赞助了 OpenTelemetry 项目,结合了每个解决方案的最佳功能。OpenTelemetry 将 OpenTracing 的 API 标准化和 OpenCensus 的数据收集能力相结合,为将遥测数据发送、收集和传输到后端可观测性平台提供单一、统一的平台。
运⾏快速、⾼可⽤性⽹络和应⽤程序的⼀个关键部分是实现全栈可观测性(或可见性),这需要访问遥测数据。可观测性解决方案收集、监控和分析遥测数据以确定系统健康,然后为 IT 团队提供可操作的洞察分析以进行修复和优化。
为了更深入地了解 OpenTelemetry,让我们深入研究什么是遥测数据以及组织使用该数据的方式。OpenTelemetry 支持特定的数据类型,即从日志、指标和跟踪(通常称为“可观测性的三大支柱” )中收集的输出。
日志详细记录了环境中发生的每个事件或行动。日志可提供事件内容、发生时间及网络位置等详细信息,从而为团队提供用于故障排除、调试和取证分析的宝贵信息。
日志可通过详细说明设备配置变更、身份验证失败和连接中断等系统事件,揭示问题的根本原因。
跟踪捕获整个网络的数据流,针对数据包跨越多个设备和系统时的路径及行为获取洞察分析,对于了解分布式系统和诊断延迟问题至关重要。
利用数据跟踪,IT 团队能够查看端到端交易的全过程,以便在复杂的多层次环境中准确定位路由延迟和故障。
OpenTelemetry 依赖多个组件和流程来成功收集数据,包括:
API 是一组规则或协议,可支持软件应用程序相互通信,以交换数据、特性和功能。
OpenTelemetry 可为 Java、Ruby、JavaScript、Python 和其他语言提供语言特定的 API,开发人员可以使用这些 API 来检测应用程序,以收集遥测数据。OpenTelemetry API 将应用程序与网络基础设施分离,使团队能够灵活地使用与其检测代码匹配的任何端点。
OpenTelemetry SDK 可支持工程师配置和定制 API 行为。SDK 在 API 和收集器之间构建桥梁,同时将常见库人工检测与应用程序人工检测相连接。
OTel 为⼀系列编程语⾔提供 SDK,因此开发⼈员可以使⽤ OTel API ⽣成和导出特定于其所选语⾔和后端的遥测数据。OTel SDK 还支持 OpenTelemetry 社区尚未涵盖的内部框架的自定义检测。
收集器是一种代理,从配备 OpenTelemetry 的应用程序收集遥测数据。收集器由接收器、处理器、聚合器和导出器组成,可充当供应商中立的中介,从应用程序接收数据并将其转发到可观测性平台或其他目的地进行分析。
OpenTelemetry 收集器支持 contrib 包,因此能够采集多种格式的数据(包括 OpenTelemetry Protocol (OTLP)、Prometheus 和 Jaeger),并将其导出到各种后端,有时甚至是同时导出(用于冗余)。Contrib 包是第三方扩展,以子模块格式为开发团队提供检测、采样器、传播器和资源检测器。
收集器还可以在导出遥测数据之前对其进行处理和筛选,以优先交付最重要的数据并加速故障排除和调试过程。
导出器是收集器的一部分,负责将应用程序遥测数据发送到一个或多个指定的可观测性后端。收集器管理整体数据流,而导出器优先考虑将数据向外传输到目的地。
OpenTelemetry 数据导出器将仪器化与后端配置解耦,并将数据转换为适合每个可观测性平台的格式(例如,将跟踪转换为 Zipkin 协议)。这些动态使收集器能够将相同的遥测数据发送到多个后端,从而更容易更改目的地,而无需改变代码的仪器化逻辑。
自动仪器化提供现成的库和框架,使应用程序能够自动生成遥测数据,只需很少或无需更改代码。此过程简化开发人员的仪器化工作,从而减少(有时甚至消除)手动编码任务。
然而,与手动检测相比,自动检测对特定类型的数据收集提供的控制可能较少。自动检测的广度还会根据语言运行时、计算环境和社区对可观测性框架的支持程度而有所不同。
OpenTelemetry 的工作原理是结合 API、SDK、收集器和自动仪器化流程,从而提取数据并将其发送到目标系统。
首先,DevOps 团队使用 OTel API 检测应用程序代码,并指定要收集哪些指标、跟踪和日志以及如何进行收集。OTel SDK 收集器收集数据并准备用于处理和导出,然后对数据进行采样、过滤,并将数据与依赖项和其他数据源关联起来。
当处理后的数据被正确格式化后,SDK 将其分组为基于时间的批次(如有必要,将在其中进行更多的过滤)并将其发送到指定的后端系统。
OpenTelemetry 的主要目标是收集和导出遥测数据并增强可观测性,同时为组织提供一种工具,以促进供应商中立性以及平台和工具集成。它帮助 DevOps 团队和站点可靠性工程师 (SRE) 管理和调试应用程序和系统,以便他们能够做出更明智的决策并在业务需求发生变化时保持敏捷。
OTel 的优势包括: