关注公众号:带你学AI

opentelemertry的背景 opentelemetry的前身是Opencensus,它爹是google,它妈是微软, 目标是集成Metrics、Tracing、Logging的融合及大一统, metric指标: 例如cpu、内存、硬盘、网络等机器指标,grpc的请求延迟、错误率等网络协议指标,用户数、访问数、订单数等业务指标,都可以涵盖在内.

OpenTelemetry的自身定位很明确:数据采集和标准规范的统一,对于数据如何去使用、存储、展示、告警,官方是不涉及的,我们目前推荐使用Prometheus + Grafana做Metrics存储、展示,使用Jaeger做分布式跟踪的存储和展示。

如何融合 在以往对APM的理解中,这三者都是完全独立的,但是随着时间的推移,人们逐步发现了三者之间的关联,例如我们可以把Tracing的TraceID打到Logging的日志中,这样可以把分布式链路跟踪和日志关联到一起,彼此数据互通,但是还存在以下问题:

如何把Metrics和其他两者关联起来如何提供更多维度的关联,例如请求的方法名、URL、用户类型、设备类型、地理位置等关联关系如何一致,且能够在分布式系统下传播 在OpenTelemetry中试图使用Context为Metrics、Logging、Tracing提供统一的上下文,三者均可以访问到这些信息,同时Context可以随着请求链路的深入,不断往下传播 ● Context数据在Task/Request的执行周期中都可以被访问到 ● 提供统一的存储层,用于保存Context信息,并保证在各种语言和处理模型下都可以工作(例如单线程模型、线程池模型、CallBack模型、Go Routine模型等) ● 多种维度的关联基于元信息(标签)实现,元信息由业务确定,例如:通过Env来区别是测试还是生产环境等 ● 提供分布式的Context传播方式,例如通过W3C的traceparent/tracestate头、GRPC协议等

opentelemetry到底包含哪些内容 OpenTelemetry是一组标准和工具的集合,管理观测类的数据. 目前开源实现:Prometheus、Jaeger或云厂商的服务提供

其负责的内容:

Opentelemetry通过spec规范了观测数据的数据模型以及采集、处理、导出方法. 项目组成: OpenTelemetry 项目目前主要由以下几个部分组成: ● 跨语言的统一规范 (Cross-language specification) ● 收集、转换和导出遥测数据的工具 (Tools to collect, transform, and export telemetry data) ● 各个语言的 SDK (Per-language SDKs) ● 自动注入的采集库和第三方支持的包 (Automatic instrumentation and contrib packages)

规范的制定和协议的统一,规范包含数据传输、API的规范,协议的统一包含:HTTP W3C的标准支持及GRPC等框架的协议标准多语言SDK的实现和集成,用户可以使用SDK进行代码自动注入和手动埋点,同时对其他三方库(Log4j、LogBack等)进行集成支持;数据收集系统的实现,当前是基于OpenCensus Service的收集系统,包括Agent和Collector。 OpenTelemetry 可以帮助你无需依赖某个特定项目的 SDK 或者工具,就能够生成和导出遥测数据 OpenTelemetry的自身定位很明确:数据采集和标准规范的统一,对于数据如何去使用、存储、展示、告警,官方是不涉及。

OpenTelemetry Specification 描述了针对所有语言插桩库而言的统一的约束和要求。除了一些基本的数据定义之外,规范中还包含如下内容: ● API:定义了在生成和关联Trace、监控指标和日志数据时的数据类型和支持的操作。 ● SDK:定义了在特定语言 API 的实现过程中的一些要求,此外,还包含了配置、数据处理以及数据导出相关概念。任何探针实现只能依赖api不能依赖sdk ● DATA:定义了一个支持 OpenTelemetry Line Protocol (OTLP) 的后端服务服务相关的语义约定 Collector OpenTelemetry Collector 是一个与供应商(后端存储)无关的一个代理服务,它可以用于接收、处理并导出相关的遥测数据。它支持接收多种形式的遥测数据,例如OTLP、Jaeger、Prometheus等,同时能够将数据发送给多个后端存储服务。此外,它还支持再导出数据前,对数据进行基本的处理和过滤等工作。此外,通过 contrib 包还能够实现对更多中数据格式和后端存储服务的支持。 SDKs OpenTelemetry 还具有各个语言的 SDK,这些 SDK 可以帮助你在对应的编程语言中使用 OpenTelemetry API 来生成遥测数据并导出给期望的后端存储服务。同时,这些 SDK 还针对了一些通用框架和库实现自动插桩注入,你也可以手动调用这些 SDK 在你的应用中实现手动插桩。各个后端存储服务商通常也会提供一些各个语言的 SDK,从而能够帮助用户更容易的将数据导出到它们的存储后端服务中。

自动插桩库 OpenTelemetry 提供了一批自动插桩库,这些自动插桩库可以针对一些语言的流行的库或者框架来自动生成遥测数据。例如,HTTP 库可能就会包含 HTTP 请求过程中入站和出站过程中的一些相关指标。自动插桩库的使用方式可能会与编程语言相关,对于一些场景,可能只需要在你的项目依赖中增加该组件即可,对于另外一些场景,可能需要在你的代码中显式使用该包。 从长远来看,我们希望针对这些流行的库而言可观测性是其内置的能力,这样,我们就不需要单独再引用相关的组件来实现插桩操作。

OpenTelemetry Specification 中文: https://github.com/open-telemetry/docs-cn/tree/main/specification 英文: https://opentelemetry.io/docs/reference/specification/ tracing api TracerProvider - 所有方法可以安全的并行调用。 Tracer - 所有方法可以安全的并行调用。 Span - 所有方法可以安全的并行调用。 Event - Events 为不可变,可安全的并行调用。 Link - Links 为不可变,可安全的并行调用。 ● TracerProvider 是 API 的入口点 (Entry Point) 。 它提供对 Tracers 的访问。 ● Tracer 是负责创建 Spans 的类。 ● Span 是跟踪操作的 API。 senmatic Conventions (data) (语义规范) 定义了以下的 ● Resource Conventions ● Span Conventions ● Metrics Conventions

Plugins and instrumentation packages 脱离sdk 成为contrib,API Contrib refers to packages which depend solely upon the API; SDK Contrib refers to packages which also depend upon the SDK.

Tracer的定义: 由一组span组成的有向无环图

spans的定义: ● 名称 ● 开始结束时间 ● 属性 {key -value}形式 ● 事件 0个或者多个 元组类型, (timestamp, name, Attributes). The name must be string ● span的类型

● 父亲span ● SpanContext information required to reference a Span ● Links 有因果的关系的spans 可以在一个trace 或者跨trace,

SpanContext: SpanContext contains the tracing identifiers and the options that are propagated from parent to child

● TraceId is the identifier for a trace. It is worldwide unique with practically sufficient probability by being made as 16 randomly generated bytes. TraceId is used to group all spans for a specific trace together across all processes. ● SpanId is the identifier for a span. It is globally unique with practically sufficient probability by being made as 8 randomly generated bytes. When passed to a child Span this identifier becomes the parent span id for the child Span. ● TraceFlags represents the options for a trace. It is represented as 1 byte (bitmap). ○ Sampling bit - Bit to represent whether trace is sampled or not (mask 0x1). ● Tracestate carries tracing-system specific context in a list of key value pairs. Tracestate allows different vendors propagate additional information and inter-operate with their legacy Id formats. For more details see this.

Links can be used to represent batched operations where a Span was initiated by multiple initiating Spans, each representing a single incoming item being processed in the batch.

更多中文参考: https://github.com/open-telemetry/docs-cn/blob/main/specification/trace/api.md#specifying-links

OpenTelemetry 客户端架构

参考文章 opelemetry中文版本 trace context2 trace context

好文推荐

评论可见,请评论后查看内容,谢谢!!!评论后请刷新页面。