APM 原理與框架

APM 原理與框架

三豐 soft張三丰

APM簡介

隨着微服務架構的流行，一次請求每每須要涉及到多個服務，所以服務性能監控和排查就變得更復雜：

不一樣的服務可能由不一樣的團隊開發、甚至可能使用不一樣的編程語言來實現 服務有可能布在了幾千臺服務器，橫跨多個不一樣的數據中心 所以，就須要一些能夠幫助理解系統行爲、用於分析性能問題的工具，以便發生故障的時候，可以快速定位和解決問題，這就是APM系統，全稱是（Application Performance Monitor，固然也有叫 Application Performance Management tools）

AMP最先是谷歌公開的論文提到的 Google Dapper。Dapper是Google生產環境下的分佈式跟蹤系統，自從Dapper發展成爲一流的監控系統以後，給google的開發者和運維團隊幫了大忙，因此谷歌公開論文分享了Dapper。

谷歌Dapper介紹

在google的首頁頁面，提交一個查詢請求後，會經歷什麼：

•可能對上百臺查詢服務器發起了一個Web查詢，每個查詢都有本身的Index
•這個查詢可能會被髮送到多個的子系統，這些子系統分別用來處理廣告、進行拼寫檢查或是查找一些像圖片、視頻或新聞這樣的特殊結果
•根據每一個子系統的查詢結果進行篩選，獲得最終結果，最後彙總到頁面上
•總結一下：
一次全局搜索有可能調用上千臺服務器，涉及各類服務。用戶對搜索的耗時是很敏感的，而任何一個子系統的低效都致使致使最終的搜索耗時 若是一次查詢耗時不正常，工程師怎麼來排查究竟是由哪一個服務調用形成的？

•首先，這個工程師可能沒法準確的定位到此次全局搜索是調用了哪些服務，由於新的服務、乃至服務上的某個片斷，都有可能在任什麼時候間上過線或修改過，有多是面向用戶功能，也有多是一些例如針對性能或安全認證方面的功能改進
•其次，你不能苛求這個工程師對全部參與此次全局搜索的服務都瞭如指掌，每個服務都有多是由不一樣的團隊開發或維護的
•再次，這些暴露出來的服務或服務器有可能同時還被其餘客戶端使用着，因此此次全局搜索的性能問題甚至有多是由其餘應用形成的
從上面能夠看出Dapper須要：

無所不在的部署，無所不在的重要性不言而喻，由於在使用跟蹤系統的進行監控時，即使只有一小部分沒被監控到，那麼人們對這個系統是否是值得信任都會產生巨大的質疑 持續的監控

Dapper的三個具體設計目標

性能消耗低

APM組件服務的影響應該作到足夠小。服務調用埋點自己會帶來性能損耗，這就須要調用跟蹤的低損耗，實際中還會經過配置採樣率的方式，選擇一部分請求去分析請求路徑。在一些高度優化過的服務，即便一點點損耗也會很容易察覺到，並且有可能迫使在線服務的部署團隊不得不將跟蹤系統關停。

應用透明，也就是代碼的侵入性小

即也做爲業務組件，應當儘量少***或者無***其餘業務系統，對於使用方透明，減小開發人員的負擔。

對於應用的程序員來講，是不須要知道有跟蹤系統這回事的。若是一個跟蹤系統想生效，就必須須要依賴應用的開發者主動配合，那麼這個跟蹤系統也太脆弱了，每每因爲跟蹤系統在應用中植入代碼的bug或疏忽致使應用出問題，這樣纔是沒法知足對跟蹤系統「無所不在的部署」這個需求。

可擴展性

一個優秀的調用跟蹤系統必須支持分佈式部署，具有良好的可擴展性。可以支持的組件越多固然越好。或者提供便捷的插件開發API，對於一些沒有監控到的組件，應用開發者也能夠自行擴展。

數據的分析

數據的分析要快 ，分析的維度儘量多。跟蹤系統能提供足夠快的信息反饋，就能夠對生產環境下的異常情況作出快速反應。分析的全面，可以避免二次開發。

Dapper的分佈式跟蹤原理

基本方法

例以下圖這樣的調用關係：

•黑盒方案：假定須要跟蹤的除了上述信息以外沒有額外的信息，這樣使用統計迴歸技術來推斷二者之間的關係。須要一些額外的數據來得到足夠精度。
•基於標註的方案：依賴於應用程序或中間件明確地標記一個全局ID，從而鏈接每一條記錄和發起者的請求。缺點是有代碼***。

跟蹤樹和span

在Dapper跟蹤樹結構中，樹節點是整個架構的基本單元，而每個節點又是對span的引用。節點之間的連線表示的span和它的父span直接的關係。雖然span在日誌文件中只是簡單的表明span的開始和結束時間，他們在整個樹形結構中倒是相對獨立的。這裏span是跟蹤術結構的基本單元，也表示一小段的時間。下圖是5個span在Dapper跟蹤樹種短暫的關聯關係

上圖說明了span在一個大的跟蹤過程當中是什麼樣的。Dapper記錄了span名稱，以及每一個span的ID和父ID，以重建在一次追蹤過程當中不一樣span之間的關係。若是一個span沒有父ID被稱爲root span。全部span都掛在一個特定的跟蹤上，也共用一個跟蹤id（在圖中未示出）。全部這些ID用全局惟一的64位整數標示。在一個典型的Dapper跟蹤中，咱們但願爲每個RPC對應到一個單一的span上，並且每個額外的組件層都對應一個跟蹤樹型結構的層級。

上圖給出了一個更詳細的典型的Dapper跟蹤span的記錄點的視圖。在圖中這種某個span表述了兩個「Helper.Call」的RPC(分別爲server端和client端)。span的開始時間和結束時間，以及任何RPC的時間信息都經過Dapper在RPC組件庫的植入記錄下來。若是應用程序開發者選擇在跟蹤中增長他們本身的註釋（如圖中「foo」的註釋）(業務數據)，這些信息也會和其餘span信息同樣記錄下來。

埋點

1.追蹤的上下文信息在ThreadLocal中進行存儲。
2.當計算過程是延遲調用的或是異步的，google經過通用的控制流來回調，確保全部的回調能夠存儲此次跟蹤的上下文信息。當回調函數被觸發時，此次跟蹤的上下文會與適當的線程關聯上。在這種方式下，Dapper可使用trace ID和span ID來輔助構建異步調用的路徑。
3.google的全部進程通訊是創建在一個RPC框架上。在RPC框架自己中來埋點從而定義全部span。
4.dapper容許用戶在Dapper跟蹤的過程當中添加額外的信息，以監控更高級別的系統行爲，或幫助調試問題。咱們容許用戶經過一個簡單的API定義帶時間戳的Annotation，核心的示例代碼以下圖所示。
5.dapper支持以下圖的文本annotation也支持key-value映射的Annotation。如持續的計數器，二進制消息記錄和在一個進程上跑着的任意的用戶數據等。

跟蹤收集

下圖演示了Dapper收集管道：

由上圖可知，Dapper的跟蹤記錄和收集管道的過程分爲三個階段: span數據寫入本地日誌文件中。而後Dapper的守護進程和收集組件把這些數據從生產環境的主機中拉出來 寫到Dapper的Bigtable倉庫中。一次跟蹤被設計成Bigtable中的一行，每一列至關於一個span。Bigtable的支持稀疏表格佈局正適合這種狀況，由於每一次跟蹤能夠有任意多個span。Dapper還提供了一個API來簡化訪問咱們倉庫中的跟蹤數據。Google的開發人員用這個API，以構建通用和特定應用程序的分析工具。

APM組件選型

市面上的全鏈路監控理論模型大多都是借鑑Google Dapper論文，重點關注如下三種APM組件：

•Zipkin：由Twitter公司開源，開放源代碼分佈式的跟蹤系統，用於收集服務的定時數據，以解決微服務架構中的延遲問題，包括：數據的收集、存儲、查找和展示。
•Pinpoint：一款對Java編寫的大規模分佈式系統的APM工具，由韓國人開源的分佈式跟蹤組件。
•Skywalking：國產的優秀APM組件，是一個對JAVA分佈式應用程序集羣的業務運行狀況進行追蹤、告警和分析的系統。

對比項

主要對比項：

探針的性能

主要是agent對服務的吞吐量、CPU和內存的影響。微服務的規模和動態性使得數據收集的成本大幅度提升。

collector的可擴展性

可以水平擴展以便支持大規模服務器集羣。

全面的調用鏈路數據分析

提供代碼級別的可見性以便輕鬆定位失敗點和瓶頸。

對於開發透明，容易開關

添加新功能而無需修改代碼，容易啓用或者禁用。

完整的調用鏈應用拓撲

自動檢測應用拓撲，幫助你搞清楚應用的架構

如何採集數據

APM是經過採集探針採集應用數據的。採集探針是經過字節碼加強技術進行埋點，生成調用數據。調用數據被採集代理ICAgent所獲取並處理，而後上報並呈如今界面中。關係以下圖所示：

採集哪些數據

APM僅採集應用的業務調用鏈數據、資源信息、資源屬性、內存檢測信息、調用請求的KPI數據，不涉及我的隱私數據。所採集的數據僅用於APM性能分析和故障診斷，不會用於其餘商業目的。下表爲數據採集範圍和用途。

行業分析

目前APM市場在海外主要有兩類的核心企業。一類是四大傳統IT巨頭（IBM、HP、CATechnologies、BMC），另外一類是ITOM市場新創企業，包括Dynatrace、NewRelic、AppDynamics、Splunk等。隨着市場成熟度的不斷提升，APM市場的市場格局與ITOM總體的市場格局同樣，呈現初創企業加速發展，開始佔據市場主導的市場趨勢。

根據調查數據顯示，NewRelic、AppDynamics以及Dynatrace做爲新創企業依舊保持在APM市場的領導者象限，這三家公司是當前全球APM市場的標杆企業。

在國內，博睿、聽雲、OneAPM、雲智慧在國內市場的佔用額較大