一、分布式链路追踪发展简介
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(链路) 中 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
[-Parent Span---------][-Child Span----][-Parent Span--------------][-Child Span A----][-Child Span B----][-Child Span C----][-Child Span D---------------][-Child Span E----]
[-Parent Span-] [-Child Span-][-Parent Span--][-Child Span-][-Parent Span-][-Child Span-]
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 个部分:
- 规范的制定和协议的统一,规范包含数据传输、API 的规范,协议的统一包含:HTTP W3C 的标准支持及GRPC等框架的协议标准
- 多语言 SDK 的实现和集成,用户可以使用 SDK 进行代码自动注入和手动埋点,同时对其他三方库(Log4j、LogBack等)进行集成支持;
- 数据收集系统的实现,当前是基于 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 exporterexp, err := jaeger.New(jaeger.WithCollectorEndpoint(jaeger.WithEndpoint(url)))if err != nil {return nil}// New trace providertp := 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 productiontracesdk.WithBatcher(exp),// Record information about this application in an Resource.tracesdk.WithResource(resource.NewSchemaless(semconv.ServiceNameKey.String(Name), // service nameattribute.String("env", Env), // environmentattribute.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(), // 设置 tracelogging.Server(logger),),),
)// http server
httpSrv := http.NewServer(http.Address(":8000"),http.Middleware(recovery.Recovery(),tracing.Server(), // 设置 tracelogging.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 recordinggrpc.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