基于jaeger微服务调用链实现方案

一、调用链引入的背景：

项目微服务化，由集中式向分布式演进后，整个调用关系变得复杂 服务由大规模集群构成，各个应用之间相当独立，可能由不同团队、不同语言实现 问题： 无法准确知道整体系统性能及运行情况 复杂的调用导致系统出问题后难以定位问题 全链路性能监控，识别对关键调用链，并进行优化比较困难 解决方案： 引入分布式系统调用链监控，目标：

1）跨语言 2）无侵入性 3）简单易用ui

二、OpenTracing介绍

调用链追踪最先由google在 Dapper这篇论文中提出，OpenTracing主要定义了相关的协议以及接口，各个语言只要按照Opentracing的接口以标准实现数据上报，那么调用信息就能统一被收集。OpenTracing通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加（或更换）追踪系统的实现。

OpenTracing关键术语：

Span：表示调用链路的基本单元，使用 spanId 作为唯一标识；每个服务的每次调用都对应一个 Span，在其中记录服务名称、时间等基本信息； Trace：表示一个调用链路，由若干 Span 组成，使用 traceId 作为唯一标识，对应一次完整的服务请求； Tags ：每个span可以有多个键值对（key:value）形式的Tags，Tags是没有时间戳的，支持简单的对span进行注解和补充，如一段span是调用redis的，而可以设置redis的标签，这样通过搜索redis关键字，可以查询出所有相关的span以及trace. SpanContext：每个span必须提供方法访问SpanContext。SpanContext代表跨越进程边界，传递到下级span的状态。(例如，包含<trace_id, span_id, sampled>元组)，并用于封装Baggage中。 Baggage： Baggage是存储在SpanContext中的一个键值对(SpanContext)集合。它会在一条追踪链路上的所有span内全局传输，包含这些span对应的SpanContexts。在这种情况下，“Baggage”会随着trace一同传播。

OpenTracing原理

三、业界调用链平台对比

四、业界调用链平台对比

Jaeger-agent： jaeger的agent，是一个监听在 UDP 端口上接收 span 数据的网络守护进程。 agent收集并汇聚这些span信息到collector。

Collector： collector从agent收集traces信息，并通过处理管道处理他们，再写入后端存储

Date Store： 可以支持 Cassandra和ElasticSearch

Query & UI Query查询是一种从存储中检索trace，并提供UI以显示它们的服务

原理图：

五、各种语言接入jeager实践

1、golang

初始化：

拦截器：

otgrpc.OpenTracingServerInterceptor(opentracing.GlobalTracer(), optFuncs...) otgrpc.OpenTracingStreamServerInterceptor(opentracing.GlobalTracer())

2、python

python服务引入包：

1、common.tracing_utils 2、vendor （opentracing_instrumentation）

python服务改动：

from common.tracing_utils import * init_tracing("testtwo") app=Flask(__name__) app.wsgi_app=FlaskTraceMiddleware(app.wsgi_app,tracer())