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
