OpenTelemetry 简称 OTel, 是 CNCF ( Cloud Native Computing Foundation,云原生计算基金会,是一个开源软件基金会,致力于云原生技术的普及和可持续发展) 的一个可观测性项目。
OpenTelemetry 旨在提供可观测性领域的标准化方案,解决遥测数据的数据建模、采集、处理、导出等标准化问题,并能够将这些数据发送到你选择的后端(开源或商业均可)。这样你就可以建立不被供应商锁定的可观测,灵活地更改后端,不需要再次更改代码,重新进行插桩(Instrument)了。
OpenTelemetry 架构
OpenTelemetry 主要包括了下面三个部分:
1、跨语言规范
跨语言规范描述了所有实现的跨语言要求和数据模型,包括遥测客户端内部实现所需要的标准和定义,也包含与外部通信时需要实现的协议规范。跨语言规范主要包含了下面几类。
- API:定义用于生成和关联追踪、指标和日志的数据类型和操作。
- SDK:定义 API 特定语言实现的要求,同时还定义配置、数据处理和导出等概念。
- 数据:定义遥测后端可以提供支持的 OpenTelemetry 协议 (OTLP) 和与供应商无关的语义约定。
只有 OTLP 是 OpenTelemetry 官方原生支持的格式。OTLP 的数据模型定义是基于 ProtoBuf 完成的。
2、API / SDK
API 可以让开发者对应用程序代码进行插桩(Instrument),而 SDK 是 API 的具体实现,是和开发语言相关的。
在软件业内,在应用中进行插桩是指将系统状态数据发送到后端,例如日志或者监控系统。发送的数据叫做 Telemetry,也就是遥测数据,包括日志、指标以及追踪等。这些数据记录了处理特定请求时的代码行为,可以对应用系统的状态进行分析。
插桩有两种方式,一是通过手动增加代码生成遥测数据,二是以探针的方式自动收集数据。
每种方案都有特定的、自定义的步骤来产生和转移符合产品后端存储的遥测数据,这就带来了工具或者厂商的绑定性,如果想把遥测数据发送到其他产品,就不得不使用其他的插件库重复整个插桩过程。而这正是 OpenTelemetry 想要解决的问题。
OpenTelemetry 为每种语言提供了基础的监测客户端 API 和 SDK。这些包一般都是规范里的定义,又结合了语言自身的特点,实现了在客户端采集遥测数据的基本能力。
3、OpenTelemetry Collector
OpenTelemetry 架构的第三部分是接收、转换和导出遥测数据的工具(OpenTelemetry Collector),这是 OpenTelemetry 组件中最重要的部分,将其简称为 Collector。
Collector 针对如何接收、处理和导出遥测数据提供了与供应商无关的实现,消除了运行、操作和维护多个代理 / 收集器的需要,它支持将开源可观测性数据格式(例如 Jaeger、Prometheus 等)发送到一个或多个开源或商业后端。
在 Collector 的内部,有一套负责接收、处理和导出数据的流程被称为 Pipeline。 每个 Pipeline 由下面三部分组件组合而成。
- Receiver:负责按照对应的协议格式监听和接收遥测数据,并把数据转给一个或者多个 Processor。
- Processor:负责加工处理遥测数据,如丢弃数据、增加信息、转批处理等,并把数据传递给下一个 Processor 或者一个或多个 Exporter。
- Exporter:负责把数据发送给下一个接收端(一般是指后端),比如将指标数据存储到 Prometheus 中。
从部署的角度来说,Collector 有下面两种模式。
- 第一种模式可以统称为 Agent 模式。它是把 Collector 部署在应用程序所在的主机内(在 Kubernetes 环境中,可以使用 DaemonSet),或者是在 Kubernetes 环境中通过边车(Sidecar)的方式进行部署。这样,应用采集到的遥测数据可以直接传递给 Collector。
- 另一种模式是 Gateway 模式。它把 Collector 当作一个独立的中间件,应用会把采集到的遥测数据往这个中间件里传递。
此文章为3月Day6 学习笔记,内容来源于极客时间《深入浅出可观测性》,推荐该课程。