[业界方案]用Jaeger来学习分布式追踪系统Opentracing

[业界方案]用Jaeger来学习分布式追踪系统Opentracing

0x00 摘要

笔者之前有过zipkin的经验，希望扩展到Opentracing，于是在学习Jaeger基础上总结出此文，与大家分享。

0x01 缘由 & 问题

1.1 选择Jaeger

Jaeger 是 Uber 开发的一款调用链服务端产品，开发语言为 golang ，能够兼容接收 OpenTracing 格式的数据。根据其发展历史，可以说是 Zipkin 的升级版。另外，其基于 udp （也可以 http ）的传输协议，更加定位了其高效、迅速的特点。

在前文 [业界方案] 用SOFATracer学习分布式追踪系统Opentracing ，我们使用SOFATracer来进行学习，本次我们选择了Jaeger，这又是什么原因？具体如下：

Jaeger是Opentracing官方推荐的。
Jaeger支持Opentracing高版本。

而且我们正好可以和SOFATracer进行对比印证。

1.2 问题

让我们用问题来引导阅读。

Jaeger 和 SOFATracer 对比如何？
spanId是怎么生成的，有什么规则?
traceId是怎么生成的，有什么规则？
客户端哪里生成的Span？
ParentSpan 从哪儿来？
ChildSpan由ParentSpan创建，那么什么时候创建？
Trace信息怎么传递？
服务器接收到请求之后做什么？
SpanContext在服务器端怎么处理？
链路信息如何搜集？

1.3 本文讨论范围

1.3.1 Jaeger构成

Jaeger主要由以下几部分组成：

Jaeger Client：为了不同语言实现了符合OpenTracing标准的SDK。应用程序通过API写入数据， client library把trace信息按照应用程序制定的采样策略传递给jaeger-agent。
Agent：他是一个监听在UDP端口上接收span数据的网络守护进程，它会将数据批量发送给collector。他被设计成一个基础组件，部署到所有的宿主机上。Agent将client library和collector解耦，为client library屏蔽了路由和发现collector的细节。
Collector：接收jaeger-agent发送来的数据，然后将数据写入后端存储。Collector被设计成无状态的组件，因此用户可以运行任意数量的Collector。
Data Store：后端存储被设计成一个可插拔的组件，支持数据写入cassandra， elastic search。
Query：接收查询请求，然后从后端存储系统中检索tarce并通过UI进行展示。Query是无状态的，可以启动多个实例。把他们部署在nginx这样的负载均衡器后面。

本文只讨论 Jaeger Client 功能。

1.3.2 全链路跟踪

全链路跟踪分成三个跟踪级别：

跨进程跟踪 (cross-process)(调用另一个微服务)
数据库跟踪
进程内部的跟踪 (in-process)(在一个函数内部的跟踪)

本文只讨论跨进程跟踪 (cross-process)，因为跨进程跟踪是最简单的 ^_^。对于跨进程跟踪，你可以编写拦截器或过滤器来跟踪每个请求，它只需要编写极少的代码。

0x02 背景知识

因为前文已经对背景知识做了较详细的介绍，本文只是提一下几个必要概念。

分布式追踪系统发展很快，种类繁多，但核心步骤一般有三个：代码埋点，数据存储、查询展示

在数据采集过程，需要侵入用户代码做埋点，不同系统的API不兼容会导致切换追踪系统需要做很大的改动。为了解决这个问题，诞生了opentracing 规范。

   +-------------+  +---------+  +----------+  +------------+

   | Application |  | Library |  |   OSS    |  |  RPC/IPC   |

   |    Code     |  |  Code   |  | Services |  | Frameworks |

   +-------------+  +---------+  +----------+  +------------+

          |              |             |             |

          |              |             |             |

          v              v             v             v

     +-----------------------------------------------------+

     | · · · · · · · · · · OpenTracing · · · · · · · · · · |

     +-----------------------------------------------------+

       |               |                |               |

       |               |                |               |

       v               v                v               v

 +-----------+  +-------------+  +-------------+  +-----------+

 |  Tracing  |  |   Logging   |  |   Metrics   |  |  Tracing  |

 | System A  |  | Framework B |  | Framework C |  | System D  |

 +-----------+  +-------------+  +-------------+  +-----------+

大多数分布式追踪系统的思想模型都来自Google's Dapper论文，OpenTracing也使用相似的术语。有几个基本概念我们需要提前了解清楚：

Trace(追踪) ：Dapper 将一个调用过程构建成一棵调用树(称为Tracer)，Tracer树中的每个节点表示链路调用中的一个模块或系统。通过一个全局唯一的 traceId 来标识一个请求调用链。在广义上，一个trace代表了一个事务或者流程在（分布式）系统中的执行过程。在OpenTracing标准中，trace是多个span组成的一个有向无环图（DAG），每一个span代表trace中被命名并计时的连续性的执行片段。
Span(跨度) ：一个span代表系统中具有开始时间和执行时长的逻辑运行单元，即应用中的一个逻辑操作。span之间通过嵌套或者顺序排列建立逻辑因果关系。一个span可以被理解为一次方法调用，一个程序块的调用，或者一次RPC/数据库访问，只要是一个具有完整时间周期的程序访问，都可以被认为是一个span。Dapper中，一个span 包含以下阶段（不同软件可能有不同的实现，比如有的会细分为 Client Span 和 Server Span）：
- Start: 发起调用
- cleint send(cs): 客户端发送请求
- Server Recv(sr)：服务端收到请求
- Server Send(ss): 服务端发送响应
- Client Recv(cr) : 客户端收到服务端响应
- End：整个链路完成。

     Client                             Server

+--------------+     Request        +--------------+

| Client Send  | +----------------> |Server Receive|

+------+-------+                    +------+-------+

       |                                   |

       |                                   v

       |                            +------+--------+

       |                            |Server Business|

       |                            +------+--------+

       |                                   |

       |                                   |

       v                                   v

+------+--------+    Response       +------+-------+

|Client Receive | <---------------+ |Server Send   |

+------+--------+                   +------+-------+

       |                                   |

       |                                   |

       v                                   v

Logs ：每个span可以进行多次Logs操作，每一次Logs操作，都需要一个带时间戳的时间名称，以及可选的任意大小的存储结构。比较适合记录日志、异常栈等一些和时间相关的信息。
Tags ：每个span可以有多个键值对（key ：value）形式的Tags，Tags是没有时间戳的，支持简单的对span进行注解和补充。记录的信息适用于span从创建到完成的任何时刻。再说直白点就是记录和时间点无关的信息，这个主要是和下面的Logs作区分。
Baggage Items：这个主要是用于跨进程全局传输数据
SpanContext ：SpanContext更像是一个“概念”，而不是通用 OpenTracing 层的有用功能。在创建Span、向传输协议Inject（注入）和从传输协议中Extract（提取）调用链信息时，SpanContext发挥着重要作用。

0x03 示例代码

3.1 代码

代码全部来自 https://github.com/yurishkuro/opentracing-tutorial，大家可以自己去下载。

这里的tracer使用的是 JaegerTracer。

public class Hello {

    private final Tracer tracer;

    private final OkHttpClient client;

    private Hello(Tracer tracer) {

        this.tracer = tracer;

        this.client = new OkHttpClient();

    }

    private String getHttp(int port, String path, String param, String value) {

        try {

            HttpUrl url = new HttpUrl.Builder().scheme("http").host("localhost").port(port).addPathSegment(path)

                    .addQueryParameter(param, value).build();

            Request.Builder requestBuilder = new Request.Builder().url(url);

            Span activeSpan = tracer.activeSpan();

            Tags.SPAN_KIND.set(activeSpan, Tags.SPAN_KIND_CLIENT);

            Tags.HTTP_METHOD.set(activeSpan, "GET");

            Tags.HTTP_URL.set(activeSpan, url.toString());

            tracer.inject(activeSpan.context(), Format.Builtin.HTTP_HEADERS, Tracing.requestBuilderCarrier(requestBuilder));

            Request request = requestBuilder.build();

            Response response = client.newCall(request).execute();

            Tags.HTTP_STATUS.set(activeSpan, response.code());

            if (response.code() != 200) {

                throw new RuntimeException("Bad HTTP result: " + response);

            }

            return response.body().string();

        } catch (Exception e) {

            Tags.ERROR.set(tracer.activeSpan(), true);

            tracer.activeSpan().log(ImmutableMap.of(Fields.EVENT, "error", Fields.ERROR_OBJECT, e));

            throw new RuntimeException(e);

        }

    }

    private void sayHello(String helloTo, String greeting) {

        Span span = tracer.buildSpan("say-hello").start();

        try (Scope scope = tracer.scopeManager().activate(span)) {

            span.setTag("hello-to", helloTo);

            span.setBaggageItem("greeting", greeting);

            String helloStr = formatString(helloTo);

            printHello(helloStr);

        } finally {

            span.finish();

        }

    }

    private String formatString(String helloTo) {

        Span span = tracer.buildSpan("formatString").start();

        try (Scope scope = tracer.scopeManager().activate(span)) {

            String helloStr = getHttp(8081, "format", "helloTo", helloTo);

            span.log(ImmutableMap.of("event", "string-format", "value", helloStr));

            return helloStr;

        } finally {

            span.finish();

        }

    }

    private void printHello(String helloStr) {

        Span span = tracer.buildSpan("printHello").start();

        try (Scope scope = tracer.scopeManager().activate(span)) {

            getHttp(8082, "publish", "helloStr", helloStr);

            span.log(ImmutableMap.of("event", "println"));

        } finally {

            span.finish();

        }

    }

    public static void main(String[] args) {

        try (JaegerTracer tracer = Tracing.init("hello-world")) {

            new Hello(tracer).sayHello("helloTo", "greeting");

        }

    }

}

3.2 dropwizard

此处虽然不是SOFATracer和Jaeger的本质区别，但是也挺有趣，即SOFATracer是使用SprintBoot来做示例代码，而此处是使用dropwizard来做示例。

可能有人对dropwizard不熟悉，现在大致讲解如下：

Dropwizard是Coda Hale在Yammer公司时创立的，它旨在提升公司分布式系统的架构（现在叫：微服务）。虽然它最早被用来构建REST Web 服务，而现在它具备了越来越多的功能，但是它的目标始终是作为轻量化、为生产环境准备且容易使用的web框架。
Dropwizard与Spring Boot类似，也是构建微服务可选的工具，但是它显得比Spring Boot更加规范一些。它使用的组件一般不会做可选替换，而好处是可以不需要那么多的修饰，比如写基于REST的web服务。
Dropwizard默认也不具备依赖注入的容器（像Spring或者CDI），你当然可以自行添加，但是Dropwizard推荐你把微服务弄的简单一些，不需要这些额外的组件。
就像Spring Boot一样，Dropwizard推荐将整个工程打包成一个可执行的jar，通过这种方式开发人员不用在担心程序运行的应用服务器是什么，需要什么额外的配置，应用再也不需要被构建成war包了，而且也不会有那么多复杂层级的类加载器了。

Dropwizard在优秀的三方库协助下，提供了不错的抽象层，使之更有效率，更简单的编写生产用途的微服务。

Servlet容器使用Jetty
REST/JAX-RS实现使用Jersey
JSON序列化使用Jackson
集成Hibernate Validator
Guava
Metrics
SLF4J + Logback
数据访问层上使用JDBI

Dropwizard偏执的认为框架就是用来写代码的，因此对于框架的底层技术栈的调整，原则上Dropwizard是拒绝的。正因为它这么做，使得Dropwizard开发起代码来更快，而且配置更加容易。

对于我们的示例代码，对Dropwizard使用举例如下，即使用 Dropwizard 建立了两个服务和一个测试client。

io.dropwizard.Application

public class Formatter extends Application<Configuration> {

    private final Tracer tracer;

    private Formatter(Tracer tracer) {

        this.tracer = tracer;

    }

    @Path("/format")

    @Produces(MediaType.TEXT_PLAIN)

    public class FormatterResource {

        @GET

        public String format(@QueryParam("helloTo") String helloTo, @Context HttpHeaders httpHeaders) {

            Span span = Tracing.startServerSpan(tracer, httpHeaders, "format");

            try (Scope scope = tracer.scopeManager().activate(span)) {

                String greeting = span.getBaggageItem("greeting");

                if (greeting == null) {

                    greeting = "Hello";

                }

                String helloStr = String.format("%s, %s!", greeting, helloTo);

                span.log(ImmutableMap.of("event", "string-format", "value", helloStr));

                return helloStr;

            } finally {

                span.finish();

            }

        }

    }

    @Override

    public void run(Configuration configuration, Environment environment) throws Exception {

        environment.jersey().register(new FormatterResource());

    }

    public static void main(String[] args) throws Exception {

        System.setProperty("dw.server.applicationConnectors[0].port", "8081");

        System.setProperty("dw.server.adminConnectors[0].port", "9081");

        try (JaegerTracer tracer = Tracing.init("formatter")) {

            new Formatter(tracer).run("server");

        }

    }

}

0x04 链路逻辑

对于一个组件来说，一次处理过程一般是产生一个 Span；这个 Span 的生命周期是从接收到请求到返回响应这段过程。

这里需要考虑的问题是如何与上下游链路关联起来呢？在 Opentracing 规范中，可以在 Tracer 中 extract 出一个跨进程传递的 SpanContext 。然后通过这个 SpanContext 所携带的信息将当前节点关联到整个 Tracer 链路中去，当然有提取（extract）就会有对应的注入（inject）。

链路的构建一般是 client-server-client-server 这种模式的，那这里就很清楚了，就是会在 client 端进行注入（inject），然后再 server 端进行提取（extract），反复进行，然后一直传递下去。

在拿到 SpanContext 之后，此时当前的 Span 就可以关联到这条链路中了，那么剩余的事情就是收集当前组件的一些数据；整个过程大概分为以下几个阶段：

从请求中提取 spanContext
构建 Span，并将当前 Span 存入当前 tracer上下文中（SofaTraceContext.push(Span)）。
设置一些信息到 Span 中
返回响应
Span 结束&上报

0x05 数据模型

5.1 Tracer & JaegerTracer

Jaeger中的Tracer控制了一个完整的服务的追踪，包括注册服务名（serviceName），发送span（reporter），采样（sampler），对span的序列化与反序列化以及传输（registry的injector,extractor），统计追踪系统的信息（metrics，如发送span成功数量等）。

因此opentracing建议每个服务使用一个Tracer，除此之外Tracer还担负构造span，获取当前span以及获取scopeManager的功能。

通过opentracing的规范亦可以看出，opentracing对Tracer的功能描述为：Tracer is a simple, thin interface for Span creation and propagation across arbitrary transports。而jaeger只是在其基础上增加了其他功能。

Tracer是opentracing给出的接口。

package io.opentracing;

public interface Tracer extends Closeable {

    ScopeManager scopeManager();

    Span activeSpan();

    Scope activateSpan(Span var1);

    Tracer.SpanBuilder buildSpan(String var1);

    <C> void inject(SpanContext var1, Format<C> var2, C var3);

    <C> SpanContext extract(Format<C> var1, C var2);

    void close();

}

JaegerTracer 实现了 io.opentracing.Tracer。

public class JaegerTracer implements Tracer, Closeable {

    private final String version;

    private final String serviceName;

    private final Reporter reporter;

    private final Sampler sampler;

    private final Map<String, ?> tags;

    private final boolean zipkinSharedRpcSpan;

    private final boolean expandExceptionLogs;

    private final boolean useTraceId128Bit;

    private final PropagationRegistry registry;

    private final Clock clock;

    private final Metrics metrics;

    private final ScopeManager scopeManager;

    private final BaggageSetter baggageSetter;

    private final JaegerObjectFactory objectFactory;

    private final int ipv4;

}

5.2 Span & JaegerSpan

io.opentracing.Span 是 Opentracing 给出的概念。

public interface Span {

    SpanContext context();

    Span setTag(String var1, String var2);

    Span setTag(String var1, boolean var2);

    Span setTag(String var1, Number var2);

    <T> Span setTag(Tag<T> var1, T var2);

    Span setBaggageItem(String var1, String var2);

    String getBaggageItem(String var1);

    Span setOperationName(String var1);

    void finish();

    void finish(long var1);

}

JaegerSpan 实现了 io.opentracing.SPan。

public class JaegerSpan implements Span {

  private final JaegerTracer tracer;

  private final long startTimeMicroseconds;

  private final long startTimeNanoTicks;

  private final boolean computeDurationViaNanoTicks;

  private final Map<String, Object> tags;

  private long durationMicroseconds; // span durationMicroseconds

  private String operationName;

  private final List<Reference> references;

  private JaegerSpanContext context;

  private List<LogData> logs;

  private boolean finished = false; // to prevent the same span from getting reported multiple times

}

在jaeger的实现中，Span的信息分为如下几方面：

span核心信息，如：traceId，spanId，parentId，baggage等
log信息与tag的区别是带有时间戳
tag信息
span的其他信息，如：startTime,duration

其中span的核心信息存储在SpanContext中。

5.3 SpanContext & JaegerSpanContext

JaegerSpanContext 实现了 io.opentracing.SpanContext

public interface SpanContext {

    String toTraceId();

    String toSpanId();

    Iterable<Entry<String, String>> baggageItems();

}

public class JaegerSpanContext implements SpanContext {

  protected static final byte flagSampled = 1;

  protected static final byte flagDebug = 2;

  private final long traceIdLow;

  private final long traceIdHigh;

  private final long spanId;

  private final long parentId;

  private final byte flags;

  private final Map<String, String> baggage;

  private final String debugId;

  private final JaegerObjectFactory objectFactory;

  private final String traceIdAsString;

  private final String spanIdAsString;

}

span的核心信息存储在SpanContext中，在构建span时候就会创建，为了防止用户擅自修改核心信息，spanContext中的所有成员都是final修饰的。

根据opentracing的规范， SpanContext represents Span state that must propagate to descendant Spans and across process boundaries. SpanContext is logically divided into two pieces:

(1) the user-level "Baggage" that propagates across Span boundaries and

(2) any Tracer-implementation-specific fields that are needed to identify or otherwise contextualize the associated Span instance (e.g., a tuple).

上面是说SpanContext代表的是span中必须传递的信息，在逻辑上分为两部分，一分部分是普通的traceId，spanId等信息，另一部分是baggage这种用户自定义需要传递的信息。

JaegerSpanContext这里只是保存了上下文环境应有的信息，与 SofaTraceContext 不同，SofaTraceContext 里面还存有Span，但是在 Jaeger，这个功能是在 ScopeManager中完成的。

5.4 Reporter

默认的 RemoteReporter 实现了 Reporter，功能就是我们在前文中所说的发送报告。

public class RemoteReporter implements Reporter {

  private static final int DEFAULT_CLOSE_ENQUEUE_TIMEOUT_MILLIS = 1000;

  public static final int DEFAULT_FLUSH_INTERVAL_MS = 1000;

  public static final int DEFAULT_MAX_QUEUE_SIZE = 100;

  private final Sender sender;

  private final int closeEnqueueTimeout;

  @ToString.Exclude private final BlockingQueue<Command> commandQueue;

  @ToString.Exclude private final Timer flushTimer;

  @ToString.Exclude private final Thread queueProcessorThread;

  @ToString.Exclude private final QueueProcessor queueProcessor;

  @ToString.Exclude private final Metrics metrics;

}

5.5 Scope

OpenTracing 抽象了Scope(active span) 和 ScopeManager(设置Scope与获取当前Scope)概念。简单来说，OpenTracing-Java的实现中，用Scope和ScopeManager 来处理了OpenTracing中的上下文（即：get_current_span 过程）；

为什么要抽象出Scope的概念？直接使用ThreadLocal 存储Span不就可以了吗？

答：首先理解Scope是什么？Scope 是Active Span的一个容器， Scope 代表着当前活跃的Span; 是对当前活跃Span的一个抽象，代表了当前上下文所处于的一个过程；

另外， ThreadLocalScope 还记录了 toRestore Span, 这样结束时，可以恢复到上一个Span的状态；

我理解如果只是 get_current_span() 逻辑的话，直接把 span 塞到 ThreadLocal里就可以在线程内传递了；但是ScopeManager看代码是这样实现的，ScopeManager 包含一个 Scope, Scope 又包含了当前Span, recover Scope；我理解它的好处是：这样就保证了，如果开启一个子Span（子span 会产生孙子span），这样子span 结束后，还可以回到父span （这样可以继续产生以父span 为基础的兄弟span）, 如果只是ThreadLocal 里塞一个当前span的话，是解决不了这种情况的。

或者说

在多线程环境下ScopeManager管理着各个线程的Scope，而每个线程中的Scope管理着该线程中的Span。这样当某个线程需要获取其线程中当前 活动的 span时，可以通过ScopeManager找到对应该线程的Scope，并从Scope中取出该线程 活动的 span。

Scope 对象是 Active Span的容器；通过Scope能拿到当前上下文内的Active Span;

io.opentracing.util.ThreadLocalScope 是Scope的一个实现，通过ThreadLocal 来存储；

构造函数就是把目前Span暂存，然后把传入的参数Span设置为当前Span。即将之前活动的scope作为当前scope的属性toRestore来存储，并将当前scope设置到scopeManager中作为当前线程最新的scope。
在操作当span操作完成（span.finish）时，需要调用scope.close方法做恢复，触发关联新的激活span，否则调用链条会出错。

具体定义如下：

public class ThreadLocalScope implements Scope {

    private final ThreadLocalScopeManager scopeManager;

    private final Span wrapped; // 当前 Active Span

    private final ThreadLocalScope toRestore; // 上一Active Span,wrapped 结束时，会恢复到此Span

    ThreadLocalScope(ThreadLocalScopeManager scopeManager, Span wrapped) {

        this.scopeManager = scopeManager;

        this.wrapped = wrapped;

        // 这两句设置了当前活动Scope

        this.toRestore = scopeManager.tlsScope.get();

        scopeManager.tlsScope.set(this);

    }

    @Override

    public void close() {

        if (scopeManager.tlsScope.get() != this) {

            // This shouldn't happen if users call methods in the expected order. Bail out.

            return;

        }

        scopeManager.tlsScope.set(toRestore);

    }

    Span span() {

        return wrapped;

    }

}

5.6 ScopeManager

Scope是站在CPU角度激活或者失效Span。ScopeManager管理Scope。一个Scope里可以有多个span，但是只有一个激活的span。

在多线程环境下ScopeManager管理着各个线程的Scope，而每个线程中的Scope管理着该线程中的Span。这样当某个线程需要获取其线程中当前活动的 span时，可以通过ScopeManager找到对应该线程的Scope，并从Scope中取出该线程 活动的 span。

有了ScopeManager，我们就可以通过 scopeManager.activeSpan() 方法获取到当前Span，并且通过scopeManager().activate(span) 方法设置当前上下文active span;

io.opentracing.util.ThreadLocalScopeManager 是opentracing提供的ScopeManager的实现，Jaeger并没有自己重写一个新类，而是直接使用ThreadLocalScopeManager。

activate 函数的作用是激活当前 Span。返回Scope（可以理解为代表当前 Span 活跃的一个阶段）。即调用ThreadLocalScope的构造方法，将传入的span激活为 当前活动的 span。我们看一下ThreadLocalScope构造函数就能发现，与其说是激活传入的span倒不如说是激活包裹(wrapped)该span的scope为 当前活动的 scope。

Span 活跃期结束后，需要关闭 Scope, 推荐使用 try-with-resources 关闭。
activeSpan函数则是返回当前激活（active）状态Span, 无则返回null。

public class ThreadLocalScopeManager implements ScopeManager {

    // 使用原始的ThreadLocal 来存储 Active Span; ScopeManager中仅包含一个 Scope( Active Span)， 即当前上下文中的 active span

    final ThreadLocal<ThreadLocalScope> tlsScope = new ThreadLocal<ThreadLocalScope>();

    // 可以看到，activate 函数就是把span放进一个新生成的 ThreadLocalScope 中，其实就是tlsScope 成员变量中。

    @Override

    public Scope activate(Span span) {

        return new ThreadLocalScope(this, span);

    }

    @Override

    public Span activeSpan() {

        ThreadLocalScope scope = tlsScope.get();

        return scope == null ? null : scope.span();

    }

}

Jaeger使用scopeManager来处理管理了上下文，可以从 scopeManager中拿到当前上下文Span；那具体是在哪里设置的父子关系呢？

在OpenTracing-Java实现中，是在 tracer.start() 方法中处理的；start() 方法中通过 scopeManager 判断是存在active span，若存在则生成CHILD_OF关系的上下文，如果不存在则createNewContext;

这点和SOFATtacer不同，SOFATtacer把这个上下文管理功能放在了SofaTraceContext之中，确实在分析代码时候感到有些许混乱。

5.7 SpanID & TraceID

SpanId 和 TraceID 都是在构建SpanContext 时候生成的。

private JaegerSpanContext createNewContext() {

  String debugId = getDebugId();

  long spanId = Utils.uniqueId();  // span

  long traceIdLow = spanId;  // trace

  long traceIdHigh = isUseTraceId128Bit() ? Utils.uniqueId() : 0;

	......

}

具体规则如下：

public static long uniqueId() {

  long val = 0;

  while (val == 0) {

    val = Java6CompatibleThreadLocalRandom.current().nextLong();

  }

  return val;

}

然后是调用到了ThreadLocalRandom # current。

public static Random current() {

  if (threadLocalRandomPresent) {

    return ThreadLocalRandomAccessor.getCurrentThreadLocalRandom();

  } else {

    return threadLocal.get();

  }

}

static class ThreadLocalRandomAccessor {

    @IgnoreJRERequirement

    private static Random getCurrentThreadLocalRandom() {

      return ThreadLocalRandom.current();

    }

}

最后格式如下：

context = {JaegerSpanContext@1701} "c29c9e0f4a0a681c:36217443515fc248:c29c9e0f4a0a681c:1"

 traceIdLow = -4423486945480775652

 traceIdHigh = 0

 spanId = 3900526584756421192

 parentId = -4423486945480775652

 flags = 1

 baggage = {HashMap@1693}  size = 1

 debugId = null

 objectFactory = {JaegerObjectFactory@1673}

 traceIdAsString = "c29c9e0f4a0a681c"

 spanIdAsString = "36217443515fc248"

0x06 启动

6.1 手动埋点

要通过Jaeger将Java应用数据上报至链路追踪控制台，首先需要完成埋点工作。本示例为手动埋点。

6.2 pom配置

pom.xml中添加了对Jaeger客户端的依赖。

<dependency>

    <groupId>io.jaegertracing</groupId>

    <artifactId>jaeger-client</artifactId>

    <version>${jaeger.version}</version>

</dependency>

6.3 启动

示例代码并没有使用注入的组件，而是手动启动，具体启动/初始化代码如下：

public final class Tracing {

    private Tracing() { }

    public static JaegerTracer init(String service) {

        SamplerConfiguration samplerConfig = SamplerConfiguration.fromEnv()

                .withType(ConstSampler.TYPE)

                .withParam(1);

        ReporterConfiguration reporterConfig = ReporterConfiguration.fromEnv()

                .withLogSpans(true);

        // 这里启动

        Configuration config = new Configuration(service)

                .withSampler(samplerConfig)

                .withReporter(reporterConfig);

        return config.getTracer();

    }

}

示例中启动的 io.dropwizard.Application 都会调用init进行初始化。

try (JaegerTracer tracer = Tracing.init("publisher")) {

    new Publisher(tracer).run("server");

}

具体启动逻辑都是在 io.jaegertracing.Configuration 中完成的。我们可以看到其中实现了众多配置和一个tracer。

6.4 构建Tracer

上节代码中有 config.getTracer(); ，这就是 jaeger采用builder模式来构建Tracer。

public class Configuration {

    private String serviceName;

    private Configuration.SamplerConfiguration samplerConfig;

    private Configuration.ReporterConfiguration reporterConfig;

    private Configuration.CodecConfiguration codecConfig;

    private MetricsFactory metricsFactory;

    private Map<String, String> tracerTags;

    private boolean useTraceId128Bit;

    private JaegerTracer tracer;

    public synchronized JaegerTracer getTracer() {

      if (tracer != null) {

        return tracer;

      }

      tracer = getTracerBuilder().build(); // 构建

      return tracer;

    }

    ......

}

build()方法最终完成了Tracer对象的构造。

默认使用RemoteReporter来report Span到agent，
采样默认使用RemoteControlledSampler。
共同使用的metrics是在Builder内部类中的有默认值的成员变量metrics。

public JaegerTracer build() {

  if (reporter == null) {

    reporter = new RemoteReporter.Builder()

        .withMetrics(metrics)

        .build();

  }

  if (sampler == null) {

    sampler = new RemoteControlledSampler.Builder(serviceName)

        .withMetrics(metrics)

        .build();

  }

  return createTracer();

}

protected JaegerTracer createTracer() {

      return new JaegerTracer(this);

}

Tracer对象可以用来创建Span对象以便记录分布式操作时间、通过Extract/Inject方法跨机器透传数据、或设置当前Span。Tracer对象还配置了上报数据的网关地址、本机IP地址、采样率、服务名等数据。用户可以通过调整采样率来减少因上报数据产生的开销。

在启动之后，用户得到 Tracer 来进行后续手动埋点。

JaegerTracer tracer = Tracing.init("hello-world")

0x07 客户端发送

下面都是手动埋点。

7.1 构建Span

构造Span对象是一件很简单的事情，通过opentracing对Tracer接口的规定可知Span是由Tracer负责构造的，如下我们“启动”了一个Span（实际上只是构造了该对象而已）：

Span span = tracer.buildSpan("printHello").start();

Tracer中的start方法(开启一个Span) 使用了scopeManager 来获取上下文，从而来处理父子关系；

public JaegerSpan start() {

      // 此处从ScopeManager获取上下文（线程）中，获取到激活的Span, 而后创建父子关系

      if (this.references.isEmpty() && !this.ignoreActiveSpan && null != JaegerTracer.this.scopeManager.activeSpan()) {

                this.asChildOf(JaegerTracer.this.scopeManager.activeSpan());

      }

      JaegerSpanContext context;

      if (!this.references.isEmpty() && ((Reference)this.references.get(0)).getSpanContext().hasTrace()) {

                context = this.createChildContext();

      } else {

                context = this.createNewContext();

      }

      ...

      return jaegerSpan;

}

7.2 Parent Span

本示例中会涉及到两个Span：Parent Span 和 Child Span。我们首先介绍 Parent Span。

其大致策略是：

调用 tracer.buildSpan("say-hello").start() 生成Span
- asChildOf(scopeManager.activeSpan()); 这里构建了Span之间的关系，即本 span在初始化时就先构建了与之前span的关系。
- createNewContext() 或者 createChildContext()。如果是root span就随机生成id作为traceId与spanId，如果不是root span则使用reference属性中找到该span的parent span（根据是否为child_of的关系来判断）获取其traceId作为自己的traceId，获取其spanId作为自己的parentId。
调用 tracer.scopeManager().activate 函数就是把span放进一个新生成的 ThreadLocalScope 中，其实就是 tlsScope 成员变量中。结果是后续可以通过tracer.scopeManager.activeSpan();获取span信息。
setTag
setBaggageItem
最后finish

具体代码如下：

private void sayHello(String helloTo, String greeting) {

        Span span = tracer.buildSpan("say-hello").start();

        try (Scope scope = tracer.scopeManager().activate(span)) {

            span.setTag("hello-to", helloTo);

            span.setBaggageItem("greeting", greeting);

            String helloStr = formatString(helloTo);

            printHello(helloStr);

        } finally {

            span.finish();

        }

}

得到的运行时Span如下：

span = {JaegerSpan@1685}

 startTimeMicroseconds = 1598707136698000

 startTimeNanoTicks = 1018098763618500

 computeDurationViaNanoTicks = true

 tags = {HashMap@1700}  size = 2

 durationMicroseconds = 0

 operationName = "say-hello"

 references = {ArrayList@1701}  size = 0

 context = {JaegerSpanContext@1666} "c8b87cc5fb01ef31:c8b87cc5fb01ef31:0:1"

  traceIdLow = -3983296680647594191

  traceIdHigh = 0

  spanId = -3983296680647594191

  parentId = 0

  flags = 1

  baggage = {Collections$EmptyMap@1704}  size = 0

  debugId = null

  objectFactory = {JaegerObjectFactory@994}

  traceIdAsString = "c8b87cc5fb01ef31"

  spanIdAsString = "c8b87cc5fb01ef31"

 logs = null

 finished = false

7.3 Child Span

示例代码然后在 formatString 中会：

生成一个子 Span
加入了Tag
调用Inject方法传入Context信息。
并且会调用http请求。

具体代码如下：

private String getHttp(int port, String path, String param, String value) {

		HttpUrl url = new HttpUrl.Builder().scheme("http").host("localhost").port(port).addPathSegment(path)

                    .addQueryParameter(param, value).build();

		Request.Builder requestBuilder = new Request.Builder().url(url);

  	Span activeSpan = tracer.activeSpan();

    Tags.SPAN_KIND.set(activeSpan, Tags.SPAN_KIND_CLIENT);

    Tags.HTTP_METHOD.set(activeSpan, "GET");

    Tags.HTTP_URL.set(activeSpan, url.toString());

    tracer.inject(activeSpan.context(), Format.Builtin.HTTP_HEADERS,

                  Tracing.requestBuilderCarrier(requestBuilder));

    Request request = requestBuilder.build();

    Response response = client.newCall(request).execute();

}

7.4 Inject

上文中的 tracer.inject 函数，是用来把 SpanContext 的信息序列化到 Request.Builder 之中。这样后续操作就可以把序列化之后的信息转换到 Header之中。

tracer.inject(activeSpan.context(), Format.Builtin.HTTP_HEADERS,

              Tracing.requestBuilderCarrier(requestBuilder));

具体序列化代码如下：

public void inject(JaegerSpanContext spanContext, TextMap carrier) {

  carrier.put(contextKey, encodedValue(contextAsString(spanContext)));

  for (Map.Entry<String, String> entry : spanContext.baggageItems()) {

    carrier.put(keys.prefixedKey(entry.getKey(), baggagePrefix), encodedValue(entry.getValue()));

  }

}

7.5 Finish

当服务端返回之后，在Client端，jaeger会进行后续操作：finish，report。

调用span.finish()方法标志着span的结束。finish方法应该是对应span实例的最后一个调用的方法。在span中finish方法还只是校验和记录的作用，真正发送span的就是开头提到的tracer，tracer包含了sampler、report等全局的功能，因此在finish中调用了tracer.report(span)方法。而tracer中的report方法是使用其成员report的report方法，上面讲过默认实现是RemoteReporter，它默认使用的是UdpSender。

span.finish会触发span上报。调用了 JaegerSpan.finishWithDuration。其中会判断本次Trace是否采样。如果是采样了，就会上报。

  @Override

  public void finish(long finishMicros) {

    finishWithDuration(finishMicros - startTimeMicroseconds);

  }

  private void finishWithDuration(long durationMicros) {

    synchronized (this) {

      if (finished) {

        log.warn("Span has already been finished; will not be reported again.");

        return;

      }

      finished = true;

      this.durationMicroseconds = durationMicros;

    }

    if (context.isSampled()) {

      tracer.reportSpan(this);

    }

  }

7.6 Reporter

上报是在 RemoteReporter 中。

在RemoteReporter中有一个BlockingQueue队列其作用是接收Command接口的实现类，其长度可在构造方法中传入。在RemoteReporter的构造函数中开启了两个守护线程。一个线程定时往BlockingQueue队列中添加flush命令，另外一个线程不停的从BlockingQueue队列中take数据，然后执行Command.excute()方法。而report(span)方法就是往BlockingQueue队列中添加AppendCommand类。

  @Override

  public void report(JaegerSpan span) {

    // Its better to drop spans, than to block here

    boolean added = commandQueue.offer(new AppendCommand(span));

    if (!added) {

      metrics.reporterDropped.inc(1);

    }

  }

可以看到如果返回的added变量为false，也就是队列满了无法再加入数据，就会抛弃该span的，最终该span的信息不会发送到agent中。因此队列的长度也是有一定的影响。

而AppendCommand类的excute()方法为：

class AppendCommand implements Command {

    private final Span span;

    public AppendCommand(Span span) {

      this.span = span;

    }

    @Override

    public void execute() throws SenderException {

      sender.append(span);

    }

  }

所以，我们看到，execute()方法并不是真正的发送span了，而只是把span添加到sender中去，由sender实现span的发送，reporter类只负责发送刷新与发送的命令。

如果我们继续深入下去，会发现UdpSender是抽象类ThriftSender的实现类，sender.append(span)方法调用的是ThriftSender的append(Span)方法，而该方法又会调用ThriftSender的flush()方法，最后这个flush()方法会调用抽象类ThriftSender的抽象方法send(Process process, List spans)。

Jaeger中其他Reporter如下：

CompositeReporter顾名思义就是将各个reporter组合起来，内部有一个list，它所实现的接口的 report(Span span)方法也只是把list中的所有reporter依次调用report(Span span)方法而已。
InMemoryReporter类是将Span存到内存中，该类含有一个list用于存储span，该类中的report方法即为将span通过add方法添加到list中，通过getSpans()方法获取到list，同时有clear()方法清除list数据。
LoggingReporter类作用是将span作为日志内容打印出来，其report方法即为log.info()打印span的内容。
NoopReporter是一个实现了Reporter接口但是实现方法为空的一个类，表示使用该类report span将毫无影响。

0x08 服务端接受

8.1 手动埋点

服务端也是手动埋点。

public class FormatterResource {

    @GET

    public String format(@QueryParam("helloTo") String helloTo, @Context HttpHeaders httpHeaders) {

        Span span = Tracing.startServerSpan(tracer, httpHeaders, "format");

        try (Scope scope = tracer.scopeManager().activate(span)) {

            String greeting = span.getBaggageItem("greeting");

            if (greeting == null) {

                greeting = "Hello";

            }

            String helloStr = String.format("%s, %s!", greeting, helloTo);

            span.log(ImmutableMap.of("event", "string-format", "value", helloStr));

            return helloStr;

        } finally {

            span.finish();

        }

    }

}

8.2 业务逻辑

业务逻辑在 startServerSpan 之中：

调用Extract方法解析Context信息。
根据是否有Parent Context 来进行Span构建，其中会用到SpanContext。

具体代码如下：

public static Span startServerSpan(Tracer tracer, javax.ws.rs.core.HttpHeaders httpHeaders, String operationName) {

        // format the headers for extraction

        MultivaluedMap<String, String> rawHeaders = httpHeaders.getRequestHeaders();

        final HashMap<String, String> headers = new HashMap<String, String>();

        for (String key : rawHeaders.keySet()) {

            headers.put(key, rawHeaders.get(key).get(0));

        }

        Tracer.SpanBuilder spanBuilder;

        try {

            SpanContext parentSpanCtx = tracer.extract(Format.Builtin.HTTP_HEADERS, new TextMapAdapter(headers));

            if (parentSpanCtx == null) {

                spanBuilder = tracer.buildSpan(operationName);

            } else {

                spanBuilder = tracer.buildSpan(operationName).asChildOf(parentSpanCtx);

            }

        } catch (IllegalArgumentException e) {

            spanBuilder = tracer.buildSpan(operationName);

        }

        // TODO could add more tags like http.url

        return spanBuilder.withTag(Tags.SPAN_KIND.getKey(), Tags.SPAN_KIND_SERVER).start();

}

8.3 解析Context

解析代码如下：

public JaegerSpanContext extract(TextMap carrier) {

  JaegerSpanContext context = null;

  Map<String, String> baggage = null;

  String debugId = null;

  for (Map.Entry<String, String> entry : carrier) {

    // TODO there should be no lower-case here

    String key = entry.getKey().toLowerCase(Locale.ROOT);

    if (key.equals(contextKey)) {

      context = contextFromString(decodedValue(entry.getValue()));

    } else if (key.equals(Constants.DEBUG_ID_HEADER_KEY)) {

      debugId = decodedValue(entry.getValue());

    } else if (key.startsWith(baggagePrefix)) {

      if (baggage == null) {

        baggage = new HashMap<String, String>();

      }

      baggage.put(keys.unprefixedKey(key, baggagePrefix), decodedValue(entry.getValue()));

    } else if (key.equals(Constants.BAGGAGE_HEADER_KEY)) {

      baggage = parseBaggageHeader(decodedValue(entry.getValue()), baggage);

    }

  }

  if (debugId == null && baggage == null) {

    return context;

  }

  return objectFactory.createSpanContext(

    context == null ? 0L : context.getTraceIdHigh(),

    context == null ? 0L : context.getTraceIdLow(),

    context == null ? 0L : context.getSpanId(),

    context == null ? 0L : context.getParentId(),

    context == null ? (byte)0 : context.getFlags(),

    baggage,

    debugId);

}

0x09 问题解答

Jaeger 和 SOFATracer 对比如何？
- Jaeger对OpenTracing支持的更完备，版本更高。
spanId是怎么生成的，有什么规则?
traceId是怎么生成的，有什么规则？
- 最终都是调用到 ThreadLocalRandom # current # nextLong 完成，举例如下：
- ```
 traceIdLow = -4423486945480775652

 traceIdHigh = 0

 spanId = 3900526584756421192

 parentId = -4423486945480775652
```
客户端哪里生成的Span？
- 本示例代码是手动调用 tracer.buildSpan("say-hello").start() 生成Span。
ParentSpan 从哪儿来？
- 在客户端发送阶段，先从 scopeManager.activeSpan 获取当前活动span。如果不为空，则需要给新span设置父亲Span。
  - ```
  if (references.isEmpty() && !ignoreActiveSpan && null != scopeManager.activeSpan()) {
  
    asChildOf(scopeManager.activeSpan());
  
  }
```
ChildSpan由ParentSpan创建，那么什么时候创建？
- 在OpenTracing-Java实现中，是在 tracer.start() 方法中处理的；start() 方法中通过 scopeManager 判断是存在active span ，若存在则生成CHILD_OF关系的上下文，如果不存在则createNewContext;
Trace信息怎么传递？
- 把 SpanContext 的信息序列化到 Request.Builder 之中。后续操作把序列化之后的信息转换到 Header之中，然后就可以传递。
服务器接收到请求之后做什么？
- 调用Extract方法解析Context信息。
- 根据是否有Parent Context 来进行Span构建，其中会用到SpanContext。
- 进行具体其他业务。
SpanContext在服务器端怎么处理？见上问题回答。
链路信息如何搜集？
- 采样是对于整条链路来说的，也就是说从 RootSpan 被创建开始，就已经决定了当前链路数据是否会被记录了。
- 如果已经确定本次Trace被采样，就会发送报告。

0xFF 参考

分布式追踪系统 -- Opentracing

开放分布式追踪（OpenTracing）入门与 Jaeger 实现

OpenTracing 语义说明

分布式追踪系统概述及主流开源系统对比

Skywalking分布式追踪与监控：起始篇

分布式全链路监控 -- opentracing小试

opentracing实战

Go微服务全链路跟踪详解

OpenTracing Java Library教程(3)——跨服务传递SpanContext

OpenTracing Java Library教程(1)——trace和span入门

蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析

蚂蚁金服开源分布式链路跟踪组件 SOFATracer 链路透传原理与SLF4J MDC 的扩展能力剖析

蚂蚁金服开源分布式链路跟踪组件 SOFATracer 采样策略和源码剖析

https://github.com/sofastack-guides/sofa-tracer-guides

The OpenTracing Semantic Specification

OpenTracing Java Library教程(2)——进程间传递SpanContext

OpenTracing Java Library教程(4)——Baggage介绍

https://github.com/yurishkuro/opentracing-tutorial

微服务系统架构之分布式traceId追踪参考实现

监控之traceid

jaeger代码阅读思路整理

分布式系统中如何优雅地追踪日志（原理篇）traceid

sky-walking的traceId生成

分布式链路追踪系列番外篇一（jaeger异步批量发送span）

分布式链路追踪系列番外篇二（Spark Job优化记）

Jaeger服务端埋点分析

通过Jaeger上报Java应用数据

OpenTracing(Jaeger) 遭遇多线程

OpenTracing-Java Scope与ScopeManager

OpenTracing-Java实现的灵魂十问

OpenTracing实现思路（附OpenTracing-Jaeger-Java实例）

OpenTracing API 自动埋点调研

Jaeger服务端埋点分析

OpenTracing(Jaeger) 遭遇多线程

jaegeropentracing的Java-client完整分布式追踪链

基于opentracing + jaeger 实现全链路追踪

jaeger代码阅读思路整理