概念和组件说明

Jaeger（音译：耶格）是一款广受欢迎的开源分布式链路跟踪系统，兼容OpenTracing API，且已加入CNCF开源组织。其主要功能是聚合来自各个异构系统的实时监控数据。

官网：jaeger

官方包支持语言：
OpenTracing Tutorial (Java, Go, Python, Node.js, C#) (tutorials)

jaeger架构

按照数据流向，整体可以分为四个部分：

• jaeger-client：Jaeger 的客户端，实现了 OpenTracing 的 API，支持主流编程语言。客户端直接集成在目标 Application 中，其作用是记录和发送 Span 到 Jaeger Agent。在 Application 中调用 Jaeger Client Library 记录 Span 的过程通常被称为埋点。

• jaeger-agent：暂存 Jaeger Client 发来的 Span，并批量向 Jaeger Collector 发送 Span，一般每台机器上都会部署一个 Jaeger Agent。官方的介绍中还强调了 Jaeger Agent 可以将服务发现的功能从 Client 中抽离出来，不过从架构角度讲，如果是部署在 Kubernetes 或者是 Nomad 中，Jaeger Agent 存在的意义并不大。

• jaeger-collector：接受 Jaeger Agent 发来的数据，并将其写入存储后端，目前支持采用 Cassandra 和 Elasticsearch 作为存储后端。个人还是比较推荐用 Elasticsearch，既可以和日志服务共用同一个 ES，又可以使用 Kibana 对 Trace 数据进行额外的分析。架构图中的存储后端是 Cassandra，旁边还有一个 Spark，讲的就是可以用 Spark 等其他工具对存储后端中的 Span 进行直接分析。

• jaeger-query & jaeger-ui：读取存储后端中的数据，以直观的形式呈现。

Jaeger 的架构非常清晰，部署起来也很轻松，Docker Hub 中有官方打好的 Image，可以拿来直接用，https://hub.docker.com/u/jaegertracing

如果是本地测试，可以直接用 Jaeger 的 all-in-one Image，

具体使用

首先假设某微服务已经有了中心化的日志收集和处理系统，如果还没有的话，强烈建议部署一套 ELK。

再假设对于每一个请求，都会有一个贯穿整个请求流程的 Request ID，如果还没有的话，强烈建议加一个。

以上准备完毕后，可以选取一个分布式追踪系统，集成到服务当中，建议采用 Jaeger。

重点在最后，在 Trace 的起始处，将 Trace ID 设置为 Request ID，这么一来就打通了日志系统和分布式追踪系统，可以使用同一个 ID 查询请求的事件流和日志流，从此开启了上帝视角。

jaeger组件

jaeger由 agent, collector, query, ingester 几个部分组成

• Agent
  通过UDP接收追踪数据
  批量发送到Collector
  部署在主机或者容器中
  jaeger-agent 是客户端代理，需要部署在每台主机上。

• Collector
  接收Agent发送的数据并进行处理
  验证、索引、转换、存储
  支持Cassandra、ElasticSearch和Kafka作为存储
  收集器，可以部署多个。收集 agent 发来的数据并写入 db 或 kafka。

• Query
  从存储后端查询数据并展示

• Ingester
  从 kafka中读取数据并写入存储后端

jaeger组件可以统一布署，也可以分开布署。

统一布署指的是把所有组件打包成单一进程支行，使用的是all-in-one镜像，

分开布署是指单个组件分开各自独立的镜像，适合于数据量大的情况。

数据流

客户端埋点上报数据给 Agent

agent将数据发送给colletor

colletor写入es

query从存储后端查询数据展示