篇幅一：APM 基礎篇
1、什麼是 APM?
APM，全稱：Application Performance Management ，目前市面的系統基本都是參考 Google 的 Dapper（大規模分佈式系統的跟蹤系統）來做的，翻譯傳送門《google 的Dapper 中文翻譯》
思考下：不遵守該理論的是偽 APM，耍流氓嗎？
APM 的核心思想是什麼？ 在應用服務各節點相互調用的時候，從中記錄並傳遞一個應用級別的標記，這個標記可以用來關聯各個服務節點之間的關係。比如兩個應用服務節點之間使用 HTTP 作為傳輸協議的話，那麼這些標記就會被加入到 HTTP 頭中。可見如何傳遞這些標記是與應用服務節點之間使用的通訊協議有關的，常用的協議就相對容易加入這些內容，一些按需定製的可能就相對困難些，這一點也直接決定了實現分佈式追蹤系統的難度。
2、為什麼要用 APM?
有業務痛點，才要尋求解決方案，個人認為，APM 需要優先解決測試環境下兩個場景問題，基於測試先行的原則考慮：
優先關注宏觀數據，並不是說測試人員無須關注微觀層面的問題，在測試角度來看，先解決性能測試環境的數據採樣、收集問題，再去評估生產環境，而線上的鏈路監控需要研發跟運維去配合，【研發角度場景】相對於測試人員來說是弱關注了。
3、市面上有哪些 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
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 is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java.
架構圖對應說明：
- 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 集合
同一個 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，在 Control Script for the CATALINA Server 加入以下三行代碼：
複製代碼
<code>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"/<code>
第一行：pinpoint-bootstrap-1.6.2.jar 的位置第二行：agentId 必須唯一, 標誌一個 jvm第三行：applicationName 表示同一種應用：同一個應用的不同實例應該使用不同的 agentId, 相同的 applicationName
方式二：SpringBoot 啟動
複製代碼
<code>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/<code>
4、代碼注入是如何工作的
Pinpoint 對代碼注入的封裝非常類似 AOP，當一個類被加載的時候會通過 Interceptor 向指定的方法前後注入 before 和 after 邏輯，在這些邏輯中可以獲取系統運行的狀態，並通過 TraceContext 創建 Trace 消息，併發送給 Pinpoint 服務器。但與 AOP 不同的是，Pinpoint 在封裝的時候考慮到了更多與目標代碼的交互能力，因此用 Pinpoint 提供的 API 來編寫代碼會比 AOP 更加容易和專業。
5、Pinpoint 實戰效果演示
搭建一個 java 開源項目 jforum ，跑在 tomcat 下，使用 jmeter 進行壓測，用戶 100 個：
- 服務器圖（ServerMap）通過可視化其組件的互連方式來了解任何分佈式系統的拓撲。單擊節點將顯示有關組件的詳細信息，例如其當前狀態和事務計數。
- 實時活動線程圖（Realtime Active Thread Chart）實時監視應用程序內的活動線程。（用了官方圖，當時沒截圖）
- 請求 / 響應散佈圖（Request/Response Scatter Chart）可視化請求計數和響應模式，以確定潛在問題。可以通過在圖表上拖動來選擇事務以獲取更多詳細信息。
- 調用棧信息（CallStack）增強分佈式環境中每個事務的代碼級可見性，識別單個視圖中的瓶頸和故障點。
- 檢查器（Inspector）
查看應用程序的其他詳細信息，如 CPU 使用率，內存 / 垃圾收集，TPS 和 JVM 參數。
6、總結
第一：PinPoint 從宏觀上看：總體鏈路、服務總體狀態（cpu、內存等等信息），符合【測試角度場景】性能測試調優監控的宏觀；第二：Spring Cloud Slueth 需要結合 Zipkin 從微觀來看：自身無法單獨提供展示，要結合 Zipkin 展示鏈路問題（並沒有服務器總體狀態的展示），更多服務器性能狀況等信息展示需要定製腳本通過 ELK 收集展示，符合【研發角度場景】性能測試調優監控的微觀；
總的來說兩者是結合體，要單獨使用的話，從測試業務上來看：PinPoint 滿足，性能測試調優監控的宏觀【測試角度場景】
7、項目場景
訪問某個 API，後端應用服務產生的一系列鏈路，為何請求一次有 23 次數據庫訪問呢？這裡就是需要排查的的地方，詳細看看 CallTree，找出可優化的 SQL 查詢語句。
另外，在做性能測試的時候，服務器併發的 IO，PP 不斷寫入也會產生瓶頸，需要後續解決。
8、標籤庫項目簡單壓測
通過 jmeter 對標籤庫進行簡單壓測，腳本如下：
通過 APM 發現問題如下：
pquery.do 的 res 高達 6782ms，需要安排開發進一步排查定位代碼問題
另外一種場景，測試人員無法在頁面獲取到的信息（有些情況下，測試人員是沒有服務器權限），這些是服務底層的異常信息，可以通過 CallTree 來查看。
9、應用服務接入 APM 後的鏈路全景蜘蛛網圖
參考文獻：
Pinpoint github
Pinpoint 源碼解析（三） Dapper，大規模分佈式系統的跟蹤系統 Pinpoint 學習筆記 Pinpoint v1.5.0 APM 視頻介紹
原文地址：https://www.infoq.cn/article/apm-Pinpoint-practice/?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage
閱讀更多 架構師筆記 的文章
