OpenTelemetry 介绍

OpenTelemetry 可以用于从应用程序收集数据。它是一组工具、API 和 SDK 集合，我们可以使用它们来检测、生成、收集和导出遥测数据（指标、日志和链路追踪），以帮助分析应用的性能和行为。

为什么需要分布式追踪

随着云计算、微服务架构和日益复杂的业务需求的兴起，越来越需要对软件和基础设施可观测性的需求。特别是在微服务架构中，每个请求最终可能会经过数个甚至数十个微服务）并在其间进行多次网络调用。

参照下图Uber 2018 年的微服务架构，该架构拥有 3000 多个服务。

Uber’s microservice architecture circa mid-2018 from Jaeger

在这种复杂的系统中，仅靠传统的日志和指标监控数据很难实现一览全局的视角，排除故障会非常困难。

指标：在监控/指标平台中，组件（例如服务、主机）是被观察的基本单元。我们可以通过监控/指标平台查询有关该单元随着时间推移的实际情况。例如，该服务在特定时间范围内的运行状况/吞吐量/错误率是多少？
日志：对于日志，被观察的基本单位是事件——例如，每当代码执行期间发生事件时，就打印一些信息。这些“事件”是开发人员在编写代码时主观定义的。使用日志的问题在于它们之间都是相互脱节的，每个组件都以自己的形式单独打印日志消息，没有简单的方法将它们联系在一起，使其更有意义。

相比之下，分布式链路追踪观察的是单个请求穿越多个组件时的情况。这使我们能够顺着请求链路查询整个分布式系统的问题，并了解复杂的互连系统中发生了什么。

why need tracing

借助分布式链路追踪能够帮助我们在复杂的分布式系统中快速定位问题、排除故障。

OpenTelemetry 演进历史

OpenTelemetry History

Google 2010年发布的 Dapper 论文是分布式链路追踪的开端
2012年 Twitter 开源了 Zipkin。
2015年 Uber 发布了 Jaeger 的开源版本。目前 Zipkin 和 Jaeger 仍然是最流行的分布式链路追踪工具之一。
2015年 OpenTracing 项目被 CNCF 接受为它的第三个托管项目，致力于标准化跨组件的分布式链路追踪。
2017年 Google 将内部的 Census 项目开源，随后 OpenCensus 在社区中流行起来。
2019年初，两个现有开源项目：OpenTracing 和 OpenCensus 被宣布合并为 OpenTelemetry 项目。
2021年， OpenTelemetry 发布了V1.0.0，为客户端的链路追踪部分提供了稳定性保证。
2023 年对于 OpenTelemetry 来说是一个里程碑，因为其三个基本信号，链路追踪、指标和日志，都达到了稳定版本。

如何实现分布式链路追踪

把请求链路中进行的每个网络调用都会被捕获并表示为一个跨度。

分布式链路追踪工具将唯一的链路追踪上下文（trace ID）插入到每个请求的标头中，并借助各种实现工具确保链路追踪上下文在整个请求链路中传播。

OTel TraceID

什么是OpenTelemetry

对于 OpenTelemetry，不同的角色（Dev和Ops）侧重点也不尽相同。

如果你的角色是Dev，那么你可能更关注如何通过编写代码使程序获得可观测性。

如果你的角色是Ops，那么你可能更关注如何从多个服务中收集 traces、metrics 和 logs 数据，并将它们发送到可观测后台。

OpenTelemetry，也称为 OTel，是一个与供应商无关的开源可观测性框架，用于检测、生成、收集和导出遥测数据，如链路追踪（traces）、指标（metrics）和日志（logs）。

作为一个行业标准，OpenTelemetry 得到了40多个可观测性供应商的支持，被许多库、服务和应用程序集成，并被众多终端用户采用。

OTel 图解

OTLP

开放遥测协议（OTLP）规范描述了遥测源、中间节点（如采集器和遥测后端）之间的遥测数据编码、传输和交付机制。

OTLP 是在 OpenTelemetry 项目范围内设计的通用遥测数据传输协议。

Collector

OpenTelemetry Collector 提供了一种与供应商无关的接收、处理和导出遥测数据的方式。它无需运行、操作和维护多个代理/收集器。它具有更好的可扩展性，支持向一个或多个开源或商业后端发送开源可观测性数据格式（如 Jaeger、Prometheus、Fluent Bit 等）。本地收集器代理是仪器库导出遥测数据的默认位置。

OTel Collector