APM，全称：ApplicationPerformanceManagement，目前市面的系统基本都是参考Google的Dapper（大规模分布式系统的跟踪系统）来做的，翻译传送门《google的Dapper中文翻译》
思考下：不遵守该理论的是伪APM，耍流氓吗？
APM的核心思想是什么？在应用服务各节点相互调用的时候，从中记录并传递一个应用级别的标记，这个标记可以用来关联各个服务节点之间的关系。比如两个应用服务节点之间使用HTTP作为传输协议的话，那么这些标记就会被加入到HTTP头中。可见如何传递这些标记是与应用服务节点之间使用的通讯协议有关的，常用的协议就相对容易加入这些内容，一些按需定制的可能就相对困难些，这一点也直接决定了实现分布式追踪系统的难度。
2、为什么要用APM?有业务痛点，才要寻求解决方案，个人认为，APM需要优先解决测试环境下两个场景问题，基于测试先行的原则考虑：
优先关注宏观数据，并不是说测试人员无须关注微观层面的问题，在测试角度来看，先解决性能测试环境的数据采样、收集问题，再去评估生产环境，而线上的链路监控需要研发跟运维去配合，【研发角度场景】相对于测试人员来说是弱关注了。
3、市面上有哪些APM工具？PinpointPinpointisanopensourceAPM(ApplicationPerformanceManagement)toolforlarge-scaledistributedsystemswritteninJava.https://github.com/naver/pinpointSkyWalkingAdistributedtracingsystem,andAPM(ApplicationPerformanceMonitoring).http://skywalking.orgZipkinZipkinisadistributedtracingsystem.Ithelpsgathertimingdataneededtotroubleshootlatencyproblemsinmicroservicearchitectures.Itmanagesboththecollectionandlookupofthisdata.Zipkin’sdesignisbasedontheGoogleDapperpaper.http://zipkin.io/CAT（大众点评）CAT基于Java开发的实时应用监控平台，包括实时应用监控，业务监控。https://github.com/dianping/cat4、先说结论目前比较贴合GoogleDapper原理设计的，Pinpoint优于Zipkin。Pinpoint对代码的零侵入，运用JavaAgent字节码增强技术，添加启动参数即可。并且符合【测试角度场景】性能测试调优监控的宏观；当然，结论太早了，会有疑惑：
“SpringCloudSlueth和zipkin之间的关系是什么？“
需要看详细对比的，详见下图：
5、再说对比本质上SpringCloudSlueth与Pinpoint没有可比性，真正对比的是Zipkin，SpringCloudSlueth聚焦在链路追踪和分析，将信息发送到Zipkin，利用Zipkin的存储来存储信息，当然，Zipkin也可以使用ELK来记录日志和展示，再通过收集服务器性能的脚本把数据存储到ELK，则可以展示服务器状况信息了。Zipkin的总体展示，也是基于链路分析为主。
篇幅二：Pinpoint实战篇1、Pinpoint架构图PinpointisanopensourceAPM(ApplicationPerformanceManagement)toolforlarge-scaledistributedsystemswritteninJava.
架构图对应说明：
Pinpoint-Collector：收集各种性能数据Pinpoint-Agent：探针与应用服务器（例如tomcat)关联，部署到同一台服务器上Pinpoint-Web：将收集到的数据层现在web展示HBaseStorage：收集到数据存到HBase中2、Pinpoint的数据结构Pinpoint消息的数据结构主要包含三种类型Span，Trace和TraceId。
Span是最基本的调用追踪单元当***调用到达的时候，Span指代处理该调用的作业，并且携带追踪数据。为了实现代码级别的可见性，Span下面还包含一层SpanEvent的数据结构。每个Span都包含一个SpanId。Trace是一组相互关联的Span***同一个Trace下的Span共享一个TransactionId，而且会按照SpanId和ParentSpanId排列成一棵有层级关系的树形结构。TraceId是TransactionId、SpanId和ParentSpanId的组合TransactionId（TxId）是一个交易下的横跨整个分布式系统收发消息的ID，其必须在整个服务器组中是全局唯一的。也就是说TransactionId识别了整个调用链；SpanId（SpanId）是处理***调用作业的ID，当一个调用到达一个节点的时候随即产生；ParentSpanId（pSpanId）顾名思义，就是产生当前Span的调用方Span的ID。如果一个节点是交易的最初发起方，其ParentSpanId是-1，以标志其是整个交易的根Span。下图能够比较直观的说明这些ID结构之间的关系。3、Pinpoint部署网上太多部署文档，这里不详细说明，简要说明下：
注意版本要求：
有两种方式启动：
方式一：修改tomat目录下bin/catalina.sh，在ControlScriptfortheCATALINAServer加入以下三行代码：
复制代码
CATALINA_OPTS="$CATALINA_OPTS-javaagent:/home/webapps/service/pp-agent/pinpoint-bootstrap-1.6.2.jar"CATALINA_OPTS="$CATALINA_OPTS-Dpinpoint.agentId=pp32tomcattest"CATALINA_OPTS="$CATALINA_OPTS-Dpinpoint.applicationName=32tomcat"第一行：pinpoint-bootstrap-1.6.2.jar的位置第二行：agentId必须唯一,标志一个jvm第三行：applicationName表示同一种应用：同一个应用的不同实例应该使用不同的agentId,相同的applicationName
方式二：SpringBoot启动
复制代码
java-javaagent:/home/webapps/pp-agent/pinpoint-bootstrap-1.6.2.jar-Dpinpoint.agentId=pp32tomcattest-Dpinpoint.applicationName=32tomcat-jar32tomcat-0.0.1-SNAPSHOT.jar4、代码注入是如何工作的Pinpoint对代码注入的封装非常类似AOP，当一个类被加载的时候会通过Interceptor向指定的***前后注入before和after逻辑，在这些逻辑中可以获取系统运行的状态，并通过TraceContext创建Trace消息，并发送给Pinpoint服务器。但与AOP不同的是，Pinpoint在封装的时候考虑到了更多与目标代码的交互能力，因此用Pinpoint提供的API来编写代码会比AOP更加容易和***。
5、Pinpoint实战效果演示搭建一个java开源项目jforum，跑在tomcat下，使用jmeter进行压测，用户100个：
服务器图（ServerMap）通过可视化其组件的互连方式来了解任何分布式系统的拓扑。单击节点将显示有关组件的详细信息，例如其当前状态和事务计数。实时活动线程图（RealtimeActiveThreadChart）实时监视应用程序内的活动线程。（用了官方图，当时没截图）请求/响应散布图（Request/ResponseScatterChart）可视化请求计数和响应模式，以确定潜在问题。可以通过在图表上拖动来选择事务以获取更多详细信息。调用栈信息（CallStack）增强分布式环境中每个事务的代码级可见性，识别单个视图中的瓶颈和故障点。检查器（Inspector）查看应用程序的其他详细信息，如CPU使用率，内存/垃圾收集，TPS和JVM参数。
6、总结第一：PinPoint从宏观上看：总体链路、服务总体状态（cpu、内存等等信息），符合【测试角度场景】性能测试调优监控的宏观；第二：SpringCloudSlueth需要结合Zipkin从微观来看：自身无法单独提供展示，要结合Zipkin展示链路问题（并没有服务器总体状态的展示），更多服务器性能状况等信息展示需要定制脚本通过ELK收集展示，符合【研发角度场景】性能测试调优监控的微观；
总的来说两者是结合体，要单独使用的话，从测试业务上来看：PinPoint满足，性能测试调优监控的宏观【测试角度场景】
7、项目场景访问某个API，后端应用服务产生的一系列链路，为何请求一次有23次数据库访问呢？这里就是需要排查的的地方，详细看看CallTree，找出可优化的SQL查询语句。
另外，在做性能测试的时候，服务器并发的IO，PP不断写入也会产生瓶颈，需要后续解决。
8、标签库项目简单压测通过jmeter对标签库进行简单压测，脚本如下：
通过APM发现问题如下：
pquery.do的res高达6782ms，需要安排开发进一步排查定位代码问题
另外一种场景，测试人员无法在页面获取到的信息（有些情况下，测试人员是没有服务器权限），这些是服务底层的异常信息，可以通过CallTree来查看。
9、应用服务接入APM后的链路全景蜘蛛网图参考文献：Pinpointgithub
Pinpoint源码解析（三）Dapper，大规模分布式系统的跟踪系统Pinpoint学习笔记Pinpointv1.5.0APM视频介绍
原文地址：https://www.infoq.cn/article/apm-Pinpoint-practice/?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage
