引言：最近在調研與選型分散式呼叫鏈監控元件。選了主要的三種APM元件進行了實踐與比較。本來打算一篇文章寫完的，篇幅太長，打算分兩篇。距離第一篇已經有近一個月時間了，主要最近工作比較忙，更新很慢。本文將會講下幾種APM選型的比較與效能測試。
1. 前文回顧
上一篇文章主要講了三種分散式呼叫鏈監控元件的實踐。問題的背景由微服務架構展開，微服務的好處已經不用多說，而微服務的多了之後，千頭萬緒，下面這張圖經常被用到。
系統的複雜度因此提升。系統越複雜，越難解決問題，例如系統失敗或者效能問題。在三層架構中找到解決方案還不是太難，僅僅需要分析3個元件比如web伺服器，應用伺服器和資料庫，而伺服器數量也不多。但是，如果問題發生在n層架構中，就需要調查大量的元件和伺服器。另一個問題是僅僅分析單個元件很難看到大局;當發生一個低可見度的問題時，系統複雜度越高，就需要更長的時間來查詢原因。最糟糕的是，某些情況下我們甚至可能無法查詢出來。
上面其實已經提到存在的故障定位問題，基於微服務體系之下構建的業務系統存在的問題基本上分為三類：
- 故障定位難，一個簡單操作，其背後可能是由十幾個微服務共同完成的，這些微服務也由不同的團隊去負責。一旦出現問題，最壞情況下我們也許需要這十幾個團隊一起來解決問題。
- 鏈路梳理難，應用沒有形成應用拓撲，不知道自己的服務下游會影響其他哪些人。
- 資源浪費多，容量預估難。對於一些服務，其消耗的cpm和memory可能連10%不到，遠遠沒有充分利用物理機。這其實和容量預估關聯，過大或者過小估算峰值的機器容量，都是浪費。
APM主要的目的就是解決上面所說的這四個問題，主要的手段是通過收集、儲存、分析、分散式系統中的呼叫事件資料，協助開發運營人員進行故障診斷、容量預估、效能瓶頸定位以及呼叫鏈路梳理。第一篇其實已經講過鏈路監控元件的需求：
- 程式碼的侵入性
- 探針的效能消耗
- 全面的呼叫鏈路資料分析
- 可擴充套件性
這邊列一下pinpoint在其wiki中提到的幾點：
- 分散式事務跟蹤，跟蹤跨分散式應用的訊息
- 自動檢測應用拓撲，幫助你搞清楚應用的架構
- 水平擴充套件以便支援大規模伺服器叢集
- 提供程式碼級別的可見性以便輕鬆定位失敗點和瓶頸
- 使用位元組碼增強技術，新增新功能而無需修改程式碼
下面我們沿著這些需求，看一下這幾種分散式呼叫鏈監控元件。
2. AMP比較
上面列了需求，但是不夠通用，筆者將需要對比的項提煉出來：
- 探針的效能
主要是agent對服務的吞吐量、CPU和記憶體的影響。微服務的規模和動態性使得資料收集的成本大幅度提高。 - collector的可擴充套件性
能夠水平擴充套件以便支援大規模伺服器叢集。 - 全面的呼叫鏈路資料分析
提供程式碼級別的可見性以便輕鬆定位失敗點和瓶頸。 - 對於開發透明，容易開關
新增新功能而無需修改程式碼，容易啟用或者禁用。 - 完整的呼叫鏈應用拓撲
自動檢測應用拓撲，幫助你搞清楚應用的架構
筆者根據主要的需求，提煉出如上五點。
2.1 探針的效能
筆者其實也是比較關注探針的效能，畢竟APM定位還是工具，如果啟用了鏈路監控組建後，直接導致吞吐量降低過半，那也是不能接受的。筆者對skywalking、zipkin、pinpoint進行了壓測，並與基線（未使用探針）的情況進行了對比。
選用了一個常見的基於Spring的應用程式，他包含Spring Boot, Spring MVC，redis客戶端，mysql。 監控這個應用程式，每個trace，探針會抓取5個span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。這邊基本和skywalkingtest的測試應用差不多。
模擬了三種併發使用者：500，750，1000。使用jmeter測試，每個執行緒傳送30個請求，設定思考時間為10ms。使用的取樣率為1，即100%，這邊與產線可能有差別。pinpoint預設的取樣率為20，即50%，通過設定agent的配置檔案改為100%。zipkin預設也是1。組合起來，一共有12種。下面看下彙總表。
從上表可以看出，在三種鏈路監控元件中，skywalking的探針對吞吐量的影響最小，zipkin的吞吐量居中。pinpoint的探針對吞吐量的影響較為明顯，在500併發使用者時，測試服務的吞吐量從1385降低到774，影響很大。然後再看下CPU和memory的影響，筆者是在內部伺服器進行的壓測，對CPU和memory的影響都差不多在10%之內。
2.2 collector的可擴充套件性
collector的可擴充套件性，使得能夠水平擴充套件以便支援大規模伺服器叢集。
- zipkin
在前一篇文章中，我們開發了zipkin-Server（其實就是提供的開箱即用包），zipkin-agent與zipkin-Server通過http或者mq進行通訊，http通訊會對正常的訪問造成影響，所以還是推薦基於mq非同步方式通訊，zipkin-Server通過訂閱具體的topic進行消費。這個當然是可以擴充套件的，多個zipkin-Server例項進行非同步消費mq中的監控資訊。
- skywalking
skywalking的collector支援兩種部署方式：單機和叢集模式。collector與agent之間的通訊使用了gRPC。 - pinpoint
同樣，pinpoint也是支援叢集和單機部署的。pinpoint agent通過thrift通訊框架，傳送鏈路資訊到collector。
2.3 全面的呼叫鏈路資料分析
全面的呼叫鏈路資料分析，提供程式碼級別的可見性以便輕鬆定位失敗點和瓶頸。
- zipkin
zipkin的鏈路監控粒度相對沒有那麼細，從上圖可以看到呼叫鏈中具體到介面級別，再進一步的呼叫資訊並未涉及。
- skywalking
skywalking 還支援20+的中介軟體、框架、類庫，比如主流的dubbo、Okhttp，還有DB和訊息中介軟體。上圖skywalking鏈路呼叫分析擷取的比較簡單，閘道器呼叫user服務，由於支援眾多的中介軟體，所以skywalking鏈路呼叫分析比zipkin完備些。
- pinpoint
pinpoint應該是這三種APM元件中，資料分析最為完備的元件。提供程式碼級別的可見性以便輕鬆定位失敗點和瓶頸，上圖可以看到對於執行的sql語句，都進行了記錄。還可以配置報警規則等，設定每個應用對應的負責人，根據配置的規則報警，支援的中介軟體和框架也比較完備。
2.4 對於開發透明，容易開關
對於開發透明，容易開關，新增新功能而無需修改程式碼，容易啟用或者禁用。我們期望功能可以不修改程式碼就工作並希望得到程式碼級別的可見性。
對於這一點，Zipkin 使用修改過的類庫和它自己的容器(Finagle)來提供分散式事務跟蹤的功能。但是，它要求在需要時修改程式碼。skywalking和pinpoint都是基於位元組碼增強的方式，開發人員不需要修改程式碼，並且可以收集到更多精確的資料因為有位元組碼中的更多資訊。
2.5 完整的呼叫鏈應用拓撲
自動檢測應用拓撲，幫助你搞清楚應用的架構。
上面三幅圖，分別展示了APM元件各自的呼叫拓撲，都能實現完整的呼叫鏈應用拓撲。相對來說，pinpoint介面顯示的更加豐富，具體到呼叫的DB名，zipkin的拓撲侷限於服務於服務之間。
3. 總結
本文講了三種分散式呼叫鏈監控元件的比較，主要從五方面著手，筆者對每一項都進了對比。至於具體選用哪款元件，大家可以根據實際的業務需求和場景進行選型，上面比較的資料僅供參考。這三款都是開源專案，一般公司都對針對實際情況進行一些二次開發，比如增加一些元件的支援、對接現存的大資料平臺等等。
最後，看了eagleEye的相關介紹，想提下監控系統如何從被動報警轉化為主動發現，其實和AIOps很密切。鏈路監控資料量很大，儘管可以通過壓縮比來降低傳輸的資料量，但是我們真的需要儲存每一條鏈路嗎？是不是隻需要識別每一個鏈路當中出現異常的情況。時序指標當中的異常點，那個時間點我們要識別出來。識別完了之後，對異常進行關聯，定位出最後的問題。當然這個涉及到業務和應用系統層面，很複雜，但筆者認為是後面AIOps的大趨勢。