logo头像

Aoho's Blog

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

本文于374天之前发表,文中内容可能已经过时。

引言:最近在调研与选型分布式调用链监控组件。选了主要的三种APM组件进行了实践与比较。本来打算一篇文章写完的,篇幅太长,打算分两篇。距离第一篇已经有近一个月时间了,主要最近工作比较忙,更新很慢。本文将会讲下几种APM选型的比较与性能测试。

1. 前文回顾

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

mcd

系统的复杂度因此提升。系统越复杂,越难解决问题,例如系统失败或者性能问题。在三层架构中找到解决方案还不是太难,仅仅需要分析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种。下面看下汇总表。

ac

从上表可以看出,在三种链路监控组件中,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中的监控信息。

zk

  • skywalking
    skywalking的collector支持两种部署方式:单机和集群模式。collector与agent之间的通信使用了gRPC。
  • pinpoint
    同样,pinpoint也是支持集群和单机部署的。pinpoint agent通过thrift通信框架,发送链路信息到collector。

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

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

  • zipkin

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

  • skywalking

swinfo

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

  • pinpoint

ppinfo

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

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

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

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

2.5 完整的调用链应用拓扑

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

ppreal

skyreal

zipkinreal

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

3. 总结

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

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

推荐阅读

几种分布式调用链监控组件的实践与比较(一)实践


参考

  1. Technical Overview Of Pinpoint
  2. 阿里微服务之殇及分布式链路追踪技术原理
微信打赏

赞赏是不耍流氓的鼓励

评论系统未开启,无法评论!