OpenTelemetry分布式追踪
opentelemetry简介
opentelemetry是什么
opentelemetry是一套由CNCF主导的云原生可观测性的标准协议，全称：OpenTelemetry Protocol，简称OTLP。
opentelemetry产生的背景
可观测性一个很重要的领域 Trace 有两个业界标杆: 一个是OpenTracing，另一个OpenCensus
- OpenTracing其实是一个规范，jaeger就是基于opentracing实现的开源工具，
- OpenCensus则是由google开源的度量工具，简单来说，这两者在可观测性领域功能高度重合，因此，在CNCF主导下进行了合并形成opentelemetry项目，OpenTracing跟penCensus共同推进opentelemetry，两者的官网也赫赫表达基本不再维护
同时opentelemetry也致力于trace、logging、metrics间的关联性.
opentelemetry的核心工作
- 1.规范的制定和协议的统一，规范包含数据传输、API的规范，协议的统一包含：HTTP W3C的标准支持及GRPC等框架的协议标准
- 2.多语言SDK的实现和集成，用户可以使用SDK进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack等）进行集成支持
- 3.数据收集系统的实现，当前是基于OpenCensus Service的收集系统，包括Agent和Collector。
OpenTelemetry状态
OpenTelemetry要解决的是对可观测性的大一统，它提供了一组API和SDK来标准化遥测数据的采集和传输，opentelemetry并不想对所有的组件都进行重写，而是最大程度复用目前业界在各大领域常用工具，通过提供了一个安全，厂商中立的能用协议、组件，这样就可以按照需要形成pipeline将数据发往不同的后端。
OpenTelemetry架构
opentelemetry也是个插件式的架构，针对不同的开发语言会有相应的Client组件，叫Instrumenttation，也就是在代码中埋点调用的api/sdk采集telemetry数据
这是go版本sdk https://github.com/open-telemetry/opentelemetry-go
opentelemetry定义了可观测性的几个方面的标准
metrics： https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/metrics/v1/metrics.protologs： https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/logs/v1/logs.prototrace：https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/trace/v1/trace.protoresources：https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/resource/v1/resource.protorpc_server_handled_seconds_bucket
数据协议规范
Tracing Signal
分布式追踪是一组事件，由单个逻辑操作触发，并跨应用程序中的各个组件合并。一个分布式追踪包含跨进程、网络和安全边界的事件。
Traces
Trace 由 Span 隐式定义，可以认为是 Span 的有向无环图（Directed Acyclic Graph, DAG）。
Spans
Span 代表了事务中的操作，每个 Span 封装了以下状态：
- 操作名称
- 起止时间戳
- 属性（Attributes）：一系列键值对
- 0 个或多个事件（Events）的集合，每个都是一个元组（时间戳，名称，属性），名称必须是字符串
- 父 Span 的标识
- 与 0 个或多个具有因果关系的 Span 链接（Links），通过相关 Span 的 SpanContext
- 引用 Span 所需的 SpanContext 信息
SpanContext
表示标识 Trace 中的 Span 的所有信息，必须传播到子 Span 和跨进程边界。一个 SpanContext 包含从父 Span 传播到子 Span 的跟踪标识符和选项。
- TraceId：trace 的标识符。全局唯一，随机生成 16 个字节。TraceId 用于将跨进程的特定 trace 的所有 span 分组在一起。
- SpanId：span 的标识符。全局唯一，随机生成 8 个字节。当传递给子 Span 时，该标识符将成为子 Span 的父 span id 。
- TraceFlags：trace 的选项。表示为一字节（位图 bitmap）
- Sampling bit：表示 trace 是否被采样的比特（掩码
0x1） - Tracestate：在一个键值对列表中携带特定于追踪系统的上下文。Tracestate 允许不同的供应商传播额外的信息，用它们的遗留的 Id 格式进行互操作。
Span 之间的链接（Links）
一个 Span 必须和 0 个或多个因果关联的其他 Span 链接（由 SpanContext 定义）。链接可以指向一个 Trace 内的 Span 或跨 Trace 。
当 Trace 进入服务的可信边界，并且服务策略要求生成新的 Trace 而不信任传入的 Trace 上下文时，可以用来表示原始 trace 和接下来的 trace 之间的关系。新链接的 Trace 还可以表示一个长时间运行的异步数据处理操作，由传入的许多请求之一发起。
Metric Signal
OpenTelemetry 允许用预定义的聚合和标签集记录原始测量或度量。
使用 OpenTelemetry API 记录原始测量允许最终用户决定应该为这个度量用什么聚合算法，以及定义标签（维度）。它将被用于像 gRPC 的客户端库，记录原始测量 server_latency 和 received_bytes 。因此最终用户将决定应该从这些原始测量数据中收集哪种类型的聚合值，也可能是简单的平均值或精细的直方图计算。
使用 OpenTelemetry API 记录预定义聚合的度量同样重要。它允许收集 CPU 和内存使用，或者是像队列长度这样的简单度量。
记录原始测量
用于记录原始测量的主要类是 Measure 和 Measurement 。可以使用 OpenTelemetry API 记录附加上下文的 Measurement 列表。因此，用户可以通过定义来聚合这些 Measurement ，并使用传递上下文来定义结果度量的额外维度。
Measure
Measure 描述库记录的单个值的类型。定义了公开测量方法的库和聚合独立测量到 Metric 中的应用之间的关系。Measure 由名称、描述和一个值的单位标识。
Measurement
Measurement 描述为 Measure 收集的单一值，Measuremrnt 是一个空接口，在 SDK 中定义。
使用预定义聚合记录度量
所有类型的预定义聚合度量的基类称为 Metric ，它定义了基本的度量属性，例如名称和标签。继承 Metric 的类定义自己的聚合类型和单个测量或点的结构。API 定义了以下类型的预定义聚合度量：
- Counter metric 报告瞬时测量。Counter 值可以上升或保持不变，但不可能下降也不可能为负，Counter 度量值有两种类型：
double和long。 - Gauge metric 报告数字值的瞬时测量。Gauge 值可以上升或下降，也可以为负值。Gauge 度量值有两种类型：
double和long。
API 允许构造选定类型的 Metric ，SDK 定义了要导出的 Metric 值的查询方式。
每种类型的 Metric 拥有自己的 API 记录将要聚合的值。API 支持推拉模型（push and pull model）来设置 Metric 值。
度量数据模型和 SDK
基于 metrics.proto 建立度量数据模型（Metrics Data Model），这个数据模型定义了三种语义：API 使用的事件模型（Event model）、SDK 和 OTLP 使用的 in-flight 数据模型、表示导出工具如何解释 in-flight 数据模型时间序列模型（TimeSeries model）。
不同的导出工具有不同的能力（例如，支持的数据模型）和约束（例如，哪些字符允许作为标签键）。所有导出工具都通过 OpenTelemetry SDK 中定义的度量生产者接口（Metric Producer interface）从度量数据模型中消费数据。
因此，Metrics 对数据的约束最小（例如，键中允许哪些字符），处理 Metrics 的代码应该避免对其进行验证和清洗。相反，将数据传递给后端，依赖后端执行验证，并从后端返回错误。
Log Signal
数据模型
数据模型定义了 OpenTelemetry 如何理解日志和事件
Baggage Signal
除了 trace 的传播，OpenTelemetry 还提供了 Baggage 来传播键值对。Baggage 用于索引一个服务中的可观察事件，该服务包含同一事务中先前的服务提供的属性，有助于在事件之间建立因果关系。
虽然 Baggage 可以用作其他横切关注点的原型，但这种机制主要是为了传递 OpenTelemetry 可观测性系统的值。
这些值可以从 Baggage 中消费，并作为度量的附加维度，或日志和跟踪的附加上下文使用。一些例子:
- web 服务可以从包含发送请求的服务的上下文中获益
- SaaS 提供商可以包含有关负责该请求的 API 用户或令牌的上下文
- 确定特定浏览器版本与图像处理服务中的故障相关联
Resources
Resources 获取关于被记录的遥测数据实体信息。例如，Kubernetes 容器公开的度量可以链接到指定集群、名称空间、pod 和容器名称的资源。Resources 可以捕获实体标识的整个层次结构，它可以描述云中的主机和特定的容器或进程中运行的应用程序。
上下文传播（Context Propagation）
所有 OpenTelemetry 横切关注点，例如 trace 和 metric ，共享底层的 Context 机制，用于在分布式追踪中存储状态和访问跨 Span 生命周期的数据。
传播器（Propagators）
OpenTelemetry 使用 Propagators 来序列化和反序列话横切关注点的值，例如 Span （通常只有 SpanContext 的部分）和 Baggage 。不同的 Propagators 类型定义了特定传输和绑定到数据类型的限制。
传播器 API 定义了一个 Propagator 类型
TextMapPropagator将值注入载体并从载体中提取值为文本。
收集器（Collector）
OpenTelemetry 收集器是一套组件，可以从 OpenTelementry 或其他监测/追踪库（Jaeger、Prometheus 等）执行的进程收集 traces、metrics 和其他遥测数据（例如，日志），并进行聚合和智能采样，导出 traces 和 metrics 到一个或多个监控/追踪后端。收集器允许丰富和转换所收集的遥测数据（例如，添加额外的属性或删除个人信息）。
OpenTelemetry 收集器有两种主要的操作模式：代理（与应用程序一起在本地运行的守护进程），收集器（独立运行的服务）。
工具库
被调用为另一个库启用 OpenTelemetry 可观测性的库称为工具库。各语言工具库
本文来自博客园，作者：王竹笙，转载请注明原文链接：https://www.cnblogs.com/edeny/p/18407804
浙公网安备 33010602011771号