背景
随着公司业务的与日俱增,各个系统也越来越复杂,服务间的调用,服务的依赖,以及分析服务的性能问题也越棘手,因此引入服务追踪系统尤为重要
现有的服务追踪体系,基本都是参考Google的 Dapper 体系来做的。通过跟踪请求的处理过程,来对应用系统在前后端处理、服务端调用的性能消耗进行跟踪(每个请求的完整调用链路,收集调用链路上每个服务的性能数据),方便工程师能够快速定位问题
同类工具
市面上的全链路监控理论模型大多都是借鉴Google Dapper论文,本文重点关注以下四种APM组件:
-
Cat: 是基于Java开发的实时应用监控平台,为美团点评提供了全面的监控服务和决策支持
-
Zipkin:由Twitter公司开源,开放源代码分布式的跟踪系统,用于收集服务的定时数据,以解决微服务架构中的延迟问题,包括:数据的收集、存储、查找和展现
-
Pinpoint:一款对Java编写的大规模分布式系统的APM工具,由韩国人开源的分布式跟踪组件。
-
Skywalking:国产的优秀APM组件,是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。
其中,Cat和Zipkin对代码均具有侵入性:Cat需要修改代码集成API,Zipkin需要修改项目配置增加拦截器,因此排除这2款工具的选型
方案对比
Pinpoint和Skywalking均为非侵入式,因此只对Pinpoint和Skywalking进行对比
Demo地址
-
Pinpoint: http://125.209.240.10:10123/
-
Skywalking: http://122.112.182.72:8080/
Pinpoint | Skywalking | |
---|---|---|
文档 | 详细 | 详细 |
用户 | 非常多 | 非常多 |
支持语言 | Java、PHP | Java、C#、PHP、Node.js |
数据存储 | HBase | ES、MySQL |
UI丰富度 | 丰富 | 一般 |
跟踪粒度 | 细致 | 一般 |
JVM跟踪粒度 | 细致 | 一般 |
代码侵入性 | 无 | 无 |
实现方式 | 字节码注入 | 字节码注入 |
接入成本 | 低 | 低 |
可扩展性 | 低 | 高 |
由上表可以看出二者的优劣势,以下简单总结下:
-
Pinpoint
-
优势
-
大企业/长时间验证,稳定性和完成度高
-
探针收集的数据粒度比较细
-
HBase的数据密度较大,支持PB级别下的数据查询
-
代码设计考虑的扩展性较弱,二次开发难度较大(探针为插件式,开发比较简单)
-
拥有完整的APM和调用链跟踪功能
-
-
劣势
-
代码针对性强,扩展较难
-
容器为HBase,查询功能较弱(主要为时间维度)
-
探针的额外消耗较多(探针采集粒度细,大概5%~10%)
-
项目趋于成熟,而扩展难度较大,目前社区活跃度偏低,基本只进行探针的增加或者升级
-
缺少自定义指标的设计
-
-
-
Skywalking
-
优势
-
数据容器为ES,查询支持的维度较多并且扩展潜力大
-
项目设计采用微内核+插件,易读性和扩展性都比较强
-
主要的研发人员为华人并且均比较活跃,能够进行更加直接的沟通
-
拥有完整的APM和调用链跟踪功能
-
-
劣势
-
项目发展非常快,稳定性有待验证
-
ES数据密度较小,在PB级别可能会有性能压力
-
缺少自定义指标的设计
-
-
个人使用感受和优缺点对比
以下是我在使用这两款工具之后得出的感受
Pinpoint
的不足:
-
不支持异步执行的调用链追踪(比如多线程、MQ),而SW通过注解可以支持
-
功能比较少,例如缺少平均响应、平均吞吐量等数据,缺少慢服务的统计
-
调用链信息,可以扩展和丰富的程度,要低于SW(SW可以通过注解扩展)
Skywalking
的不足:
-
针对单个应用的请求热力图,只能看到请求数量,看不到响应时间分布
-
应用界面,不能直观看到时间段内的请求总数量及错误数量
-
JVM的监控信息,SW没有PP全面
-
调用链信息,SW默认只显示入口和组件(如MySQL)调用处的信息,而PP还会显示SpringBean方法的调用信息,更丰富实用,当然SW也可以开启更详细的信息,但是会显示Bean内部方法的所有调用,显得冗余(例如 A调B调C,显示B和C被调用的入口方法就可以了,不用显示B调用自己内部方法的过程)
-
SW更新快,BUG较多,值得优化和改进的地方也很多,虽然功能强,但是用起来不一定顺手和实用,还需要时间斟酌和打磨。相对而言,PP功能成熟,功能虽然少,但是都比较经典,用起来比较顺手
-
SW调用链里面DB类型只能看到SQL,看不到参数化SQL的传值,而PP可以
-
PP支持实时监控、页面实时刷新,而SW不支持
两款工具皆有优劣,需要根据具体情况权衡。