一文搞懂全链路监控：方案概述与比较 | 干货

水深无声 2022-10-25 04:51 482阅读 0赞

> ![format_png][]  
> 
> 
> 原文标题为《全链路监控（一）：方案概述与比较》，作者陶邦仁，链接：https://www.jianshu.com/p/92a12de11f18

![format_png 1][]

#     #

—

问题背景

随着微服务架构的流行，**服务按照不同的维度进行拆分**，一次请求往往需要涉及到多个服务。**互联网应用构建在不同的软件模块集上**，这些软件模块，**有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心**。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。

全链路监控组件就在这样的问题背景下产生了。最出名的是谷歌公开的论文提到的 Google Dapper。**想要在这个上下文中理解分布式系统的行为，就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作**。

所以，**在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路**。一个请求完整调用链可能如下图所示：

![format_png 2][]

那么在业务规模不断增大、服务不断增多以及频繁变更的情况下，面对复杂的调用链路就带来一系列问题：

> 1.  **如何快速发现问题？**
> 2.  **如何判断故障影响范围？**
> 3.  **如何梳理服务依赖以及依赖的合理性？**
> 4.  **如何分析链路性能问题以及实时容量规划？**

**同时我们会关注在请求处理期间各个调用的各项性能指标**，比如：吞吐量（TPS）、响应时间及错误记录等。

> 1.  **吞吐量**，根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。
> 2.  **响应时间**，包括整体调用的响应时间和各个服务的响应时间等。
> 3.  **错误记录**，根据服务返回统计单位时间异常次数。

全链路性能监控 **从整体维度到局部维度展示各项指标**，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。

**有了全链路监控工具，我们能够达到：**

> 1.  **请求链路追踪，故障快速定位**：可以通过调用链结合业务日志快速定位错误信息。
> 2.  **可视化**：各个阶段耗时，进行性能分析。
> 3.  **依赖优化**：各个调用环节的可用性、梳理服务依赖关系以及优化。
> 4.  **数据分析，优化链路**：可以得到用户的行为路径，汇总分析应用在很多业务场景。

—

目标要求

如上所述，那么我们选择全链路监控组件有哪些目标要求呢？Google Dapper中也提到了，总结如下：

**1. 探针的性能消耗**

APM组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗，这就需要调用跟踪的低损耗，实际中还会通过配置采样率的方式，选择一部分请求去分析请求路径。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。

**2. 代码的侵入性**

即也作为业务组件，应当尽可能少入侵或者无入侵其他业务系统，对于使用方透明，减少开发人员的负担。

对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题，这样才是无法满足对跟踪系统“无所不在的部署”这个需求。

**3. 可扩展性**

一个优秀的调用跟踪系统必须支持分布式部署，具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API，对于一些没有监控到的组件，应用开发者也可以自行扩展。

**4. 数据的分析**

数据的分析要快 ，分析的维度尽可能多。跟踪系统能提供足够快的信息反馈，就可以对生产环境下的异常状况做出快速反应。分析的全面，能够避免二次开发。

#     #

—

功能模块

一般的全链路监控系统，大致可分为四大功能模块：

**1.埋点与生成日志**

埋点即系统在当前节点的上下文信息，可以分为 客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容traceId、spanId、调用的开始时间，协议类型、调用方ip和端口，请求的服务名、调用耗时，调用结果，异常信息等，同时预留可扩展字段，为下一步扩展做准备；

>  *  不能造成性能负担：一个价值未被验证，却会影响性能的东西，是很难在公司推广的！
>  *  因为要写log，业务QPS越高，性能影响越重。通过采样和异步log解决。

**2.收集和存储日志**

主要支持分布式日志采集的方案，同时增加MQ作为缓冲；

>  *  每个机器上有一个 deamon 做日志收集，业务进程把自己的Trace发到daemon，daemon把收集Trace往上一级发送；
>  *  多级的collector，类似pub/sub架构，可以负载均衡；
>  *  对聚合的数据进行 实时分析和离线存储；
>  *  离线分析 需要将同一条调用链的日志汇总在一起；

**3.分析和统计调用链路数据，以及时效性**

调用链跟踪分析：把同一TraceID的Span收集起来，按时间排序就是timeline。把ParentID串起来就是调用栈。

抛异常或者超时，在日志里打印TraceID。利用TraceID查询调用链情况，定位问题。

依赖度量：

>  *  强依赖：调用失败会直接中断主流程
>  *  高度依赖：一次链路中调用某个依赖的几率高
>  *  频繁依赖：一次链路调用同一个依赖的次数多

离线分析：按TraceID汇总，通过Span的ID和ParentID还原调用关系，分析链路形态。

实时分析：对单条日志直接分析，不做汇总，重组。得到当前QPS，延迟。

**4.展现以及决策支持**

—

Google Dapper

##     ##

## **3.1 Span**       ##

**基本工作单元**，一次链路调用（可以是 RPC，DB 等没有特定的限制）创建一个 span，通过一个64位 ID 标识它，uuid 较为方便，span 中还有其他的数据，例如描述信息，时间戳，key-value对的（Annotation）tag信息，parent\_id 等,其中 parent-id 可以表示 span 调用链路来源。

![format_png 3][]

上图说明了span在一次大的跟踪过程中是什么样的。**Dapper记录了span名称，以及每个span的ID和父ID，以重建在一次追踪过程中不同span之间的关系**。如果一个span没有父ID被称为root span。**所有span都挂在一个特定的跟踪上，也共用一个跟踪id**。

**Span数据结构**：

type Span struct {
        TraceID    int64 // 用于标示一次完整的请求id
        Name       string
        ID         int64 // 当前这次调用span_id
        ParentID   int64 // 上层服务的调用span_id  最上层服务parent_id为null
        Annotation []Annotation // 用于标记的时间戳
        Debug      bool
    
    
    }

## **3.2 Trace** ##

类似于 **树结构的Span集合**，表示一次完整的跟踪，从请求到服务器开始，服务器返回response结束，跟踪每次 rpc 调用的耗时，存在唯一标识trace\_id。比如：你运行的分布式大数据存储一次 Trace 就由你的一次请求组成。

![format_png 4][]

每种颜色的note标注了一个span，一条链路通过TraceId唯一标识，Span标识发起的请求信息。**树节点是整个架构的基本单元，而每一个节点又是对span的引用**。节点之间的连线表示的span和它的父span直接的关系。虽然span在日志文件中只是简单的代表span的开始和结束时间，他们在整个树形结构中却是相对独立的。

## **3.3 Annotation** ##

**注解，用来记录请求特定事件相关信息（例如时间），一个span中会有多个annotation注解描述**。通常包含四个注解信息：

> (1) **cs**：Client Start，表示客户端发起请求  
> (2) **sr**：Server Receive，表示服务端收到请求  
> (3) **ss**：Server Send，表示服务端完成处理，并将结果发送给客户端  
> (4) **cr**：Client Received，表示客户端获取到服务端返回信息

**Annotation数据结构**：

type Annotation struct {
        Timestamp int64
        Value     string
        Host      Endpoint
        Duration  int32
    }

##     ##

## **3.4 调用示例**    ##

**1. 请求调用示例**

1.  当用户发起一个请求时，首先到达前端A服务，然后分别对B服务和C服务进行RPC调用；
2.  B服务处理完给A做出响应，但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务，最后由A服务来响应用户的请求；

![format_png 5][]

**2. 调用过程追踪**

整个调用过程追踪:

> 1.  请求到来生成一个全局TraceID，通过TraceID可以串联起整个调用链，一个TraceID代表一次请求。
> 2.  除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id，通过他们可以组织一次完整调用链的父子关系。
> 3.  一个没有parent id的span成为root span，可以看成调用链入口。
> 4.  所有这些ID可用全局唯一的64位整数表示；
> 5.  整个调用过程中每个请求都要透传TraceID和SpanID。
> 6.  每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下，并且将自己生成的SpanID也记录下。
> 7.  要查看某次完整的调用则 只要根据TraceID查出所有调用记录，然后通过parent id和span id组织起整个调用父子关系。

1.  ![format_png 6][]
    
    **3. 调用链核心工作**
    
    1.  **调用链数据生成**，对整个调用过程的所有应用进行埋点并输出日志。
    2.  **调用链数据采集**，对各个应用中的日志数据进行采集。
    3.  **调用链数据存储及查询**，对采集到的数据进行存储，由于日志数据量一般都很大，不仅要能对其存储，还需要能提供快速查询。
    4.  **指标运算、存储及查询**，对采集到的日志数据进行各种指标运算，将运算结果保存起来。
    5.  **告警功能**，提供各种阀值警告功能。
    
    **4. 整体部署架构**
    
    ![format_png 7][]
    
    1.  整体部署架构
    2.  通过AGENT生成调用链日志。
    3.  通过logstash采集日志到kafka。
    4.  kafka负责提供数据给下游消费。
    5.  storm计算汇聚指标结果并落到es。
    6.  **storm抽取trace数据并落到es，这是为了提供比较复杂的查询**。比如通过时间维度查询调用链，可以很快查询出所有符合的traceID，**根据这些traceID再去 Hbase 查数据就快了**。
    7.  logstash将kafka原始数据拉取到hbase中。**hbase的rowkey为traceID，根据traceID查询是很快的**。

**5. AGENT无侵入部署**

通过AGENT代理无侵入式部署，将性能测量与业务逻辑完全分离，可以测量任意类的任意方法的执行时间，这种方式大大提高了采集效率，并且减少运维成本。**根据服务跨度主要分为两大类AGENT**：

1.  **a. 服务内AGENT**，这种方式是通过 Java 的agent机制，对服务内部的方法调用层次信息进行数据收集，如方法调用耗时、入参、出参等信息。
    
    **b. 跨服务AGENT**，这种情况需要对主流RPC框架以插件形式提供无缝支持。并通过提供标准数据规范以适应自定义RPC框架：
    
        （1）Dubbo支持；
        （2）Rest支持；
        （3）自定义RPC支持；
    
        6. 调用链监控好处
    
    1.  **准确掌握生产一线应用部署情况**；
    2.  从调用链全流程性能角度，**识别对关键调用链，并进行优化**；
    3.  **提供可追溯的性能数据**，量化 IT 运维部门业务价值；
    4.  **快速定位代码性能问题**，协助开发人员持续性的优化代码；
    5.  **协助开发人员进行白盒测试**，缩短系统上线稳定期；

—

方案比较

市面上的全链路监控理论模型大多都是借鉴 Google Dapper 论文，本文重点关注以下三种APM组件：

> 1.  **Zipkin**：由Twitter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括：数据的收集、存储、查找和展现。
> 2.  **Pinpoint**：一款对Java编写的大规模分布式系统的APM工具，由韩国人开源的分布式跟踪组件。
> 3.  **Skywalking**：国产的优秀APM组件，是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。

**以上三种全链路监控方案需要对比的项提炼出来**：

1.  **探针的性能**
    
    主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。
2.  **collector的可扩展性**
    
    能够水平扩展以便支持大规模服务器集群。
3.  **全面的调用链路数据分析**
    
    提供代码级别的可见性以便轻松定位失败点和瓶颈。
4.  **对于开发透明，容易开关**
    
    添加新功能而无需修改代码，容易启用或者禁用。
5.  **完整的调用链应用拓扑**
    
    自动检测应用拓扑，帮助你搞清楚应用的架构

##     ##

## **4.1 探针的性能** ##

比较关注探针的性能，毕竟APM定位还是工具，如果启用了链路监控组建后，直接导致吞吐量降低过半，那也是不能接受的。对skywalking、zipkin、pinpoint进行了压测，并与基线（未使用探针）的情况进行了对比。

选用了一个常见的基于Spring的应用程序，他包含Spring Boot, Spring MVC，redis客户端，mysql。监控这个应用程序，每个trace，探针会抓取5个span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。这边基本和 skywalkingtest 的测试应用差不多。

模拟了三种并发用户：500，750，1000。使用jmeter测试，每个线程发送30个请求，设置思考时间为10ms。使用的采样率为1，即100%，这边与生产可能有差别。pinpoint默认的采样率为20，即50%，通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来，一共有12种。下面看下汇总表：

![format_png 8][]

从上表可以看出，在三种链路监控组件中，**skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显**，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器进行的压测，对CPU和memory的影响都差不多在10%之内。

##     ##

## **4.2 collector的可扩展性** ##

collector的可扩展性，使得能够水平扩展以便支持大规模服务器集群。

1.  **zipkin**
    
    开发zipkin-Server（其实就是提供的开箱即用包），zipkin-agent与zipkin-Server通过http或者mq进行通信，**http通信会对正常的访问造成影响，所以还是推荐基于mq异步方式通信**，zipkin-Server通过订阅具体的topic进行消费。这个当然是可以扩展的，**多个zipkin-Server实例进行异步消费mq中的监控信息**。  
      
    
    
    ![format_png 9][]
2.  **skywalking**
    
    skywalking的collector支持两种部署方式：**单机和集群模式。collector与agent之间的通信使用了gRPC**。  
      
    
3.  **pinpoint**
    
    同样，pinpoint也是支持集群和单机部署的。**pinpoint agent通过thrift通信框架，发送链路信息到collector**。

## **4.3 全面的调用链路数据分析** ##

全面的调用链路数据分析，提供代码级别的可见性以便轻松定位失败点和瓶颈。

1.  **zipkin**
    
    ![format_png 10][]
    
    **zipkin的链路监控粒度相对没有那么细**，从上图可以看到调用链中具体到接口级别，再进一步的调用信息并未涉及。  
      
    
2.  **skywalking**  
      
    
    
    ![format_png 11][]
    
      
    **skywalking 还支持20+的中间件、框架、类库**，比如：主流的dubbo、Okhttp，还有DB和消息中间件。上图skywalking链路调用分析截取的比较简单，网关调用user服务，**由于支持众多的中间件，所以skywalking链路调用分析比zipkin完备些**。  
      
    
3.  **pinpoint**  
      
    
    
    ![format_png 12][]
    
    pinpoint应该是这三种APM组件中，**数据分析最为完备的组件**。提供代码级别的可见性以便轻松定位失败点和瓶颈，上图可以看到对于执行的sql语句，都进行了记录。还可以配置报警规则等，设置每个应用对应的负责人，根据配置的规则报警，支持的中间件和框架也比较完备。

## **4.4 对于开发透明，容易开关**       ##

对于开发透明，容易开关，添加新功能而无需修改代码，容易启用或者禁用。我们期望功能可以不修改代码就工作并希望得到代码级别的可见性。

对于这一点，**Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能**。但是，它要求在需要时修改代码。**skywalking和pinpoint都是基于字节码增强的方式，开发人员不需要修改代码，并且可以收集到更多精确的数据因为有字节码中的更多信息**。

## **4.5 完整的调用链应用拓扑**       ##

自动检测应用拓扑，帮助你搞清楚应用的架构。

![format_png 13][]

![format_png 14][]

![format_png 15][]

上面三幅图，分别展示了APM组件各自的调用拓扑，都能实现完整的调用链应用拓扑。相对来说，**pinpoint界面显示的更加丰富，具体到调用的DB名，zipkin的拓扑局限于服务于服务之间**。

## **4.6 Pinpoint与Zipkin细化比较**       ##

### **4.6.1 Pinpoint与Zipkin差异性**       ###

1.  **Pinpoint 是一个完整的性能监控解决方案**：有从探针、收集器、存储到 Web 界面等全套体系；**而 Zipkin 只侧重收集器和存储服务**，虽然也有用户界面，但其功能与 Pinpoint 不可同日而语。**反而 Zipkin 提供有 Query 接口**，更强大的用户界面和系统集成能力，可以基于该接口二次开发实现。  
      
    
2.  **Zipkin 官方提供有基于 Finagle 框架（Scala 语言）的接口**，而其他框架的接口由社区贡献，目前可以支持 Java、Scala、Node、Go、Python、Ruby 和 C\# 等主流开发语言和框架；但是**Pinpoint 目前只有官方提供的 Java Agent 探针**，其他的都在请求社区支援中（请参见 \#1759 和 \#1760）。  
      
    
3.  Pinpoint 提供有 Java Agent 探针，通过字节码注入的方式实现调用拦截和数据收集，**可以做到真正的代码无侵入，只需要在启动服务器的时候添加一些参数，就可以完成探针的部署**；而 **Zipkin 的 Java 接口实现 Brave**，只提供了基本的操作 API，如果需要与框架或者项目集成的话，**就需要手动添加配置文件或增加代码**。  
      
    
4.  **Pinpoint 的后端存储基于 HBase，而 Zipkin 基于 Cassandra**。

###    **4.6.2 Pinpoint与Zipkin相似性**       ###

Pinpoint 与 Zipkin 都是基于 Google Dapper 的那篇论文，因此理论基础大致相同。**两者都是将服务调用拆分成若干有级联关系的 Span，通过 SpanId 和 ParentSpanId 来进行调用关系的级联；最后再将整个调用链流经的所有的 Span 汇聚成一个 Trace，报告给服务端的 collector 进行收集和存储**。

即便在这一点上，Pinpoint 所采用的概念也不完全与那篇论文一致。比如他采用 **TransactionId 来取代 TraceId，而真正的 TraceId 是一个结构，里面包含了 TransactionId, SpanId 和 ParentSpanId**。而且 Pinpoint 在 Span 下面又增加了一个 SpanEvent 结构，用来记录一个 Span 内部的调用细节（比如具体的方法调用等等），因此 **Pinpoint 默认会比 Zipkin 记录更多的跟踪数据**。  
  
但是理论上并没有限定 Span 的粒度大小，所以一个服务调用可以是一个 Span，那么每个服务中的方法调用也可以是个 Span，这样的话，**其实 Brave 也可以跟踪到方法调用级别，只是具体实现并没有这样做而已**。

### **4.6.3 字节码注入 vs API 调用**       ###

Pinpoint 实现了基于字节码注入的 Java Agent 探针，而 Zipkin 的 Brave 框架仅仅提供了应用层面的 API，但是细想问题远不那么简单。**字节码注入是一种简单粗暴的解决方案，理论上来说无论任何方法调用，都可以通过注入代码的方式实现拦截，也就是说没有实现不了的，只有不会实现的**。但 Brave 则不同，**其提供的应用层面的 API 还需要框架底层驱动的支持，才能实现拦截**。  
  
比如，MySQL 的 JDBC 驱动，就提供有注入 interceptor 的方法，因此只需要实现 StatementInterceptor 接口，并在 Connection String 中进行配置，就可以很简单的实现相关拦截；而与此相对的，低版本的 MongoDB 的驱动或者是 Spring Data MongoDB 的实现就没有如此接口，想要实现拦截查询语句的功能，就比较困难。

因此在这一点上，Brave 是硬伤，无论使用字节码注入多么困难，但至少也是可以实现的，但是 Brave 却有无从下手的可能，而且是否可以注入，能够多大程度上注入，更多的取决于框架的 API 而不是自身的能力。

### **4.6.4 难度及成本**       ###

经过简单阅读 Pinpoint 和 Brave 插件的代码，可以发现两者的实现难度有天壤之别。**在都没有任何开发文档支撑的前提下，Brave 比 Pinpoint 更容易上手**。Brave 的代码量很少，核心功能都集中在 brave-core 这个模块下，一个中等水平的开发人员，可以在一天之内读懂其内容，并且能对 API 的结构有非常清晰的认识。

Pinpoint 的代码封装也是非常好的，尤其是针对字节码注入的上层 API 的封装非常出色，但是这依然要求阅读人员对字节码注入多少有一些了解，虽然其用于注入代码的核心 API 并不多，但要想了解透彻，恐怕还得深入 Agent 的相关代码，比如很难一目了然的理解 addInterceptor 和 addScopedInterceptor 的区别，而这两个方法就是位于 Agent 的有关类型中。

**因为 Brave 的注入需要依赖底层框架提供相关接口，因此并不需要对框架有一个全面的了解，只需要知道能在什么地方注入，能够在注入的时候取得什么数据就可以了**。就像上面的例子，我们根本不需要知道 MySQL 的 JDBC Driver 是如何实现的也可以做到拦截 SQL 的能力。

但是 Pinpoint 就不然，因为 Pinpoint 几乎可以在任何地方注入任何代码，这需要开发人员对所需注入的库的代码实现有非常深入的了解，通过查看其 MySQL 和 Http Client 插件的实现就可以洞察这一点，当然这也从另外一个层面说明 Pinpoint 的能力确实可以非常强大，而且其默认实现的很多插件已经做到了非常细粒度的拦截。

**针对底层框架没有公开 API 的时候，其实 Brave 也并不完全无计可施，我们可以采取 AOP 的方式，一样能够将相关拦截注入到指定的代码中，而且显然 AOP 的应用要比字节码注入简单很多**。

以上这些直接关系到实现一个监控的成本，在 Pinpoint 的官方技术文档中，给出了一个参考数据。**如果对一个系统集成的话，那么用于开发 Pinpoint 插件的成本是 100，将此插件集成入系统的成本是 0；但对于 Brave，插件开发的成本只有 20，而集成成本是 10**。从这一点上可以看出官方给出的成本参考数据是 5:1。

但是官方又强调了，如果有 10 个系统需要集成的话，那么总成本就是 10 \* 10 + 20 = 120，就超出了 Pinpoint 的开发成本 100，而且需要集成的服务越多，这个差距就越大。

###     ###

### **4.6.5 通用性和扩展性**       ###

很显然，这一点上 Pinpoint 完全处于劣势，从社区所开发出来的集成接口就可见一斑。

Pinpoint 的数据接口缺乏文档，而且也不太标准（参考论坛讨论帖），需要阅读很多代码才可能实现一个自己的探针（比如 Node 的或者 PHP 的）。而且团队为了性能考虑使用了 Thrift 作为数据传输协议标准，比起 HTTP 和 JSON 而言难度增加了不少。

### **4.6.6 社区支持** ###

这一点也不必多说，Zipkin 由 Twitter 开发，可以算得上是明星团队，而 Naver 的团队只是一个默默无闻的小团队（从 \#1759 的讨论中可以看出）。虽然说这个项目在短期内不太可能消失或停止更新，但毕竟不如前者用起来更加放心。

而且没有更多社区开发出来的插件，**让 Pinpoint 只依靠团队自身的力量完成诸多框架的集成实属困难，而且他们目前的工作重点依然是在提升性能和稳定性上**。

### **4.6.7 其他** ###

Pinpoint 在实现之初就考虑到了性能问题，www.naver.com 网站的后端某些服务每天要处理超过 200 亿次的请求，因此他们会选择 Thrift 的二进制变长编码格式、而且使用 UDP 作为传输链路，同时在传递常量的时候也尽量使用数据参考字典，传递一个数字而不是直接传递字符串等等。这些优化也增加了系统的复杂度：包括使用 Thrift 接口的难度、UDP 数据传输的问题、以及数据常量字典的注册问题等等。

相比之下，Zipkin 使用熟悉的 Restful 接口加 JSON，几乎没有任何学习成本和集成难度，只要知道数据传输结构，就可以轻易的为一个新的框架开发出相应的接口。

另外 **Pinpoint 缺乏针对请求的采样能力，显然在大流量的生产环境下，不太可能将所有的请求全部记录，这就要求对请求进行采样，以决定什么样的请求是我需要记录的**。Pinpoint 和 Brave 都支持采样百分比，也就是百分之多少的请求会被记录下来。但是，除此之外 **Brave 还提供了 Sampler 接口，可以自定义采样策略**，尤其是当进行 A/B 测试的时候，这样的功能就非常有意义了。

### **4.6.8 总结** ###

从短期目标来看，Pinpoint 确实具有压倒性的优势：**无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面以及几乎比较全面的 Java 框架支持**。但是长远来看，学习 Pinpoint 的开发接口，以及未来为不同的框架实现接口的成本都还是个未知数。

相反，**掌握 Brave 就相对容易，而且 Zipkin 的社区更加强大，更有可能在未来开发出更多的接口**。在最坏的情况下，我们也可以自己通过 AOP 的方式添加适合于我们自己的监控代码，而并不需要引入太多的新技术和新概念。而且在未来业务发生变化的时候，Pinpoint 官方提供的报表是否能满足要求也不好说，增加新的报表也会带来不可以预测的工作难度和工作量。

#     #

—

Tracing 和 Monitor 区别

**Monitor可分为系统监控和应用监控**。系统监控比如CPU，内存，网络，磁盘等等整体的系统负载的数据，细化可具体到各进程的相关数据。这一类信息是直接可以从系统中得到的。**应用监控需要应用提供支持，暴露了相应的数据**。

比如应用内部请求的QPS，请求处理的延时，请求处理的error数，消息队列的队列长度，崩溃情况，进程垃圾回收信息等等。**Monitor主要目标是发现异常，及时报警**。

**Tracing的基础和核心都是调用链**。相关的metric大多都是围绕调用链分析得到的。**Tracing主要目标是系统分析。提前找到问题比出现问题后再去解决更好**。

Tracing和应用级的Monitor技术栈上有很多共同点。都有数据的采集，分析，存储和展式。只是具体收集的数据维度不同，分析过程不一样。（end）

精彩文章推荐

[安装kubernetes集群-灵活安装k8s各个版本高可用集群][kubernetes_-_k8s]

[Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档][Prometheus_Grafana_Alertmanager_-]

[linux架构师成长路线图：如何从月薪3千涨到月薪3万][linux_3_3]

[基于Jenkins共享库实践之自定义通知器][Jenkins]

[Spring Cloud基础面试题大集合][Spring Cloud]

[Kubernetes将弃用Docker，不必恐慌][Kubernetes_Docker]

[手把手教你使用 Jenkins 配合 Github hook 持续集成][Jenkins _ Github hook]

[5个维度对 Kubernetes 集群优化][5_ Kubernetes]

[Docker+k8s+DevOps企业级架构师成长路线图][Docker_k8s_DevOps]

[开源API网关Kong基本介绍和安装验证  
][API_Kong_]

[Red Hat通过整合Ansible来提升Kubernetes集群管理能力][Red Hat_Ansible_Kubernetes]

[K8s自动扩缩容工具KEDA发布2.0版本，全面升级应用扩展能力][K8s_KEDA_2.0]

[2021年厮杀之年，K8s通吃跨云落地各平台，成现代化主流标准][2021_K8s]

## 技术交流 ##

为了大家更快速的学习知识，掌握技术，随时沟通交流问题，特组建了技术交流群，大家在群里可以分享自己的技术栈，抛出日常问题，群里会有很多大佬及时解答的，这样我们就会结识很多志同道合的人，长按或者扫描下图二维码可加我微信，备注运维或者k8s或者devops即可进群，让我们共同的努力，向着美好的未来出发吧~~~，**想要****免费获取****linux、k8s、DevOps、Openstack、Openshift、运维、开发、测试、架构师、Python、Go、面试文档、容器、岗位内推等资料也可进群获取****哈~~**

![format_png 16][]

**微信：** luckylucky421302

好课推荐

**《Docker+kubernetes(k8s)+DevOps+微服务企业级架构师实战培训》**

![format_png 17][]

## 微信公众号    ##

![format_png 18][]

点击阅读原文了解更多

![点击查看源网页][format_png 19]

[format_png]: /images/20221024/e5aa53d0570d420bb1f702c9c9bc2754.png
[format_png 1]: /images/20221024/78edc036f29244bfad92049385ccbe4f.png
[format_png 2]: /images/20221024/7ada7d6012e14aa6b85f6b021f7ebef5.png
[format_png 3]: /images/20221024/385cc60976c7460eb38f6fbb69902d13.png
[format_png 4]: /images/20221024/9eedbb4d84fc41ff9b50cf1ff5ecbecc.png
[format_png 5]: /images/20221024/18f7eebfecd74f228d0ddf357a434e29.png
[format_png 6]: /images/20221024/ae6f4b09fe4244a1a649fa45e4742564.png
[format_png 7]: /images/20221024/a6512d40a5e440dab61498327aca87c2.png
[format_png 8]: /images/20221024/f42a0ad4f17d41dd832292311e68b668.png
[format_png 9]: /images/20221024/27c5a0759f954c319b5811eb82da8820.png
[format_png 10]: /images/20221024/db1673f472b14e51a470b52fb1eff84e.png
[format_png 11]: /images/20221024/d6d7c9c775e949c7b61bc5404ca61eea.png
[format_png 12]: /images/20221024/c2eddc53f6354d1bae5e42d12c4f4786.png
[format_png 13]: /images/20221024/f105a0e9a36940088ac4d47600249a9a.png
[format_png 14]: /images/20221024/1e0631daf8964623a996787938fc0339.png
[format_png 15]: /images/20221024/b2c7df7e23844fd2a1f548a8216986fd.png
[kubernetes_-_k8s]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6384b8cc140dae0e6efba75100e29549cc440a010a5c7976bdd313e9c6139569b197e20a8f&idx=1&mid=2247486381&scene=21&sn=f07ae730cdc3ca2442462e0c7f2caed1#wechat_redirect
[Prometheus_Grafana_Alertmanager_-]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb638b08cc14021e5e025f2f0b89d18ec5ef19f9dec4429a56f356e8b596d01095e313dab3e3&idx=1&mid=2247484445&scene=21&sn=bf8928e7aae815b8e7f9ac56a67289ce#wechat_redirect
[linux_3_3]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639e28cc14173e61b92f64bcd416338ee89c60c2a6009cb1259a79476bc861646505c8094c&idx=1&mid=2247487805&scene=21&sn=4ff2737a8ba870626f266e9520096a55#wechat_redirect
[Jenkins]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639f82cc141694aa50a9739b93fe5041b656758179ca6123d6d01097981d810129cab7543d&idx=1&mid=2247487639&scene=21&sn=6d8ec25fe7f2d319333ec0564877e160#wechat_redirect
[Spring Cloud]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639f9bcc14168dbffbc995646942ed75995d1181296af73df1cd13b6d3f0052d42934648cc&idx=1&mid=2247487630&scene=21&sn=d4cbb1afb6d2d059c0e9d319dd47fdf0#wechat_redirect
[Kubernetes_Docker]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639f68cc14167e344cea74d031c8f466e51cb00f19d112d07aeb73fa062a7be5b473d055d7&idx=1&mid=2247487613&scene=21&sn=61308d2c58562ad51ad8c1327a2353e1#wechat_redirect
[Jenkins _ Github hook]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639f7acc14166ca2176a440bbcde9d563c78df76bff8a5a8e0cff467f23dfc9415b2c5c4ef&idx=1&mid=2247487599&scene=21&sn=8f107a8d869238058e50e8cd73175c5a#wechat_redirect
[5_ Kubernetes]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6383aecc140ab8050df002d52f6063e85ad2777f4ec0941c9d40ea49c50c11f23542f43dfc&idx=1&mid=2247486651&scene=21&sn=2fe1be9d4a335077757c46a36cb1aea2#wechat_redirect
[Docker_k8s_DevOps]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639e8dcc14179b1ddcd20f7d08d9720e7382ddf84ab627c13eac16df1b59bc7b393491906c&idx=1&mid=2247487896&scene=21&sn=e6f0424c4d86f7de4355d4790ee10d71#wechat_redirect
[API_Kong_]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639ed5cc1417c3f90de67376a354d0c7f1d918151f3bcfe301e319d79c2cfee71fec24017f&idx=1&mid=2247487936&scene=21&sn=141bcb9b8346826458f83693bc6b6bb1#wechat_redirect
[Red Hat_Ansible_Kubernetes]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639d5dcc14144b9c1ae512634b533b3c65d8eea7095494d1bdb9b078c2f0d2ebc6e58e6ac6&idx=1&mid=2247488072&scene=21&sn=702ada85b3a7a81a38e5f8e8c89cd9f5#wechat_redirect
[K8s_KEDA_2.0]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639d51cc141447eb0ded990df4abe27860fc66b782875f3e656bcdfe5a7b00b2bfb76b9d15&idx=1&mid=2247488068&scene=21&sn=f24c1e2561160fe5feb9a17c6bcc8d1c#wechat_redirect
[2021_K8s]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639d97cc14148192189d950db0377e6cc8258a84f00232de9d5c84a2b8cbb73cf64e1a53a5&idx=1&mid=2247488130&scene=21&sn=7a99ea3149fbf416fdce8912591024d8#wechat_redirect
[format_png 16]: /images/20221024/5308f3045e704a038c50450cf7ead8d0.png
[format_png 17]: /images/20221024/12bbb229149e4a18a0f9495e2c211855.png
[format_png 18]: /images/20221024/abd26542c82945b69ea5c850f802fbc8.png
[format_png 19]: /images/20221024/c80e1239068847e09aa13199ea36ac81.png