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、雲智慧在國內市場的佔用額較大