全链路追踪之OpenTracing

链路追踪

现在的大多数互联网服务，基本都是用复杂，大规模分布式集群来实现，微服务化，这些服务模块分布在不同的机器，不同的数据中心，由不同团队，语言开发而成。因此，需要工具帮助理解，分析这些系统、定位问题，做到追踪每一个请求的完整调用链路，收集性能数据，反馈到服务治理中，链路追踪系统应运而生。

OpenTracing 协议

OpenTracing是分布式跟踪系统，当我们把系统拆成服务化，分布式系统的时候，查询一个问题，很可能需要多个登录多台机器。

OpenTracing通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加（或更换）追踪系统的实现。OpenTracing正在为全球的分布式追踪，提供统一的概念和数据标准。

Trace

• OpenTracing中的Trace（调用链）通过归属于此调用链的Span来隐性的定义。
• 一条Trace（调用链）可以被认为是一个由多个Span组成的有向无环图（DAG图），

Span

• Span可以被翻译为跨度，可以被理解为一次方法调用, 一个程序块的调用, 或者一次RPC/数据库访问
• 只要是一个具有完整时间周期的程序访问，都可以被认为是一个span
• Span与Span的关系被命名为References。

以下是由8个Span组成的Trace

单个Trace中，span间的因果关系


        [Span A]  ←←←(the root span)
            |
     +------+------+
     |             |
 [Span B]      [Span C] ←←←(Span C 是 Span A 的孩子节点, ChildOf)
     |             |
 [Span D]      +---+-------+
               |           |
           [Span E]    [Span F] >>> [Span G] >>> [Span H]
                                       ↑
                                       ↑
                                       ↑
                         (Span G 在 Span F 后被调用, FollowsFrom)

基于时间轴的时序图

单个Trace中，span间的时间关系

––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time

 [Span A···················································]
   [Span B··············································]
      [Span D··········································]
    [Span C········································]
         [Span E·······]        [Span F··] [Span G··] [Span H··]

span 的结构

Span

• An operation name，操作名称
• A start timestamp，起始时间
• A finish timestamp，结束时间
• Span Tag，一组键值对构成的Span标签集合。键值对中，键必须为string，值可以是字符串，布尔，或者数字类型。
• Span Log，一组span的日志集合。
  • 每次log操作包含一个键值对，以及一个时间戳。
  • 键值对中，键必须为string，值可以是任意类型。
  • 不是所有的支持OpenTracing的Tracer,都需要支持所有的值类型。
• SpanContext，Span上下文对象
• References(Span 间关系)，相关的零个或者多个Span（Span间通过SpanContext建立这种关系）

SpanContext

• 任何一个OpenTracing的实现，都需要将当前调用链的状态（例如：trace和spanId），依赖一个独特的Span去跨进程边界传输
• Baggage Items，Trace的随行数据，是一个键值对集合，它存在于trace中，也需要跨进程边界传输

span 的关系

一个Span可以与一个或者多个SpanContexts存在因果关系。OpenTracing目前定义了两种关系，这两种关系明确的给出了两个父子关系的Span的因果模型。

• ChildOf（父子）,
• FollowsFrom（跟随）。

ChildOf

一个span可能是一个父级span的孩子，即ChildOf关系。在ChildOf引用关系下，父级span某种程度上取决于子span。下面这些情况会构成ChildOf关系：

• 一个RPC调用的服务端的span，和RPC服务客户端的span构成ChildOf关系
• 一个数据库insert操作的span，和ORM的save方法的span构成ChildOf关系
• 很多span可以并行工作（或者分布式工作）都可能是一个父级的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之间是FollowsFrom的因果关系。FollowsFrom关系可以被分为很多不同的子类型.

FollowFrom关系的父子节点关系的时序图。

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

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

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