一、技术调研
Zipkin是Twitter开源的调用链分析工具、目前基于SpringCloud Sleuth得到了广泛的使用、特点是轻量、使用部署简单
Pinpoint是韩国人开源的基于字节码注入的调用链分析、以及应用监控分析工具、特点是支持多种插件、UI功能强大、接入端无代码侵入
SkyWalking是本土开源的基于字节码注入的调用链分析、以及应用监控分析工具、目前已Apache孵化器毕业、特点是支持多种插件、UI功能强大、接入端无代码侵入、提供应用Agent交互包、
CAT是大众点评开源的基于编码和配置的调用链分析、应用监控分析、日志采集、监控报警等一系列的监控平台工具
Pradar是数列公司的一个产品、并非开源项目、Pradar和Pinpoint一样也是基于字节码注入的调用链分析、Agent部分的代码也十分相似、
类别ZipkinPinpointSkyWalkingCATPradar
实现方式拦截请求字节码增强字节码增强代码埋点字节码增强
接入方式基于linkerd或者sleuth方式配置javaagentjavaagent代码入侵javaagent
OpenTracing√×√××
存储ES、Mysql、Cassandra、MemoryHbaseES、JDBCMySQL、HDFSHbase、HDFS
收集协议HTTP、MQThrift、gRPCHTTP、gRPCHTTP/TCPHTTP(代理)
类别ZipkinPinpointSkyWalkingCATPradar
颗粒度接口级方法级方法级(代码级)代码级方法级
全局调用统计×√√√√
TraceId查询√×√×√
报警×√√√×
JVM监控××√√×
UI*******************
zipkin分为zipkin服务端和客户端、每一个被监控的服务都是客户端
追踪器：位于客户端、并记录有关发生的操作的时间和元数据、对用户透明
Reporter： 将数据发送到Zipkin的检测应用程序
Transport ：传输数据：HTTP、 Kafka and Scribe
Collector：位于服务端中、收集传输来的数据
Storage ：存储数据、默认存储在内存中
search ：查询Api、JSON应用编程接口、被UI调用
UI ：Web UI提供了一种基于服务、时间Annotation查看跟踪的方法、没有内置身份验证
Pinpoint 完整组件分为五部分: 探针、收集器、流计算、存储和用户界面
Pinpoint-Collector：收集各种性能数据
Pinpoint-Agent：探针与应用关联、部署到同一台服务器上
Pinpoint-Web：将收集到的数据层现在web展示
Pinpoint-Flink: 将收集到的数据进行聚合等运算得出指标
HBase Storage：收集到数据存到HBase中
SkyWalking 逻辑上分为四部分: 探针(SkyWalking-agent)、平台后端(oap-server)、存储(es)和用户界面(apm-webapp)
探针基于不同的来源可能是不一样的（原生代理, SDK 以及 Zipkin, Jaeger 和 OpenCensus ）、但作用都是收集数据、将数据格式化为 SkyWalking 适用的格式
平台后端是一个支持集群模式运行的后台、用于数据聚合、数据分析以及驱动数据流从探针到用户界面的流程、平台后端还提供了各种可插拔的能力、如不同来源数据(如来自 Zipkin)格式化、不同存储系统以及集群管理、你甚至还可以使用观测分析语言来进行自定义聚合分析
存储是开放式的、你可以选择一个既有的存储系统、如 ElasticSearch, H2 或 MySQL 集群(Sharding-Sphere 管理)、也可以选择自己实现一个存储系统、
用户界面对于 SkyWalking 的最终用户来说非常炫酷且强大、同样它也是可定制以匹配你已存在的后端的
整个CAT主要分为三个模块、cat-client、cat-consumer、cat-home
cat-client 提供给业务以及中间层埋点的底层sdk
cat-consumer 用于实时分析从客户端的提供的数据
cat-home 作为用户提供给用户的展示的控制端
上图是CAT目前多机房的整体结构图：
路由中心是根据应用所在机房信息来决定客户端上报的CAT服务端地址
每个机房内部都有的独立的原始信息存储集群HDFS
cat-home可以部署在一个机房也可以部署在多个机房、在做报表展示的时候、cat-home会从cat-consumer中进行跨机房的调用、将所有的数据合并展示给用户
实际过程中、cat-consumer、cat-home以及路由中心都是部署在一起、每个服务端节点都可以充当任何一个角色
Pradar 整体分为四部分: 探针、log-agent服务、流计算、存储和用户界面
Pradar-Agent：收集各种性能数据
Log-Agent：探针与应用关联、部署到同一台服务器上
Pradar-Strom：将收集到的数据层现在web展示
Pinpoint-Flink: 将收集到的数据进行聚合等运算得出指标
HBase-Storage：收集到数据存到HBase中
类别ZipkinPinpointSkyWalkingCATPradar
Star当前数量114169099948710645-
Issues数量235985122-
代码最后变更2天前2天前21小时前13天前-
数据统计日期：2019年8月4日
公司目前已经有过百系统、并且技术栈相对混乱、经过对以上几种类型APM的剖析、只有使用javaagent类型的接入方式、才能减少冲击、降低成本、考虑pradar有些陈旧、并且很多功能也是存在不少的问题、例如对容器不友好等等情况、本章节将对Pinpoit与SkyWalking进行一次深度对比、
类别PinpointSkyWalking
项目发起人Woonduk Kang（韩国）吴晟（中国）
Github Star90999487
社区非Apache/一般社区Apache项目 + QQ官方群交流
文档详细详细
用户非常多非常多
OpenTracing兼容否是
支持语言Java、PHPJava、PHP、C#、Node.js、Go
协议Thrift、gRPCgRPC
存储Hbase + MySQLES、TiDB、JDBC
UI丰富度一般很高
实现方式字节码注入字节码注入
代码入侵性无无（代码入侵可拥有更多功能）
扩展性低高
TraceId查询不支持支持
告警支持支持
JVM监控支持支持
跟踪粒度细一般
过滤追踪filter配置Optional Plguin支持
性能损耗高低
组件Agent + Collector + Flink + Web + 存储Agent + OAP + Web + 存储 + ZK
发布包WarJar
二者的展示环境：Pinpoint Live Demo SkyWalking Live Demo
Pinpoint只支持Java和PHP、而SkyWalking支持5种语言：Java, C#, PHP, Node.js, Go、如果公司的服务涉及到多个开发语言、那么SkyWalking会是你更好的选择、并且如果要实现自己的探针、SkyWalking的二次开发成本也比Pinpoint更低、所以，支持语言方面，SkyWalking更胜一筹。
SkyWalking支持gRPC和HTTP、不过建议使用gRPC、SkyWalking6.x版本已经不提供HTTP方式（但是还会保留接收5.x的数据）、以后会考虑删除、而Pinpoint使用的是thrift协议、协议本身没有谁好谁坏、
存储是SkyWalking和Pinpoint最大的差异所在、因为底层存储决定了上层功能、Pinpoint只支持HBase、且扩展代价较大、
如果选择Pinpoint、还要有能力hold住一套HBase集群（DaoCloud从Pinpoint切换到SkyWalking就是因为HBase的维护代价有点大）、在这方面、SkyWalking支持的存储就多很多、这样的话、技术选型时可以根据团队技术特点选择合适的存储、而且还可以自行扩展（不过生产环境上应该大部分是以es存储为主）
Pinpoint只支持HBase的另一个缺陷就是、HBase本身查询能力有限（HBase只能支持三种方式查询：RowKey精确查找、SCAN范围查找、全表扫描）限制了Pinpoint的查询能力、所以其支持的查询一定是在时间的基础上（Pinpoint通过鼠标圈定一个时间范围后查看这个范围内的Trace信息）、而SkyWalking可以多个维度任意组合查询、例如：时间范围、服务名、Trace状态、请求路径、TraceId等
Pinpoint和SkyWalking都支持TTL、即历史数据保留策略、SkyWalking是在OAP模块的application.yml中配置从而指定保留时间、而Pinpoint是通过HBase的ttl功能实现、通过Pinpoint提供的HBase脚本
ES并不是完全碾压HBase、ES和HBase没有绝对的好和坏、ES强在检索能力、存储能力偏弱、HBase强在存储能力、检索能力偏弱、如果搜集的日志量非常庞大、那么es存储就比较吃力、同样的、如果对检索能力有一定的要求、那么HBase肯定满足不了你、所以又到了根据你的业务和需求决定的时刻了、trade-off真是无所不在
Pinpoint的UI早期确实要比SkyWalking强上不少、尤其是服务的拓扑图展示、不过DaoCloud根据Pinpoint的风格为SkyWalking定制了一款UI(Rocketbot)、随着社区的发展已经贡献给SkyWalking成为官方UI了、所以用5.x版本的SkyWalking比较、Pinpoint UI更胜一筹、6.x版本SkyWalking UI更胜一筹
Pinpoint好像设计之初就没有过多考虑扩展性、无论是底层的存储、还是自定义探针实现等、而SkyWalking核心设计目标之一就是Pluggable、
以存储为例、Pinpoint完全没有考虑扩展性、而SkyWalking从设计理念上就是SPI模式、实现一些接口配置就可以完成存储扩展、至于Pinpoint则完全没有考虑过扩展底层存储、
再以实现一个自己的探针为例、Pinpoint 在实现之初就考虑到了性能问题、因此会选择 Thrift 的二进制变长编码格式、而且使用 UDP 作为传输链路、同时在传递常量的时候也尽量使用数据参考字典、这些优化也增加了系统的复杂度：包括使用 Thrift 接口的难度、UDP 数据传输的问题、以及数据常量字典的注册问题等等、Pinpoint发展这么年才支持Java和PHP、可见一斑、目前Pinpoint最新代码也在使用gRPC、而SkyWalking的数据接口就标准很多、并且支持OpenTracing协议、除了官方支持Java以外、C#、PHP、Go和Node.js的支持都是由社区开发并维护、
还有后面会提到的告警、SkyWalking的可扩展性也要远好于Pinpoint、
Pinpoint和SkyWalking都支持自定义告警规则、但是Pinpoint如果要配置告警规则、还需要安装MySQL(配置告警时的用户、用户组信息以及告警规则都持久化保存在MySQL中)、这就导致Pinpoint的维护成本又高了一些、既要维护HBase又要维护MySQL、
Pinpoint支持的告警规则有：SLOW COUNT|RATE, ERROR COUNT|RATE, TOTAL COUNT, SLOW COUNT|RATE TO CALLEE, ERROR COUNT|RATE TO CALLEE, ERROR RATE TO CALLEE, HEAP USAGE RATE, JVM CPU USAGE RATE, DATASOURCE CONNECTION USAGE RATE
Pinpoint每3分钟周期性检查过去5分钟的数据、如果有符合规则的告警、就会发送sms/email给用户组下的所有用户、需要说明的是、实现发送sms/email的逻辑需要自己实现、Pinpoint只提供了接口com.navercorp.pinpoint.web.alarm.AlarmMessageSender、并且Pinpoint发现告警持续时、会递增发送sms/email的时间间隔 3min -> 6min -> 12min -> 24min、防止sms/email狂刷
SkyWalking支持的告警规则有：service_resp_time, service_sla, service_cpm, service_p99, service_p95, service_p90, service_p75, service_p50, service_instance_sla, service_instance_resp_time, service_instance_cpm, endpoint_cpm, endpoint_avg, endpoint_sla, endpoint_p99, endpoint_p95, endpoint_p90, endpoint_p75, endpoint_p50。
SkyWalking通过HttpClient的方式远程调用在配置项webhooks中定义的告警通知服务地址、SkyWalking也支持silence-period配置、假设在TN这个时间点触发了告警、那么TN -> TN + period 这段时间内不会再重复发送该告警
Pinpoint和SkyWalking都支持常用的告警规则配置、SkyWalking采用webhooks的方式就灵活很多、但是需要自己开发webhooks接口、短信通知、邮件通知、微信通知都是可以支持的、而Pinpoint虽然免去了开发接口的工作量、但是只能sms/email通知、并且还需要引入MySQL存储、增加了整个系统复杂度、所以、告警方面、SkyWalking更胜一筹
Pinpoint能够监控的指标主要有：Heap、 Non-Heap、 FGC、 DirectBufferMemory、MappedBufferMemory、但是没有YGC
SkyWalking支持监控：Heap、Non-Heap、YGC、FGC
另外、Pinpoint还支持多个指标同一时间点查看的功能、所以、对JVM的监控方面、Pinpoint更胜一筹
包括操作系统和部署的服务实例的监控、
Pinpoint支持的维度有：CPU使用率、Open File Descriptor、数据源、活动线程数、RT、TPS、
SkyWalking支持的维度有：CPU使用率、SLA、RT、CPM（Call Per Minutes）。
所以、这方面两者旗鼓相当、没有明显的差距
Pinpoint在这方面做的非常好、跟踪粒度非常细、在跟踪粒度方面、Pinpoint完胜、
Pinpoint和SkyWalking都可以实现、而且配置的表达式都是基于ant风格、Pinpoint在Web UI上配置 filter wizard 即可自定义过滤追踪、SkyWalking通过加载apm-trace-ignore-plugin插件就能自定义过滤跟踪、两种配置方式各有优势、所以、这方面两者旗鼓相当、没有明显的差距
由于Pinpoint采集信息太过详细、所以、它对性能的损耗很大、而SkyWalking默认策略比较保守、对性能损耗较小、所以、在性能损耗方面、SkyWalking更胜一筹、有网友做过压力测试，对比如下：
SkyWalking与时俱进、全系标配jar包、部署只需要执行start.sh脚本即可、而Pinpoint的collector和web还是war包、部署时依赖web容器、所以、在发布包方面、SkyWalking更胜一筹、
Pinpoint支持组件 SkyWalking支持组件、这个毫无疑问也是Pinpoint更胜一筹、
经过前面对SkyWalking和Pinpoint全方位对比后我们发现、对于两款非常优秀的APM软件、有一种既生瑜何生亮的感觉、
Pinpoint的优势在于：追踪数据粒度非常细、功能强大的用户界面、以及使用HBase作为存储带来的海量存储能力、
SkyWalking的优势在于：非常活跃的中文社区、支持多种语言的探针、使用es作为底层存储带来的强大的检索能力、并且SkyWalking的扩展性以及定制化要更优于Pinpoint、
如果有海量的日志存储需求、推荐Pinpoint、如果更看重二次开发的便捷性、推荐SkyWalking、参考上面的对比、结合需求、哪些不能妥协、哪些可以舍弃、从而更好的选择一款最适合自己的APM软件
参考资料：
调用链选型之Zipkin，Pinpoint，SkyWalking，CAT
