Go微服务框架go-kratos实战05：分布式链路追踪 OpenTelemetry 使用

一、分布式链路追踪发展简介

1.1 分布式链路追踪介绍

关于分布式链路追踪的介绍，可以查看我前面的文章 微服务架构学习与思考(09)：分布式链路追踪系统-dapper论文学习(https://www.cnblogs.com/jiujuan/p/16097314.html) 。

这里的 OpenTelemetry 有一段发展历程。

APM(Application Performance Monitoring) 和 Distributed Tracing(分布式跟踪)，后者是前者的子集。

微服务架构流行起来后，为了监控和定位微服务中请求链路过长导致的定位和监控问题，分布链路监控也蓬勃发展起来。出现了

很多有名的产品，比如：Jaeger，Pinpoint，Zipkin，Skywalking 等等。这里有个问题，就是每家都有自己的一套数据采集标准和SDK。

为了统一这些标准，国外的人们就创建了 OpenTracing 和 OpenCensus 2 个标准。最先出现的是 OpenTracing。为了统一标准，后来两者合并为 OpenTelemetry。

1.2 OpenTracing

OpenTracing 制定了一套与平台无关、厂商无关的协议标准，使得开发人员能够方便的添加或更换底层APM的实现。

它是 CNCF 的项目。OpenTracing 协议的产品有 Jaeger、Zipkin 等等。

OpenTracing 数据模型

• Trace(s):

Trace(s) 在 OpenTracing 中是被 spans 隐式定义的。一个 trace 可以被认为是由一个或多个 span 组成的有向无环图。

比如，下图示例就表示一个 trace 由 8 个 span 组成，也就是一次链路追踪由 8 个 span 组成：

单个 trace(链路) 中 span 之间的关系           [Span A]  ←←←(the root span)             |      +------+------+      |             |  [Span B]      [Span C] ←←←(Span C is a `ChildOf` Span A)      |             |  [Span D]      +---+-------+                |           |            [Span E]    [Span F] >>> [Span G] >>> [Span H]                                        ↑                                        ↑                                        ↑                          (Span G `FollowsFrom` Span F) 

用时间轴来可视化这次链路追踪图，更容易理解：

Temporal relationships between Spans in a single Trace   ––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time   [Span A···················································]    [Span B··············································]       [Span D··········································]     [Span C········································]          [Span E·······]        [Span F··] [Span G··] [Span H··] 

（来自：https://opentracing.io/specification/）

• Span:

Span 是一次链路追踪里的基本组成元素，一个 Span 表示一个独立工作单元，比如一次 http 请求，一次函数调用等。每个 span 里元素：

• An operation name，服务/操作名称
• A start timestamp，开始时间
• A finish timestamp，结束时间
• Span Tags，key:value 数据形式，用户自定义的标签，主要用途是链路记录信息的查询过滤。
• Span Logs，key:value 数据形式，主要用途是记录某些事件和事件发生的时间。
• SpanContext 看下面解释
• References，对 0 或 更多个相关 span 的引用（通过 SpanContext 来引用）

• SpanContext:

SpanContext 携带跨进程(跨服务)通信的数据。它的组成：

• 在系统中表示 span 的信息。比如 span_id, trace_id。
• Baggage Items，为整条追踪链路保存跨进程(跨服务)的数据，数据形式是 key:value

• References

多个 span 中的对应关系。OpenTracing 目前定义了 2 种关系：ChildOf 和 FollowsFrom：

• ChildOf，一个子 span 可能是父 span 的 ChildOf

    [-Parent Span---------]          [-Child Span----]      [-Parent Span--------------]          [-Child Span A----]           [-Child Span B----]         [-Child Span C----]          [-Child Span D---------------]          [-Child Span E----] 

• FollowsFrom，一些父 span 不依赖任何的子 span

    [-Parent Span-]  [-Child Span-]       [-Parent Span--]      [-Child Span-]       [-Parent Span-]                 [-Child Span-] 

（来自：https://opentracing.io/specification/）

1.3 OpenCensus

为什么又出现个 OpenCensus 这个项目？因为它有个好爹：google。要知道分布式跟踪的基础论文就是谷歌提出。

其实，刚开始它并不是要抢 OpenTracing 的饭碗，它只是为了把 Go 语言的 Metrics 采集、链路跟踪与 Go 语言自带的

profile 工具打通，统一用户的使用方式。但是随着项目发展，它也想把链路相关的统一一下。它不仅要做 Metrics 基础指标监控，

还要做 OpenTracing 的老本行：分布式跟踪。

1.4 OpenTracing 与 OpenCensus 对比

2 者功能对比

1.5 OpenTelemetry

这样出现 2 个标准也不是个事啊，如是就出现了 OpenTelemetry，它把 2 者合并在一起了。

OpenTelemetry 的核心工作目前主要集中在 3 个部分：

1. 规范的制定和协议的统一，规范包含数据传输、API 的规范，协议的统一包含：HTTP W3C 的标准支持及GRPC等框架的协议标准
2. 多语言 SDK 的实现和集成，用户可以使用 SDK 进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack等）进行集成支持；
3. 数据收集系统的实现，当前是基于 OpenCensus Service 的收集系统，包括 Agent 和 Collector。

(1.4 1.5来自： https://github.com/open-telemetry/docs-cn)

OpenTelemetry 的最终形态就是实现 Metrics、Tracing、Logging 的融合。

OpenTelemetry 整体架构图：

（来自：https://opentelemetry.io/docs/）

Tracing API 中几个重要概念：

• TracerProvider：是 API 的入口点，提供了对 tracer 的访问。在代码里主要是创建一个 Tracer，一般是第三方分布式链路管理软件提供具体实现。默认是一个空的 TracerProvider("")，虽然也创建 Tracer，但是内部不会执行数据流传输逻辑。
• Tracer：负责创建 span，一个 tracer 表示一次完整的追踪链路。tracer 由一个或多个 span 组成。跟上面的 OpenTracing 数据模型很像，所以说是两者合并。
• Span：一次链路追踪操作里的基本操作元素。比如一次函数调用，一次 http 请求。

里面还有很多详细介绍：https://opentelemetry.io/docs/reference/specification/trace/api/

还有一个数据采样，https://www.cnblogs.com/jiujuan/p/16097314.html - 前面学习 dapper 论文的这篇文章有介绍。

小结：

一条链路追踪信息：

有一条链路 trace，它是由一个或多个 span 组成， span 里会记录各种链路中的信息，跨进程的信息，各种 span 之间的关系。

使用哪种链路管理软件，则由 traceprovider 来设置。可以是 Jaeger，Pinpoint，Zipkin，Skywalking 等等。

span 中的信息收集到链路管理软件，然后可以用图来展示记录的链路信息和链路之间的关系。

二、jaeger 简介

Jaeger 是受到 Dapper 和 OpenZipkin 启发，是 Uber 开发的一款分布式链路追踪系统。

它用于监控微服务和排查微服务中出现的故障。

jaeger 架构图：

（来自：https://www.jaegertracing.io/docs/1.35/architecture/）

jaeger 安装：

参考我前面文章 ：https://www.cnblogs.com/jiujuan/p/13235748.html docker all-in-one 安装

三、kratos 中链路追踪使用

前面介绍了那么多，应该对 opentelemetry 大致有了一个了解。下面就在 kratos 中使用 opentelemetry。

这里使用 jaeger 作为链路追踪的管理软件。

go 1.17

go-kratos 2.2.1

jaeger 1.35

下面代码来自 go-kratos 官方例子。

server 端

在 main.go 中，有 grpc server 和 http server。

第一步，设置 TraceProvider()

// set trace provider func setTraceProvider(url string) error { 	// create the jager exporter 	exp, err := jaeger.New(jaeger.WithCollectorEndpoint(jaeger.WithEndpoint(url))) 	if err != nil { 		return nil 	}  	// New trace provider 	tp := tracesdk.NewTracerProvider( 		// set the sampling rate based on the parent span to 100%， 设置采样率 100% 		tracesdk.WithSampler(tracesdk.ParentBased(tracesdk.TraceIDRatioBased(1.0))), 		// always be sure to batch in production 		tracesdk.WithBatcher(exp), 		// Record information about this application in an Resource. 		tracesdk.WithResource(resource.NewSchemaless( 			semconv.ServiceNameKey.String(Name),  // service name 			attribute.String("env", Env),         // environment 			attribute.String("version", Version), // version 		)), 	) 	otel.SetTracerProvider(tp) 	return nil } 

第二步，grpc server 和 http server

err := setTraceProvider(url) // 调用上面的 setTraceProvider 函数 if err != nil {     log.Error(err) } // grpc server grpcSrv := grpc.NewServer(     grpc.Address(":9000"),     grpc.Middleware(         middleware.Chain(             recovery.Recovery(),             tracing.Server(), // 设置 trace             logging.Server(logger),         ),     ), )  // http server httpSrv := http.NewServer(     http.Address(":8000"),     http.Middleware(         recovery.Recovery(),         tracing.Server(), // 设置 trace         logging.Server(logger),     ), ) 

client 端

grpc client 和 http client

grpc client：

// create grpc conn // only for demo, use single instance in production env conn, err := grpc.DialInsecure(ctx, 		grpc.WithEndpoint("127.0.0.1:9000"), 		grpc.WithMiddleware( 			recovery.Recovery(), 			tracing.Client(), 		), 		grpc.WithTimeout(2*time.Second), 		// for tracing remote ip recording 		grpc.WithOptions(grpcx.WithStatsHandler(&tracing.ClientHandler{})), ) 

http client：

http.NewClient(ctx, http.WithMiddleware(     tracing.Client(         tracing.WithTracerProvider(s.tracer),     ), )) 

四、参考

• https://go-kratos.dev/docs/component/middleware/tracing/ 链路追踪
• https://go-kratos.dev/blog/go-kratos-opentelemetry-practice/ 基于OpenTelemetry的链路追踪
• https://opentracing.io/specification/ opentracing doc
• https://opentelemetry.io/docs/instrumentation opentelemetry doc
• https://opentelemetry.io/docs opentelemetry trace api
• https://opencensus.io/ opencensus 官网
• https://www.jaegertracing.io/docs/1.35/ jaeger doc