開源APM效能檢測系統技術選型與架構實戰

隨著分散式應用、雲端計算的不斷深入發展，業務系統的邏輯結構變得越來越複雜，目前很多應用都採用了分散式架構，即從一個大程式演變成一系列服務的形式，執行在不同的平臺不同的機器上，這種架構的複雜性和靈活性為發現和定位效能問題、系統安全運維帶來了更高的挑戰。此時需要一種新的技術手段，用來關注應用哪些問題影響了企業服務的效能和可用性，關注如何識別這些問題以及如何解決這些問題。本文將介紹目前業界主流的APM技術工具，解決分散式架構帶來的監控和運維上的挑戰。

一、APM基礎篇

1、什麼是APM?

APM，全稱：Application Performance Management ，目前市面的系統基本都是參考Google的Dapper（大規模分散式系統的跟蹤系統）來做的，翻譯傳送門《google的Dapper 中文翻譯》

APM（ApplicationPerformance Management）是一種應用效能監控工具，通過匯聚業務系統各處理環節的實時資料，分析業務系統各事務處理的交易路徑和處理時間，實現對應用的全鏈路效能監測。目前主流的APM工具，基本都是參考了Google的Dapper（大規模分散式系統的跟蹤系統）體系，通過跟蹤業務請求的處理過程，完成對應用系統在前後端處理、服務端呼叫的效能消耗跟蹤，提供視覺化的介面來展示對跟蹤資料的分析。

思考下：不遵守該理論的是偽APM，耍流氓嗎？

APM的核心思想是什麼？ 在應用服務各節點相互呼叫的時候，從中記錄並傳遞一個應用級別的標記，這個標記可以用來關聯各個服務節點之間的關係。比如兩個應用服務節點之間使用 HTTP 作為傳輸協議的話，那麼這些標記就會被加入到 HTTP 頭中。可見如何傳遞這些標記是與應用服務節點之間使用的通訊協議有關的，常用的協議就相對容易加入這些內容，一些按需定製的可能就相對困難些，這一點也直接決定了實現分散式追蹤系統的難度。

2、為什麼要用APM?

有業務痛點，才要尋求解決方案，個人認為，APM需要優先解決測試環境下兩個場景問題，基於測試先行的原則考慮：

優先關注巨集觀資料，並不是說測試人員無須關注微觀層面的問題，在測試角度來看，先解決效能測試環境的資料取樣、收集問題，再去評估生產環境，而線上的鏈路監控需要研發跟運維去配合，【研發角度場景】相對於測試人員來說是弱關注了。

APM工具與傳統的效能監控工具的區別在於，不僅僅提供一些零散的資源監控點和指標，其主要關注在系統內部執行、系統間呼叫的效能瓶頸分析，這樣更有利於定位到問題的具體原因。

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

近年來APM技術和市場得到了快速發展，隨著移動網際網路的爆發，APM的產業擴張的比較明顯，重心也從最初的IT和技術運維轉到了商業核心業務，相關產品也如雨後春筍般大量湧現出來，商業產品有國外的Dynatrace、Appdynamics、New Relic、卓豪，國內的RichAPM、聽雲、OneAPM、阿里的業務實時監控服務 ARMS和百度MTC等等，開源產品也得到了迅速發展。

                                               隨後筆者帶大家一起了解幾種業界主流的開源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

我所知道相對有名的APM系統主要有以下幾個（翻譯上面的英文原文）：

• 1、Pinpoint

github地址：GitHub - naver/pinpoint: Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java.
對java領域的效能分析有興趣的朋友都應該看看這個開源專案，這個是一個韓國團隊開源出來的，通過JavaAgent的機制來做位元組碼程式碼植入，實現加入traceid和抓取效能資料的目的。
NewRelic、Oneapm之類的工具在java平臺上的效能分析也是類似的機制。

• 2、SkyWalking

github地址：wu-sheng/sky-walking
這是國內一位叫吳晟的兄弟開源的，也是一個對JAVA分散式應用程式叢集的業務執行情況進行追蹤、告警和分析的系統，在github上也有400多顆星了。
功能相對pinpoint還是稍弱一些，外掛還沒那麼豐富，不過也很難得了。

• 3、Zipkin

官網：OpenZipkin · A distributed tracing system
github地址：GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system
這個是twitter開源出來的，也是參考Dapper的體系來做的。

Zipkin的java應用端是通過一個叫Brave的元件來實現對應用內部的效能分析資料採集。
Brave的github地址：https://github.com/openzipkin/brave
這個元件通過實現一系列的java攔截器，來做到對http/servlet請求、資料庫訪問的呼叫過程跟蹤。
然後通過在spring之類的配置檔案里加入這些攔截器，完成對java應用的效能資料採集。

• 4、CAT

github地址：GitHub - dianping/cat: Central Application Tracking
這個是大眾點評開源出來的，實現的功能也還是蠻豐富的，國內也有一些公司在用了。
不過他實現跟蹤的手段，是要在程式碼裡硬編碼寫一些“埋點”，也就是侵入式的。
這樣做有利有弊，好處是可以在自己需要的地方加埋點，比較有針對性；壞處是必須改動現有系統，很多開發團隊不願意。

• 5、Xhprof/Xhgui

這兩個工具的組合，是針對PHP應用提供APM能力的工具，也是非侵入式的。
Xhprof github地址：GitHub - preinheimer/xhprof: XHGUI is a GUI for the XHProf PHP extension, using a database backend, and pretty graphs to make it easy to use and interpret.
Xhgui github地址：GitHub - perftools/xhgui: A graphical interface for XHProf data built on MongoDB

                                前面三個工具裡面，我推薦的順序依次是Pinpoint—》Zipkin—》CAT。

原因很簡單，就是這三個工具對於程式原始碼和配置檔案的侵入性，是依次遞增的：
Pinpoint：基本不用修改原始碼和配置檔案，只要在啟動命令裡指定javaagent引數即可，對於運維人員來講最為方便；
Zipkin：需要對Spring、web.xml之類的配置檔案做修改，相對麻煩一些；
CAT：因為需要修改原始碼設定埋點，因此基本不太可能由運維人員單獨完成，而必須由開發人員的深度參與了，而很多開發人員是比較抗拒在程式碼中加入這些東西滴；

相對於傳統的監控軟體（Zabbix之流）的區別，APM跟關注在對於系統內部執行、系統間呼叫的效能瓶頸分析，這樣更有利於定位到問題的具體原因，而不僅僅像傳統監控軟體一樣只提供一些零散的監控點和指標，就算告警了也不知道問題是出在哪裡。 

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部署

網上太多部署文件，這裡不詳細說明，簡要說明下：

注意版本要求：

• Java version required to run Pinpoint:
  
• HBase compatibility table:
  
• Agent compatibility table:
  

有兩種方式啟動：

方式一：修改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

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後的鏈路全景蜘蛛網圖

 

總結

介紹了4種主流的開源APM工具，最後我從程式碼侵入方式、資料落地方式、效能分析報表等三個方面對上述工具進行對比分析：

通過對比可知，主流APM工具為了更好地進行推廣，主要採用了侵入程度低的方式完成對應用程式碼的改造。並且為了應對雲端計算、微服務、容器化的迅速發展與應用帶來的APM監控的資料的海量增長的趨勢，資料落地方式也主要以海量儲存資料庫為主。         未來在資料分析和效能分析方面，大資料和機器學習將在APM領域發揮重要的作用，APM的功能也將從單一的資源監控和應用監控，向異常檢測、效能診斷、未來預測等自動化、智慧化等方向發展，讓我們共同期待開源社群或組織帶來功能更強大的免費產品！

【參考資料】

1、回到網易後開源APM技術選型與實戰 http://www.infoq.com/cn/articles/apm-Pinpoint-practice

2、常見開源APM監控工具介紹_搜狐科技 https://www.sohu.com/a/226488076_505794

3、OneAPM Servers | 伺服器監控軟體 | 伺服器監控系統 – OneAPM https://www.oneapm.com/others/servers.html

4、業務實時監控服務ARMS_秒級業務監控 https://www.aliyun.com/product/arms

5、開源APM工具pinpoint安裝與使用 - CSDN部落格 https://blog.csdn.net/wh211212/article/details/80437696