OpenTelemetry-1.介绍

1.是什么

2.为什么使用 OpenTelemetry

3.数据类型

Tracing

Metrics

Logging

Baggage

4.架构图

5.核心概念

6.相关开源项目

编辑

7.分布式追踪的起源

8.百花齐放的分布式追踪

Zipkin

Skywalking

Pinpoint

Jaeger

OpenCensus

OpenTracing

9.Opentelemetry的诞生

10.Opentelemetry的目标

1.是什么

开源的
受到可观测领域行业领导者的采用和支持
是一个 CNCF 孵化项目, 由 OpenTracing 和 OpenCensus 项目合并而成。
与供应商无关的

OpenTelemetry 包括可观测性的三个支柱：追踪、指标和日志。（本文将重点关注追踪）

分布式追踪是一种跟踪服务请求在分布式系统中从开始到结束的方法。
指标是对一段时间内活动的测量，以便了解系统或应用程序的性能。
日志是系统或应用程序在特定时间点发生的事件的文本记录。

OTLP 协议: OTLP 是 OpenTelemetry 中比较核心的存在, 在遥测数据及 Collector 之间制定了包括编码 (encoding)、传输 (transport)、传递 (delivery) 等协议。
Instrumentation: 采集器

以 Dapper 的定义作为基准, 一个标准的分布式 Trace 示例如下图所示。一个 Trace 是由 Span 构成的有向无环图 (DAG), Span 是一个最小粒度的调用, 既可以指代一个程序块执行, 也可以指代一次 HTTP 等应用协议的远程调用。

2.为什么使用 OpenTelemetry

在云原生技术堆栈中, 分布式和多语言架构是常态。随着云计算、微服务架构和日益复杂的业务需求的兴起，越来越需要对软件和基础设施可观测性的需求。特别是在微服务架构中，每个请求最终可能会经过数个甚至数十个微服务）并在其间进行多次网络调用。在这种复杂的系统中，仅靠传统的日志和指标监控数据很难实现一览全局的视角，排除故障会非常困难。

3.数据类型

Opentelemetry 采集的信息包括可观测的三支柱 Tracing、Metrics、Logging, 其次还包括 Baggage。Baggage 类似与 OpenTrace 中 Baggage, Opentelemetry 将它从 trace 中独立了出来。目前状态: Traces 和 Baggage 已进入稳定状态, Metrics 也大部分完成, 而下一将在 Logs 上逐步发力。值得一提的是 Metrics 中的 Exemplars 的情况, 目前在 Java SDK 中已经实现, 而在 Go SDK 中还未支持。

Tracing

OpenTelemetry 追踪系统是基于 OpenTracing 和 OpenCensus。这两个系统, 以及流行的 Zipkin 和 Jaeger 项目, 都是基于谷歌开发的 Dapper 追踪系统。OpenTelemetry 可以将这些项目兼容到一个系统中。

Metrics

度量指标 (metric) 是一个很大的话题, 包含各种各样的方法和实现。OpenTelemetry 度量信号可以与 Prometheus 和 StatsD 完全兼容。

Logging

OpenTelemetry 结合了高度结构化的日志 API 和高速日志处理系统。现有的日志 API 可以连接到 OpenTelemetry, 避免了对应用程序的重新测量。目前这部分尚发展阶段

Baggage

OpenTelemetry Baggage 是一个简单但通用的键值系统。一旦数据被添加为 Baggage, 它就可以被所有下游服务访问。这允许有用的信息, 如账户和项目 ID, 在事务的后期变得可用, 而不需要从数据库中重新获取它们。例如, 一个使用项目 ID 作为索引的前端服务可以将其作为 Baggage 添加, 允许后端服务也通过项目 ID 对其跨度和指标进行索引。这信息添加到了 http header 中, 进行上下文传递, 因此每增加一个项目都必须被编码为一个头, 每增加一个项目都会增加事务中每一个后续网络请求的大小, 因此不建议在将大量的非重要的信息添加到 Baggage 中。

4.架构图

receivers(接收者): 定义从 client 端的数据要以何种数据模型进行接收, 支持很多种数据模型。
processors: 将 receivers 的数据进行某些处理, 比如批量、性能分析等。
exporters: 将 processors 后的数据导出到特定的后端, 比如 metrics 数据存储到 prometheus 中。

5.核心概念

信号
- 信号是用于描述操作系统和平台上运行的应用程序基本活动的系统输出。信号可以是你想在特定时间点测量的东西，如温度或内存使用率，也可以是你想追踪的分布式系统组件中发生的事件。你可以将不同的信号组合在一起，从不同角度观察同一项技术的内部运作。
遥测数据（Telemetry Data）：
- 指标（Metrics）：度量数据，用于量化系统的状态和性能，如CPU利用率、请求速率、队列长度等。指标可以是瞬时值（Gauge）、累积计数（Counter）、直方图（Histogram）、摘要统计（Summary）等不同类型，有助于监控系统的健康状况、资源消耗、服务质量等。
- 日志（Logs）：事件记录，包含文本信息、时间戳、严重级别、元数据等，用于记录系统的运行状态、异常情况、调试信息等。日志有助于诊断问题、理解系统行为和审计目的。
- 分布式追踪（Distributed Tracing）：跟踪跨服务、跨进程甚至跨网络边界的请求流经系统的全过程，包括每个环节的耗时、调用关系、状态等信息。分布式追踪对于分析服务间的依赖关系、排查性能瓶颈、识别故障根源至关重要。
OpenTelemetry API：
- 提供一系列标准化的编程接口，使得开发人员能够在应用程序中方便地插入观测代码，生成上述三种类型的遥测数据。API 设计的目标是语言无关，目前支持多种主流编程语言（如Java、Python、Go、JavaScript等）。
OpenTelemetry SDK：
- 实现了OpenTelemetry API，提供了具体的遥测数据采集、处理和导出功能。SDK 包括：
  - 数据收集（Data Collection）：通过API暴露的接口收集应用程序产生的指标、日志和追踪数据。
  - 数据处理（Data Processing）：对原始数据进行转换、聚合、过滤等操作，如采样、资源标签关联、Span链接等。
  - 数据导出（Data Export）：将处理后的遥测数据发送到后端监控系统、日志聚合平台、分布式追踪系统等，这些系统可能是商业产品（如Prometheus、Jaeger、Zipkin等）或云服务商提供的服务（如阿里云、腾讯云等）。
资源（Resources）：
- 描述了产生遥测数据的实体（如进程、服务、主机等）的属性，如服务名、版本、环境、地域等。资源信息与每一条遥测数据关联，有助于在后端进行数据的筛选、聚合和分析。
Span（跨度）：
- 在分布式追踪中，Span代表一次操作的执行单元，通常对应一次网络请求、数据库查询、函数调用等。每个Span包含起止时间、操作名称、状态（如成功/失败）、时间戳、属性（Tags）、事件（Events）、关联的Span（Links）等信息。Spans可以形成树状结构（通过ParentSpanId关联），构成完整的调用链路。
Trace（跟踪）：
- 由一个或多个相互关联的Span组成，表示一个完整的服务请求（或工作单元）的生命周期。一个Trace通过唯一的Trace ID标识，包含了请求从发起至完成过程中涉及的所有服务调用及其相关信息。
Semantic Conventions（语义约定）：
- 规定了如何标准化地命名、描述和度量特定类型的操作或事件，以便在不同系统和服务间保持遥测数据的一致性和可理解性。例如，定义了HTTP请求的Span应如何标记URL、方法、状态码等属性，数据库查询的Span应如何记录SQL语句、数据库类型等信息。
自动 instrumentation（自动检测）：
- OpenTelemetry 提供了自动检测库，能够自动植入到应用程序中，无需手动修改代码即可收集相关组件（如HTTP客户端/服务器、数据库驱动、消息队列客户端等）的遥测数据。
Collector（收集器）：
- 可选组件，用于接收来自多个源（如本地SDK、远程应用程序等）的原始遥测数据，进行集中式的处理（如格式转换、协议适配、数据清洗等）和导出到多个后端系统。Collector有助于简化遥测数据的管理和集成。

6.相关开源项目

7.分布式追踪的起源

自从微服务的兴起开始，整个系统架构开始变得极为庞大和复杂，但是服务之间的调用关系，调用消耗时间等等信息却依然是半黑盒的状态。为了能够将调用的链路进行串联，将系统的各种指标数据展示出来以使得系统的链路更加透明便于排查故障，分布式追踪便应运而生。

分布式追踪的起源有一个比较普遍的说法是源自Google2010年发表的论文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure，然而实际上更早之前就有一些大公司内部已经有了类似的组件在使用了，只是不为人所知。当然即便如此，作为最早的系统性的论述分布式追踪的论文，它有着非同寻常的影响了，可以说是很多分布式追踪的实现参考。

8.百花齐放的分布式追踪

Zipkin

Zipkin最初是由Twitter开发并与2012年开源的一款开源追踪系统。Zipkin的使用非常广泛，影响了很多的后来人。他的传输头为X-B3

Skywalking

Skywalking是由国人开发，并且在后续捐赠给了Apache基金会的一个开源项目。现在是Apache基金会的顶级项目。

Pinpoint

Pinpoint由Naver在2012年开发，并于2015年开源。Pinpoint适用于java，php和python。

Jaeger

Jaeger最早是由Uber开发并于2017年开源，后续捐赠给了CNCF基金会。

OpenCensus

OpenCensus由Google发起，最初是Google内部追踪平台，后开源。

OpenTracing

OpenTracing由CNCF托管，具备较为完善的instrumentation库。

9.Opentelemetry的诞生

OpenCensus与OpenTracing
在上述的项目中有两个项目较为特殊：其一是OpenTracing，他制定了一套无关平台的统一的Trace的标准，后续的很多项目例如Jaeger等都是基于此协议，因此他在当时的Trace标准领域具有不小影响力；其二是OpenCensus，他背靠Google，并且它不仅仅实现了Trace，还包括了Metrics，并且他包含了一系列诸如Agent和Collector的方案，可以说是相当完备。

在当时这两大流派可以说是互相有一大票的追随者，一边是以Google和微软领衔的OpenCensus，一边是众多开源项目和厂商使用的OpenTracing，两者可以说是各有优劣，各领风骚。直到有一天...

再经过了一段时间的发展后OpenCensus与OpenTracing为了将两者的优点进行整合，宣布将进行合并，两者的合并就是后来赫赫有名的Opentelemetry

Opentelemetry可以说是含着金汤匙出生：OpenTracing支持，OpenCensus支持，刚开始就自带经验丰富的的社区人员，同时背后也有互联网巨头的支持。