几种分布式调用链监控组件的实践与比较（二）比较

https://blog.csdn.net/ityouknow/article/details/82393102

引言：继上篇《几种分布式调用链监控组件的实践与比较（一）实践》后，本篇将会讲下几种APM选型的比较与性能测试。

1. 前文回顾

上一篇文章主要讲了三种分布式调用链监控组件的实践。问题的背景由微服务架构展开，微服务的好处已经不用多说，而微服务的多了之后，千头万绪，下面这张图经常被用到。

系统的复杂度因此提升。系统越复杂，越难解决问题，例如系统失败或者性能问题。在三层架构中找到解决方案还不是太难，仅仅需要分析3个组件比如web服务器，应用服务器和数据库，而服务器数量也不多。但是，如果问题发生在n层架构中，就需要调查大量的组件和服务器。另一个问题是仅仅分析单个组件很难看到大局;当发生一个低可见度的问题时，系统复杂度越高，就需要更长的时间来查找原因。最糟糕的是，某些情况下我们甚至可能无法查找出来。

上面其实已经提到存在的故障定位问题，基于微服务体系之下构建的业务系统存在的问题基本上分为三类：

• 故障定位难，一个简单操作，其背后可能是由十几个微服务共同完成的，这些微服务也由不同的团队去负责。一旦出现问题，最坏情况下我们也许需要这十几个团队一起来解决问题。

• 链路梳理难，应用没有形成应用拓扑，不知道自己的服务下游会影响其他哪些人。

• 资源浪费多，容量预估难。对于一些服务，其消耗的cpm和memory可能连10%不到，远远没有充分利用物理机。这其实和容量预估关联，过大或者过小估算峰值的机器容量，都是浪费。

APM主要的目的就是解决上面所说的这四个问题，主要的手段是通过收集、存储、分析、分布式系统中的调用事件数据，协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。第一篇其实已经讲过链路监控组件的需求：

• 代码的侵入性

• 探针的性能消耗

• 全面的调用链路数据分析

• 可扩展性

这边列一下pinpoint在其wiki中提到的几点：

• 分布式事务跟踪，跟踪跨分布式应用的消息

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

• 水平扩展以便支持大规模服务器集群

• 提供代码级别的可见性以便轻松定位失败点和瓶颈

• 使用字节码增强技术，添加新功能而无需修改代码

下面我们沿着这些需求，看一下这几种分布式调用链监控组件。

2. AMP比较

上面列了需求，但是不够通用，笔者将需要对比的项提炼出来：

1. 探针的性能 
   主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。

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

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

4. 对于开发透明，容易开关 
   添加新功能而无需修改代码，容易启用或者禁用。

5. 完整的调用链应用拓扑 
   自动检测应用拓扑，帮助你搞清楚应用的架构

笔者根据主要的需求，提炼出如上五点。

2.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种。下面看下汇总表。

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

2.2 collector的可扩展性

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

• zipkin 
  在前一篇文章中，我们开发了zipkin-Server（其实就是提供的开箱即用包），zipkin-agent与zipkin-Server通过http或者mq进行通信，http通信会对正常的访问造成影响，所以还是推荐基于mq异步方式通信，zipkin-Server通过订阅具体的topic进行消费。这个当然是可以扩展的，多个zipkin-Server实例进行异步消费mq中的监控信息。

• skywalking 
  skywalking的collector支持两种部署方式：单机和集群模式。collector与agent之间的通信使用了gRPC。

• pinpoint 
  同样，pinpoint也是支持集群和单机部署的。pinpoint agent通过thrift通信框架，发送链路信息到collector。

2.3 全面的调用链路数据分析

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

• zipkin

zipkin的链路监控粒度相对没有那么细，从上图可以看到调用链中具体到接口级别，再进一步的调用信息并未涉及。

• skywalking

skywalking 还支持20+的中间件、框架、类库，比如主流的dubbo、Okhttp，还有DB和消息中间件。上图skywalking链路调用分析截取的比较简单，网关调用user服务，由于支持众多的中间件，所以skywalking链路调用分析比zipkin完备些。

• pinpoint

pinpoint应该是这三种APM组件中，数据分析最为完备的组件。提供代码级别的可见性以便轻松定位失败点和瓶颈，上图可以看到对于执行的sql语句，都进行了记录。还可以配置报警规则等，设置每个应用对应的负责人，根据配置的规则报警，支持的中间件和框架也比较完备。

2.4 对于开发透明，容易开关

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

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

2.5 完整的调用链应用拓扑

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

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

3. 总结

本文讲了三种分布式调用链监控组件的比较，主要从五方面着手，笔者对每一项都进了对比。至于具体选用哪款组件，大家可以根据实际的业务需求和场景进行选型，上面比较的数据仅供参考。这三款都是开源项目，一般公司都对针对实际情况进行一些二次开发，比如增加一些组件的支持、对接现存的大数据平台等等。

最后，看了eagleEye的相关介绍，想提下监控系统如何从被动报警转化为主动发现，其实和AIOps很密切。链路监控数据量很大，尽管可以通过压缩比来降低传输的数据量，但是我们真的需要存储每一条链路吗？是不是只需要识别每一个链路当中出现异常的情况。时序指标当中的异常点，那个时间点我们要识别出来。识别完了之后，对异常进行关联，定位出最后的问题。当然这个涉及到业务和应用系统层面，很复杂，但笔者认为是后面AIOps的大趋势。

参考：

1. Technical Overview Of Pinpoint

2. 阿里微服务之殇及分布式链路追踪技术原理