开源APM技术选型与实用“改造”

APM，全称：应用性能管理。目前市面上的系统基本都是基于Google的Dapper（大规模分布式系统的跟踪系统）。翻译门户《google 的Dapper 中文翻译》

大家想一想，不遵守这个理论的人都是伪APM、流氓吗？

APM的核心思想是什么？当应用服务节点互相调用时，会记录并传递一个应用级标签。该标签可以用来关联各个服务节点之间的关系。例如，如果使用HTTP作为两个应用服务节点之间的传输协议，这些标签将被添加到HTTP标头中。可见，如何传递这些标签与应用服务节点之间使用的通信协议有关。常用的协议添加这些内容相对容易，但一些定制的可能相对困难。这也直接决定了分布式追踪的实现。系统难度。

2、为什么要用 APM?

有业务痛点，才能寻求解决方案。个人认为APM需要优先解决测试环境中的两个场景问题，本着测试先行的原则：

优先考虑宏观数据并不意味着测试人员不需要关注微观层面的问题。从测试角度来说，首先要解决性能测试环境中的数据采样和采集问题，然后再对生产环境进行评估。在线链接监控需要研究和开发。配合运维，【研发视角场景】相比测试人员关注度较弱。

3、市面上有哪些 APM 工具？

PinpointPinpoint是一个用Java编写的用于大规模分布式系统的开源APM（应用程序性能管理）工具。https://github.com/naver/pinpointSkyWalking是一个分布式跟踪系统，APM（应用程序性能监控）。http://skywalking.orgZipkinZipkin是一个分布式追踪系统。它有助于收集解决微服务架构中的延迟问题所需的计时数据。它管理此数据的收集和查找。 Zipkin 的设计基于Google Dapper 论文。http://zipkin.io/CAT（大众点评） CAT 是基于Java 开发的实时应用监控平台，包括实时应用监控和业务监控。 https://github.com/dianping/cat

4、先说结论

目前设计符合Google Dapper的原则，Pinpoint比Zipkin更好。 Pinpoint对代码零侵入，采用JavaAgent字节码增强技术，只需添加启动参数。并且符合【测试角度场景】性能测试调优与监控的宏观视角；当然，这个结论还为时过早，难免会有质疑：

“Spring Cloud Slueth 和zipkin 是什么关系？ “

如果需要看详细对比，请看下图：

5、再说对比

本质上，Spring Cloud Slueth 无法与Pinpoint 相媲美。真正的比较是与Zipkin 的比较。 Spring Cloud Slueth专注于链接跟踪和分析，将信息发送到Zipkin，并使用Zipkin的存储来存储信息。当然，Zipkin也可以使用ELK来记录日志并显示，然后通过收集服务器性能的脚本将数据存储在ELK中，从而可以显示服务器状态信息。 Zipkin的整体展示也是基于链接分析。

篇幅二：Pinpoint 实战篇

1、Pinpoint 架构图

Pinpoint 是一个开源APM（应用程序性能管理）工具，用于用Java 编写的大规模分布式系统。

开源APM技术选型与实用“改造”

架构图对应的描述：

Pinpoint-Collector：收集各种性能数据Pinpoint-Agent：探针与应用服务器（如tomcat）关联，部署在同一台服务器上Pinpoint-Web：收集到的数据层展示在Web上HBase Storage：收集到的数据存储在HBase中的

2、Pinpoint 的数据结构

Pinpoint消息的数据结构主要包含三种类型：Span、Trace和TraceId。

Span 是最基本的呼叫跟踪单位。当远程调用到达时，Span 指的是处理调用并携带跟踪数据的作业。为了实现代码级可见性，Span还包含一层SpanEvent数据结构。每个Span包含一个SpanId。跟踪是一组相互关联的跨度。同一trace下的span共享一个TransactionId，会根据SpanId和ParentSpanId排列成层次树结构。 TraceId 是TransactionId、SpanId 和ParentSpanId 的组合。 TransactionId（TxId）是一个事务下整个分布式系统发送和接收的消息的ID，在整个服务器组中必须是全局唯一的。也就是说TransactionId标识了整个调用链； SpanId（SpanId）是远程调用作业的ID，调用到达节点时生成； ParentSpanId（pSpanId），顾名思义，就是生成当前Span的调用者Span的ID。如果某个节点是事务的原始发起者，则其ParentSpanId 为-1，表示它是整个事务的根跨度。下图可以直观的说明这些ID结构之间的关系。

3、Pinpoint 部署

网上的部署文档太多。我不会在这里详细解释它们。这里有一个简单的解释：

注意版本要求：

有两种方法可以开始：

方法一：修改tomat目录下的bin/catalina.sh，在CATALINA Server的Control Script中添加以下三行代码：

方法二：SpringBoot启动

Pinpoint对代码注入的封装与AOP非常相似。当一个类被加载时，前后逻辑会通过Interceptor注入到指定的方法中。在这些逻辑中，可以获取系统的运行状态，并通过TraceContext创建Trace消息，并发送给Pinpoint服务器。但与AOP不同的是，Pinpoint在封装时考虑到了更多与目标代码的交互能力，因此使用Pinpoint提供的API编写代码会比AOP更容易、更专业。

5、Pinpoint 实战效果演示

搭建一个java开源项目jforum，在tomcat下运行，使用jmeter进行压力测试，100个用户：

服务器映射(ServerMap) 通过可视化分布式系统组件的互连方式来了解任何分布式系统的拓扑。单击节点将显示有关该组件的详细信息，例如其当前状态和事务计数。实时活动线程图表实时监控应用程序内的活动线程。（使用官方图像，当时没有屏幕截图）请求/响应散点图可视化请求计数和响应模式以识别潜在问题。可以通过拖动图表来选择交易以获取更多详细信息。 CallStack 信息(CallStack) 增强了分布式环境中每个事务的代码级可见性，在单个视图中识别瓶颈和故障点。检查器查看应用程序的其他详细信息，例如CPU 使用情况、内存/垃圾收集、TPS 和JVM 参数。

开源APM技术选型与实用“改造”

6、总结

第一：PinPoint从宏观角度看：整体链路、服务整体状态（cpu、内存等信息），符合【测试角度场景】性能测试调优和监控宏观；第二：Spring Cloud Slueth需要结合从微观角度来看，Zipkin无法单独提供显示。需要结合Zipkin来显示链接问题（没有服务器整体状态的显示）。要展示服务器性能状态等更多信息，必须通过ELK采集定制脚本并展示，这符合【研发视角场景】性能测试、调优、监控的微观层面；

一般来说，两者是结合的。如果单独使用，从测试业务的角度来看：PinPoint满足性能测试、调优和监控的宏观【测试视角场景】。