■ 李耀宗
我之前曾重點介紹過如何將大數據用于APM來加速平均修復時間(MTTR)的問題。不同于數據采樣或觸發器方式,APM大數據方式可以確保隨時提供全部所需數據,即使是在依賴微服務,虛擬化和云服務的動態應用環境中也沒有問題。
目前,人們除了對APM大數據的實用性存在一些誤解之外,關于其是否可行,也存在誤區。因此,本文將探討有關大數據技術應用于APM的三大誤區。
APM數據可分為兩個測定類別:
1.描述應用工作負載的數據,并通知應用的行為或執行情況。
2.描述應用環境的數據,以關鍵指標的形式顯示基礎設施如何響應應用需求。
APM大數據的規模是捕獲原始數據和未過濾數據的副產品。收集、存儲、分析和訪問PB級的數據是一項浩大的工程,但它驚人的一面是這些PB級的數據代表了我們想要探索,了解和獲取信息所需的未經過濾的“純凈的”事實。大數據的不同方面適用于不同的測定類別,但在以上兩種情況下,其終極目標都是提供完整且正確的理解。
許多APM產品并非是為了支持大數據而設計的,而是為了迫使客戶在規模和數據質量之間做出權衡。
將APM用于數據質量和深度時,其通常因無法擴展而難以支持應用生態系統
或者犧牲數據質量和深度來擴展APM以支持應用生態系統
APM供應商通常借助采樣和觸發器方式來進行交易追蹤,通過匯聚數據以及犧牲調用堆棧的深度和細節來滿足其可擴展性需求。否則他們只能監測1-2個應用,并部署多個分析控制臺。
這些不能令人滿意的方案無法提供解決性能問題所需的數據完整性,尤其是在資源根據需求而快速增減變化的短暫環境中,而共享的依賴關系意味著一個組件的故障可能會對多筆交易產生負面影響。
捕獲每個用戶動作和后端活動的詳細交易記錄確實會產生大量數據,但APM與其它設計大數據解決方案的行業并沒有什么不同。相同的大數據技術和架構也適合于APM。
例如,在許多分布式系統場景中,除了流媒體和復雜事件處理架構外,利用非關系型高度優化的數據存儲是普遍的共識。此外,跨APM組件的聯合數據處理和分析功能則有助于分配工作負載,如同您在Hadoop集群中看到的那樣。
在三層處理模式中,應用內收集器只完成極少量的工作,并將原始數據傳遞給本地處理器,在本地處理器進行壓縮和一些基礎分析工作后再將數據發送到中央引擎。這一方法遠比兩層方法更好,應用內收集器給應用或后端系統帶來的壓力也要小得多。
持續捕獲所有交易細節可使應用更具彈性且更易于管理,因為它不再依賴用于配置和維護的復雜規則、檢測及觸發引擎。一定會有更多的數據,但此時管理存儲的問題已經解決,且存儲是比計算更便宜的資源。
任何與應用相關的技術,其成本都是一個很重要的問題。APM代理也不例外。通過連續捕獲交易來啟用的大數據APM需在如何觀察、記錄和持久的交易中使用不同的技術,以確保應用不會受到開銷影響。代理可以動態地發現應用棧,并在交易表述中記錄每個關鍵方法和應用調用。然后利用三層分布式架構對交易進行實時壓縮和流化處理。N