云原生内容分享(四)：OpenTelemetry 重塑云原生的可观测性

目录

一、前言

二、OpenTelemetry 的出现

三、OpenTelemetry 架构

四、收集、转换、转发遥测数据的工具Collector

五、基于 OpenTelemetry && Kubernetes  的解决方案

六、基于 Kubernetes 的 OpenTelemetry 实现

6.1、通过 Helm 的方式进行部署

6.2、通过 kubectl 的方式进行部署

七、来点实战

7.1、集成OpenTelemetry SDK

7.2、部署OpenTelemetry Collector

八、数据处理与可视化

九、总结

---

一、前言

随着云计算、微服务和容器化技术的快速发展，现代应用程序的架构变得越来越复杂。这种复杂性为运维人员和开发者带来了新的挑战，特别是在监控、追踪和诊断分布式系统的行为和性能方面。

传统的监控工具和框架往往专注于单一的领域，如日志记录、度量收集或分布式追踪。然而，这些工具之间的互操作性和数据标准化程度有限，导致在大规模、多语言的云原生环境中实施全面可观测性变得困难且成本高昂。

二、OpenTelemetry 的出现

在此背景下，OpenTelemetry 应运而生。作为一项由行业领导者和开源社区共同推动的倡议，OpenTelemetry 旨在提供一个统一、标准化的框架，用于收集、处理和导出跨多种编程语言和平台的可观测性数据。

OpenTelemetry 的诞生是对现有问题的一种回应，它整合了先前两个重要的开源项目 OpenTracing 和 OpenCensus 的经验和最佳实践。这两个项目分别在分布式追踪和度量收集方面做出了重要贡献，但各自存在的碎片化和不兼容性问题限制了它们在复杂环境中的应用。

通过合并这两个项目并引入更广泛的社区支持，OpenTelemetry 致力于创建一个通用的、 vendor-neutral 的解决方案，使得开发人员和运维人员能够更容易地实现端到端的可观测性，无论他们的应用程序是基于何种语言、运行在何种环境之上。

三、OpenTelemetry 架构

OpenTelemetry（也称为 OTel）是一个开源可观测性框架，由工具、API 和 SDK 的集合组成。

要了解 OTel 的功能，了解可观测性会有所帮助。松散定义的可观测性是指根据系统生成的外部数据（通常是日志、指标和跟踪）的知识来了解系统内部发生的情况的能力。

拥有如何收集和发送可观测性数据的标准格式是 OpenTelemetry 发挥作用的地方。作为云原生计算基金会 （CNCF） 的孵化项目，OTel 旨在提供一套统一的与供应商无关的库和 API，主要用于收集数据并将其传输到某个地方。自项目启动以来，包括 Dynatrace 在内的许多供应商都加入了进来，帮助简化和更易用的丰富数据收集工作。

为了理解为什么可观测性和 OTel 的可观测性方法如此重要？那让我们先深入地了解遥测数据本身：

四、收集、转换、转发遥测数据的工具Collector

在 Tracing 实践中有一个原则，遥测数据收集过程需要与业务逻辑处理正交。意思就是遥测数据收集并传递到遥测后端服务的过程不占用业务逻辑的信道/线程，尽量较少监测客户端对原有业务逻辑的影响。Collector是基于这个原则实践的产物。

代码仓库：opentelemetry-collector

从架构层面来说，Collector 有两种模式。一种是把 Collector 部署在应用相同的主机内（如K8S的DaemonSet），或者部署在应用相同的 Pod 里面 （如K8S中的Sidecar），应用采集到的遥测数据，直接通过回环网络传递给 Collector。这种模式统称为 Agent模式。

另一种模式是把 Collector 当作一个独立的中间件，应用把采集到的遥测数据往这个中间件里面传递。这种模式称之为 Gateway 模式。

两种模式既可以单独使用，也可以组合使用，只需要数据出口的数据协议格式跟数据入口的数据协议格式保持一致。