引言：最近在調研與選型分布式呼叫鏈監控元件。選了主要的三種apm元件進行了實踐與比較。本來打算一篇文章寫完的，篇幅太長，打算分兩篇。距離第一篇已經有近乙個月時間了，主要最近工作比較忙，更新很慢。本文將會講下幾種apm選型的比較與效能測試。
微服務呼叫鏈
系統的複雜度因此提公升。系統越複雜，越難解決問題，例如系統失敗或者效能問題。在三層架構中找到解決方案還不是太難，僅僅需要分析3個元件比如web伺服器，應用伺服器和資料庫，而伺服器數量也不多。但是，如果問題發生在n層架構中，就需要調查大量的元件和伺服器。另乙個問題是僅僅分析單個元件很難看到大局;當發生乙個低可見度的問題時，系統複雜度越高，就需要更長的時間來查詢原因。最糟糕的是，某些情況下我們甚至可能無法查詢出來。
上面其實已經提到存在的故障定位問題，基於微服務體系之下構建的業務系統存在的問題基本上分為三類：
apm主要的目的就是解決上面所說的這四個問題，主要的手段是通過收集、儲存、分析、分布式系統中的呼叫事件資料，協助開發運營人員進行故障診斷、容量預估、效能瓶頸定位以及呼叫鏈路梳理。第一篇其實已經講過鏈路監控元件的需求：
這邊列一下pinpoint在其wiki中提到的幾點：
下面我們沿著這些需求，看一下這幾種分布式呼叫鏈監控元件。
上面列了需求，但是不夠通用，筆者將需要對比的項提煉出來：
探針的效能
主要是agent對服務的吞吐量、cpu和記憶體的影響。微服務的規模和動態性使得資料收集的成本大幅度提高。
collector的可擴充套件性
能夠水平擴充套件以便支援大規模伺服器集群。
全面的呼叫鏈路資料分析
提供**級別的可見性以便輕鬆定位失敗點和瓶頸。
對於開發透明，容易開關
新增新功能而無需修改**，容易啟用或者禁用。
完整的呼叫鏈應用拓撲
自動檢測應用拓撲，幫助你搞清楚應用的架構
筆者根據主要的需求，提煉出如上五點。
筆者其實也是比較關注探針的效能，畢竟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%之內。
collector的可擴充套件性，使得能夠水平擴充套件以便支援大規模伺服器集群。
zipkin
全面的呼叫鏈路資料分析，提供**級別的可見性以便輕鬆定位失敗點和瓶頸。
zipkin鏈路呼叫分析
zipkin的鏈路監控粒度相對沒有那麼細，從上圖可以看到呼叫鏈中具體到介面級別，再進一步的呼叫資訊並未涉及。
skywalking鏈路呼叫分析
skywalking 還支援20+的中介軟體、框架、類庫，比如主流的dubbo、okhttp，還有db和訊息中介軟體。上圖skywalking鏈路呼叫分析擷取的比較簡單，閘道器呼叫user服務，由於支援眾多的中介軟體，所以skywalking鏈路呼叫分析比zipkin完備些。
pinpoint鏈路呼叫分析
pinpoint應該是這三種apm元件中，資料分析最為完備的元件。提供**級別的可見性以便輕鬆定位失敗點和瓶頸，上圖可以看到對於執行的sql語句，都進行了記錄。還可以配置報警規則等，設定每個應用對應的負責人，根據配置的規則報警，支援的中介軟體和框架也比較完備。
對於開發透明，容易開關，新增新功能而無需修改**，容易啟用或者禁用。我們期望功能可以不修改**就工作並希望得到**級別的可見性。
對於這一點，zipkin 使用修改過的類庫和它自己的容器(finagle)來提供分布式事務跟蹤的功能。但是，它要求在需要時修改**。skywalking和pinpoint都是基於位元組碼增強的方式，開發人員不需要修改**，並且可以收集到更多精確的資料因為有位元組碼中的更多資訊。
自動檢測應用拓撲，幫助你搞清楚應用的架構。
pinpoint鏈路拓撲
skywalking鏈路拓撲
zipkin dependency
上面三幅圖，分別展示了apm元件各自的呼叫拓撲，都能實現完整的呼叫鏈應用拓撲。相對來說，pinpoint介面顯示的更加豐富，具體到呼叫的db名，zipkin的拓撲侷限於服務於服務之間。
本文講了三種分布式呼叫鏈監控元件的比較，主要從五方面著手，筆者對每一項都進了對比。至於具體選用哪款元件，大家可以根據實際的業務需求和場景進行選型，上面比較的資料僅供參考。這三款都是開源專案，一般公司都對針對實際情況進行一些二次開發，比如增加一些元件的支援、對接現存的大資料平台等等。
最後，看了eagleeye的相關介紹，想提下監控系統如何從被動報警轉化為主動發現，其實和aiops很密切。鏈路監控資料量很大，儘管可以通過壓縮比來降低傳輸的資料量，但是我們真的需要儲存每一條鏈路嗎？是不是只需要識別每乙個鏈路當**現異常的情況。時序指標當中的異常點，那個時間點我們要識別出來。識別完了之後，對異常進行關聯，定位出最後的問題。當然這個涉及到業務和應用系統層面，很複雜，但筆者認為是後面aiops的大趨勢。
幾種分布式呼叫鏈監控元件的實踐與比較（一）實踐
technical overview of pinpoint
阿里微服務之殤及分布式鏈路追蹤技術原理
分布式系統呼叫鏈監控
乙個請求完整的呼叫鏈可能如下圖，經過多個系統服務，呼叫關係複雜。期間我們會關注各個呼叫的各項效能指標，比如吞吐量 tps 響應時間及錯誤記錄等。全鏈路效能監控從整體維度到區域性維度展示各項指標，將跨應用的所有呼叫鏈效能資訊集中展現，可方便度量整體和區域性效能，並且方便找到故障產生的源頭，生產上可極大...
skywalking分布式呼叫鏈
部署 elasticsearch 修改elasticsearch.yml檔案 設定 cluster.name collectordbcluster。此名稱需要和collector配置檔案一致。設定 node.name anyname，可以設定為任意名字，如elasticsearch為集群模式，則每個...
分布式呼叫鏈跟蹤系統 Zipkin
官網 github 英語 tracer，概念 範疇 分布式呼叫鏈跟蹤系統，或分布式鏈路呼叫監控系統。trace span zipkin 以 trace 結構表示對一次請求的追蹤，又把每個 trace 拆分為若干個有依賴關係的 span。span 模型 在微服務架構中，一次使用者請求可能會由後台若干個...