OpenTelemetry 简析

Posted 2023-04-06 m0_69526086

• 组件闭环的信息

• 组件间或系统间流动的信息

第一种形态通常可通过 logs 或 metrics 表征，第二种形态就需要 trace 表征，在流动的信息中增加标记。

对于 logs 和 metrics 的区别，可通过它们的操作方法进行理解。

再进一步抽象，可观测性涉及到如下问题：

• 观测数据的数据模型

• 观测数据的采集

• 观测数据的处理

• 观测数据的导出

• 观测数据的使用

• etc.

上述即是 OpenTelemetry 面对的问题域及具体的问题，且将具体的问题限定在：

• 观测数据的数据模型

• 观测数据的采集

• 观测数据的处理

• 观测数据的导出

[](()OpenTelemetry 的解决方案是什么？

---

OpenTelemetry 通过 Spec 规范了观测数据的数据模型以及采集、处理、导出方法，包括 trace、metrics、logs (未来不排除会有新的类型)，参见 [opentelemetry-specification](()。

同时为了方便使用，通过 protobuf 来描述，参见[opentelemetry-proto](()。

基于 Spec，OpenTelemetry 面向观测数据的生成和处理，做了如下的努力：

• 为了方便开发者使用，提供了语言相关的 SDK，如 [opentelemetry-go](()、[opentelemetry-java](()、[opentelemetry-js](() 等，所有支持的开发语言可参见 [官方文档](()

• 为了方便可观测数据的采集、处理、导出，提供了通过配置管理的 Collector 服务，如对接开源项目的 [opentelemetry-collector](()、对接第三方 vendor 的 [opentelemetry-collector-contrib](()

通过下图可直观理解 OpenTelemetry 的组件和工作流：

[](()OpenTelemetry 的历史是什么？

---

从 [A brief history of OpenTelemetry (So Far)](() 可简单了解到，OpenTelemetry 是由两个开源项目合并组成的：

• [OpenCensus](()

• 面向 trace 和 metrics 进行数据模型标准化，并提供采集、处理、导出的工具

• [OpenTracing](()

• 面向 trace 进行数据模型标准化，并提供采集、处理、导出的工具

2019 年 5 月，两个开源项目合并，官方宣布开源 OpenTelemetry 项目。

2021.02，trace spec 达到 1.0 版本，根据官方的成熟度模型 (link，目前 trace 的 s 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 pec 已经达到 stable 级别，metrics 达到了 beta 级别，logs 当前还处在 alpha 级别：

[](()OpenTelemetry 的前景如何？

---

自 OpenTelemetry 推出以来，有越来越多的厂商开始关注和贡献。

从 [opentelemetry-collector-contrib](() 可看出来，厂商的关注重点在于 exporter 部分，将观测数据便利导入到自身的服务中，其中已经包含阿里云自身的 [SLS 产品](()：

对于 receiver 和 processor 环节，相信厂商也会逐步投入更多的精力，如：

• 通过 receiver 和 exporter 的配合，形成观测数据的处理 workflow

• 通过 processor，在观测数据存储前进行规范化处理

对于多云场景，OpenTelemetry 定义的观测数据模型、采集/处理/导出 标准，将有利于用户通过一套可观测性标准对接多种云厂商，避免 vendor 锁定。

即使是面向单一的云 (如云厂商内部的服务)，也不可避免会考虑未来进行开源、与外部共建等，使用社区的可观测性标准可以降低开源成本。同时，可观测性的理念、标准、技术在不断迭代，通过跟进社区，可以更好使用到社区带来的技术红利和影响力。

因此，无论是面对多云场景还是单一的云厂商，采用业界的可观测性标准都是很有必要。

[](()OpenTelemetry 如何使用？

---

[](()核心概念

OpenTelemetry 中的概念比较多，这里列举些常见的概念，方便进行理解：

• 观测数据相关

• Signal

• 观测数据类型，如 trace、metrics、logs

• Instrument

• 可认为是某种 Signal 的实例

• OpenTelemetry 自身项目相关

• API

• OpenTelemetry Spec 的形式化描述，如 [opentelemetry-proto](()

• SDK

• 面向不同开发语言的 API 实现

• Contrib Packages

• 与具体的开源项目或 vendor 产品相关的实现

• 使用的组件相关

• Components

• Receivers

• 接收观测数据的组件

• Processors

• 处理接收到的观测数据的组件

• Exporters

• 将观测数据导出的组件，如导出到开源项目 Prometheus 或云厂商服务中

• Extensions

• 不参与观测数据的处理，辅助相关处理组件的运行，如健康检测、服务发现等

• Services

• 表征配置的哪些组件需要运行，如 receivers / processors / exporters / extentions

• Collector

• 可认为是 receivers / processors / exporters / extentions / services 组成的整体

• Controller

• 用于开发者开发的应用中，作用可等同于 receivers / processors / exporters 组成的整体

[](()golang demo

笔者写了一个 golang demo，用来演示：

• APP 中如何生成 trace / metrics 数据

• APP 中使用 stdout controller 来采集、处理、打印 trace / metrics 数据

• APP 中通过 otlp controller 采集 trace / metrics 数据，并导出到外部运行的 collector 中

• 本地独立运行一个 collector 服务，接收 otlp controller 推送的 trace / metrics 数据，并将其导出到本地文件和阿里云 SLS 中

demo 参见：[https://github.com/flyer103/otel-demo](()

具体的使用方法参见 demo 的 README.md，下述简单描述下思路。

cmd/app/server.go 文件描述了 OpenTelemetry 的使用逻辑，分成两部分：

1. 初始化并运行全局的 controller，用来在 APP 内部 receive / process / export 观测数据，或将 APP 内的观测数据推送到外部

2. APP 内按照业务需求生成 metrics 和 trace

OpenTelemetry - 云原生的观测技术框架

OpenTelemetry 是什么

OpenTelemetry 是一个实现应用行为和性能观测的框架，目前已成为 CNCF 应用的事实标准。OpenTelemetry 定义了一组工具，帮助开发者生成各维度基础数据和对数据进行统计分析，支持多种技术栈。

值得一提的是，OpenTelemetry 目前同样是一个 CNCF 孵化项目，Github 地址 https://github.com/open-telemetry，感兴趣的同学可以学习源码。

OpenTelemetry 的特性

Traces、Metrics、Logs

支持 Traces、Metrics、Logs 三类数据的收集和导入分析工具。

简单易用

支持 Spring、ASP.NET Core 等等一系列主流开发框架。

开源，云服务商

100% 开源，主流云服务商务都已支持，这里 https://opentelemetry.io/vendors/ 有一个所有支持 OpenTelemetry 的云厂商列表。

OpenTelemetry 使用入门

这里给出了 OpenTelemetry 的各技术栈使用手册，非常详尽。
https://opentelemetry.io/docs/instrumentation/

大家可以使用最主流的 Java 开发语言体验一下，这个例子实现了一个 RPC 调用的追踪，细节大家可以实践一下文档中给出的示例。

OpenTelemetry 的未来

个人认为 OpenTelemetry 的未来还是非常光明的，主要是由于这个方向是未来的趋势所在。当前对应用的运维方式主要是来自于 SRE 的定义，这种定义往往是普适的、滞后的，意味着和业务往往是脱节的。所以，OpenTelemetry 其实是把运维方式的定义能力抽象出来，让最懂业务的人来设定观测应用的哪些维度以及观测的方式，SRE 只需要建设好观测系统的基础设施即可。当然，一些普适的观测规则模板的维护还是 SRE 的日常工作。