APM入门与实战

篇幅一：APM基础篇

一、什么是APM?

APM，全称：Application Performance Management ，目前市面的系统基本都是参考Google的Dapper（大规模分布式系统的跟踪系统）来作的，翻译传送门《google的Dapper 中文翻译》

思考下：不遵照该理论的是伪APM，耍流氓吗？

APM的核心思想是什么？ 在应用服务各节点相互调用的时候，从中记录并传递一个应用级别的标记，这个标记能够用来关联各个服务节点之间的关系。好比两个应用服务节点之间使用 HTTP 做为传输协议的话，那么这些标记就会被加入到 HTTP 头中。可见如何传递这些标记是与应用服务节点之间使用的通信协议有关的，经常使用的协议就相对容易加入这些内容，一些按需定制的可能就相对困难些，这一点也直接决定了实现分布式追踪系统的难度。

二、为何要用APM?

有业务痛点，才要寻求解决方案，我的认为，APM须要优先解决测试环境下两个场景问题，基于测试先行的原则考虑：

优先关注宏观数据，并非说测试人员无须关注微观层面的问题，在测试角度来看，先解决性能测试环境的数据采样、收集问题，再去评估生产环境，而线上的链路监控须要研发跟运维去配合，【研发角度场景】相对于测试人员来讲是弱关注了。</br>

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

• Pinpoint

Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java.
https://github.com/naver/pinpoint

• SkyWalking

A distributed tracing system, and APM ( Application Performance Monitoring ) .
http://skywalking.org

• Zipkin

Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. Zipkin’s design is based on the Google Dapper paper.
http://zipkin.io/

• CAT （大众点评）

CAT基于Java开发的实时应用监控平台，包括实时应用监控，业务监控。
https://github.com/dianping/cat

四、先说结论

目前比较贴合 Google Dapper 原理设计的，Pinpoint 优于 Zipkin。
Pinpoint对代码的零侵入，运用JavaAgent字节码加强技术，添加启动参数便可。
而且符合【测试角度场景】性能测试调优监控的宏观；
固然，结论太早了，会有疑惑：

" Spring Cloud Slueth和zipkin之间的关系是什么？ "

须要看详细对比的，详见下图：

五、再说对比

本质上 Spring Cloud Slueth 与 Pinpoint 没有可比性，真正对比的是Zipkin，Spring Cloud Slueth 聚焦在链路追踪和分析，将信息发送到Zipkin，利用 Zipkin的存储来存储信息，固然，Zipkin也可使用ELK来记录日志和展现，再经过收集服务器性能的脚本把数据存储到ELK，则能够展现服务器情况信息了。Zipkin的整体展现，也是基于链路分析为主。

篇幅二：Pinpoint实战篇

一、Pinpoint架构图

Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java. </br>

架构图对应说明：

• Pinpoint-Collector：收集各类性能数据
• Pinpoint-Agent：探针与应用服务器（例如tomcat)关联，部署到同一台服务器上
• Pinpoint-Web：将收集到的数据层如今web展现
• HBase Storage：收集到数据存到HBase中

二、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 结构之间的关系。</br>
  

三、Pinpoint部署

网上太多部署文档，这里不详细说明，简要说明下：</br>

注意版本要求：

• Java version required to run Pinpoint:</br>
  
• HBase compatibility table:</br>
  
• Agent compatibility table:</br>
  
  有两种方式启动：
  方式一：修改tomat目录下bin/catalina.sh，在Control Script for the CATALINA Server加入如下三行代码：

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 -jar 32tomcat-0.0.1-SNAPSHOT.jar

四、代码注入是如何工做的

Pinpoint 对代码注入的封装很是相似 AOP，当一个类被加载的时候会经过 Interceptor 向指定的方法先后注入 before 和 after 逻辑，在这些逻辑中能够获取系统运行的状态，并经过 TraceContext 建立 Trace 消息，并发送给 Pinpoint 服务器。但与 AOP 不一样的是，Pinpoint 在封装的时候考虑到了更多与目标代码的交互能力，所以用 Pinpoint 提供的 API 来编写代码会比 AOP 更加容易和专业。

五、Pinpoint实战效果演示

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

• 服务器图（ServerMap）

  经过可视化其组件的互连方式来了解任何分布式系统的拓扑。单击节点将显示有关组件的详细信息，例如其当前状态和事务计数。
  

• 实时活动线程图（Realtime Active Thread Chart）

  实时监视应用程序内的活动线程。（用了官方图，当时没截图）
  

• 请求/响应散布图（Request/Response Scatter Chart）

  可视化请求计数和响应模式，以肯定潜在问题。能够经过在图表上拖动来选择事务以获取更多详细信息。
  

• 调用栈信息（CallStack）

  加强分布式环境中每一个事务的代码级可见性，识别单个视图中的瓶颈和故障点。
  

• 检查器（Inspector）

查看应用程序的其余详细信息，如CPU使用率，内存/垃圾收集，TPS和JVM参数。

六、总结

第一：PinPoint从宏观上看：整体链路、服务整体状态（cpu、内存等等信息），符合【测试角度场景】性能测试调优监控的宏观；
第二：Spring Cloud Slueth须要结合Zipkin从微观来看：自身没法单独提供展现，要结合Zipkin展现链路问题（并无服务器整体状态的展现），更多服务器性能情况等信息展现须要定制脚本经过ELK收集展现，符合【研发角度场景】性能测试调优监控的微观；

总的来讲二者是结合体，要单独使用的话，从测试业务上来看：PinPoint知足，性能测试调优监控的宏观【测试角度场景】

七、项目场景

访问某个API，后端应用服务产生的一系列链路，为什么请求一次有23次数据库访问呢？这里就是须要排查的的地方，详细看看CallTree，找出可优化的SQL查询语句。


另外，在作性能测试的时候，服务器并发的IO，PP不断写入也会产生瓶颈，须要后续解决。

八、标签库项目简单压测

经过jmeter对标签库进行简单压测，脚本以下：

经过APM发现问题以下：

pquery.do的res高达6782ms，须要安排开发进一步排查定位代码问题

另一种场景，测试人员没法在页面获取到的信息（有些状况下，测试人员是没有服务器权限），这些是服务底层的异常信息，能够经过CallTree来查看。

九、应用服务接入APM后的链路全景蜘蛛网图

参考文献：

Pinpoint github
Pinpoint源码解析（三）
Dapper，大规模分布式系统的跟踪系统
Pinpoint学习笔记
Pinpoint v1.5.0 APM 视频介绍