APM简介
APM全称Application Performance Management ，目前市面的系统基本都是参考Google的Dapper（大规模分布式系统的跟踪系统）来做的, 核心思想是在服务各节点彼此调用的时候，记录并传递一个应用级别的标记，这个标记可以用来关联各个服务节点之间的关系，最终形成一个分布式跟踪的服务调用链。
APM 要解决的问题
微服务架构下，服务按照不同的维度进行拆分，一次请求请求往往需要涉及到多个服务。尤其是大规模互联网应用，服务由不同的团队开发，用不同编程语言来实现、并部署在成千上万态几千台服务器上面。我们需要可以帮助我们理解系统行为和进行分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。
市面上的APM工具
Zipkin
由Twitter公司开源，开放源代码分布式的跟踪系统
Pinpoint
Pinpoint是一款对Java编写的大规模分布式系统的APM工具，由韩国人开源的分布式跟踪系统
Skywalking
国产的优秀APM组件，是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。
其他类似的组件还有美团点评的CAT，淘宝的鹰眼EgleEye。
APM链路监控组件的要求
探针的性能消耗
APM组件服务的影响对被监控的应用应该做到足够小。
代码的侵入性
监控工具对程序员来说最好是透明的， 有侵入性对程序员来说是非常不友好的，程序员需要额外理解监控组件，以及要放入的位置，如果忽略了就监控不到，而且可能还容易引起bug
可扩展性
能够支持的组件越多当然越好，或者能提供插件开发的API，对于一些没有北监控到的组件，应用开发者也可以自行扩展
数据的分析
数据的分析要快 ，分析的维度尽可能多，实时性要求很高，这样才能在生产环境下的异常状况做出快速反应，分析并解决问题
Zipkin 与Pinpoint
Zipkin
zipkin主要涉及几个组件：collector收集agent的数据，storage存储，web UI图形化界面，search查询Storage中存储的数据, 提供简单的JSON API获取数据。
Spring cloud 提供了 sleuth 方便集成到zipkin，在Spring cloud 的帮助下我们很快就可以搭建出zipkin的server 和client，
PinPonit
Pinpoint 主要由 3 个组件外加 Hbase 数据库构成，三个组件分别为：Agent、Collector 和 Web UI
PinPoint 与ZipKin比较
探针的性能
主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。
collector的可扩展性
能够水平扩展以便支持大规模服务器集群。
全面的调用链路数据分析
提供代码级别的可见性以便轻松定位失败点和瓶颈。
对于开发透明，容易开关
添加新功能而无需修改代码，容易启用或者禁用。
完整的调用链应用拓扑
自动检测应用拓扑，帮助你搞清楚应用的架构
探针的性能
网上有大神对skywalking、zipkin、pinpoint进行了压测，并与基线（未使用探针）的情况进行了对比。
大神模拟了三种并发用户：500，750，1000。使用jmeter测试，每个线程发送30个请求，设置思考时间为10ms，采样率为100%
在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，大牛是在内部服务器进行的压测，对CPU和memory的影响都差不多在10%之内。
collector的可扩展性
zipkin
zipkin-agent与zipkin-Server通过http或者mq进行通信，通过基于mq异步方式通信，zipkin-Server通过订阅具体的topic进行消费。多个zipkin-Server实例进行异步消费mq中的监控信息。
PinPoint
pinpoint也是支持集群和单机部署,pinpoint agent通过thrift通信框架，发送链路信息到collector
全面的调用链路数据分析
zipkin
zipkin的链路监控粒度相对没有那么细，下图可以看到调用链中具体到接口级别，再进一步的调用信息不能看到
pinpoin
pinpoint数据分析相对完毕。提供代码级别的可见性以便轻松定位失败点和瓶颈，下图可以看到对于执行的sql语句，都进行了记录
对于开发透明，容易开关
Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能，但是它要求在需要时修改代码
pinpoint是基于字节码增强的方式，开发人员不需要修改代码，并且可以收集到更多精确的数据因为有字节码中的更多信息
完整的调用链应用拓扑
PinPoint的界面更加丰富，在这方面可以秒掉zipkin
其它方面
Pinpoint 是一个完整的性能监控解决方案：有从探针、收集器、存储到 Web 界面等全套体系；而 Zipkin 只侧重收集器和存储服务，虽然也有用户界面，但其功能与 Pinpoint 不可同日而语。反而 Zipkin 提供有 Query 接口，更强大的用户界面和系统集成能力，可以基于该接口二次开发实现。
Zipkin 官方提供有基于 Finagle 框架（Scala 语言）的接口，而其他框架的接口由社区贡献，目前可以支持 Java、Scala、Node、Go、Python、Ruby 和 C# 等主流开发语言和框架；但是 Pinpoint 目前只有官方提供的 Java Agent 探针。
Pinpoint 提供有 Java Agent 探针，通过字节码注入的方式实现调用拦截和数据收集，可以做到真正的代码无侵入，只需要在启动服务器的时候添加一些参数，就可以完成探针的部署；而 Zipkin 的 Java 接口实现 Brave，只提供了基本的操作 API，如果需要与框架或者项目集成的话，就需要手动添加配置文件或增加代码。
总结
对于我们来说Pinpoint 确实具有压倒性的优势；无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面以及几乎比较全面的 Java 框架支持；关于由于PinPoint采用的是字节码注入的方式导致接口开发困难度提高一个数量级，对于我们2B服务的互联网产品来说或许不是一个大问题，我们可以等一等，站在巨人的肩膀上，采取拿来主义的原则，而不是去自己实现一些接口，因为我们并不是走在互联网的前沿，所以很多问题走在前沿的开发人员会帮助我们解决，他们对于我们来说就是巨人。
Pinpoint实战演示效果
搭建一个java开源项目jforum，跑在tomcat下，使用jmeter进行压测，用户100个
服务器图（ServerMap）
通过可视化其组件的互连方式来了解任何分布式系统的拓扑。单击节点将显示有关组件的详细信息，例如其当前状态和事务计数。
实时活动线程图（Realtime Active Thread Chart）
实时监视应用程序内的活动线程。
请求/响应散布图（Request/Response Scatter Chart）
可视化请求计数和响应模式，以确定潜在问题。可以通过在图表上拖动来选择事务以获取更多详细信息
调用栈信息（CallStack)
增强分布式环境中每个事务的代码级可见性，识别单个视图中的瓶颈和故障点。
检查器（Inspector）
查看应用程序的其他详细信息，如CPU使用率，内存/垃圾收集，TPS和JVM参数
Zipkin实战演示效果
调用栈信息（CallStack)
服务器图（ServerMap）
参考+引用+抄袭的文章
https://www.cnblogs.com/Bug-Hunter/p/8677435.html
http://www.herohuang.com/2017/03/01/apm-pinpoint/
https://sq.163yun.com/blog/article/168169689970475008
http://www.tangrui.net/2016/pinpoint-plugin-development.html
http://iamlile.github.io/2017/10/06/apm/
http://www.tangrui.net/2016/zipkin-vs-pinpoint.html
https://juejin.im/post/5a0579e6f265da4326524f0f
https://juejin.im/post/5a274614518825592c07f8b8
