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

引言:最近在调研与选型分布式调用链监控组件。选了主要的三种APM组件进行了实践与比较。本来打算一篇文章写完的,篇幅太长,打算分两篇。距离《几种分布式调用链监控组件的实践与比较(一)实践》已经有近一个月时间了,主要最近工作比较忙,更新很慢。本文将会讲下几种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. 阿里微服务之殇及分布式链路追踪技术原理

原文发布于微信公众号 - aoho求索(aohoBlog)

原文发表时间:2017-12-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ThoughtWorks

组件测试:改建遗留系统的起点 | 洞见

在遗留系统中工作,无论是开发新功能,还是对旧功能进行修改,抑或是通过重构以期重拾其往日的雄风,都会面临大量的挑战。这些挑战主要来自于流失的业务知识、失传的技术和...

1413
来自专栏JAVA高级架构

多研究些架构,少谈些框架(3)-- 微服务和事件驱动

接上篇,我们采用了领域驱动的开发方式,使用了充血模型,享受了他的好处,但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。 事务一致性 事务...

3974
来自专栏纯洁的微笑

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

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

2892
来自专栏社区的朋友们

浅聊 API 网关

在微服务概念流行之前,API 网关的就已经诞生了,如银行、证劵等领域常见的前置机系统,解决访问认证、报文转换、访问统计等;而我今天的切入点是从 API-cent...

1.6K2
来自专栏EAWorld

微服务的持续集成,四步“构建”一个代码世界

大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天...

3355
来自专栏大数据文摘

首席工程师揭秘:LinkedIn大数据后台是如何运作的

2675
来自专栏EAWorld

DevOps平台中的自动化部署框架设计

本文目录: 一、背景 二、我们的需求是什么? 三、概念澄清 四、概念模型 五、总体设计 六、关键点设计 七、总结 一、背景 说到自动化部署,大家肯定都会想到一些...

6184
来自专栏JAVA高级架构

高并发、高性能 Web 架构

2812
来自专栏java一日一条

浅析数据一致性

在数据有多分副本的情况下,如果网络、服务器或者软件出现故障,会导致部分副本写入成功,部分副本写入失败。这就造成各个副本之间的数据不一致,数据内容冲突。 实践中,...

5731
来自专栏美团技术团队

【沙龙干货】RDS平台介绍

今天我就给大家讲一下我们这边做的数据库运维的自动化平台,他是怎么样子的。首先我会给大家简单介绍一下我们做平台的背景,以及平台的一些技术架构,以及针对我们DBA和...

5484

扫码关注云+社区

领取腾讯云代金券