進階篇丨鏈路追蹤(Tracing)很簡單:鏈路成本指南

廣義上的鏈路成本,既包含使用鏈路追蹤產生的數據生成、採集、計算、存儲、查詢等額外資源開銷,也包含鏈路系統接入、變更、維護、協作等人力運維成本。爲了便於理解,本小節將聚焦在狹義上的鏈路追蹤機器資源成本,人力成本將在下一小節(效率)進行介紹。

鏈路追蹤機器成本的組成結構

鏈路追蹤機器成本主要分爲客戶端和服務端兩大類。 鏈路追蹤客戶端(SDK/Agent)通常運行在業務進程內部,與業務程序共享 CPU、內存、網絡、磁盤等系統資源。鏈路追蹤的客戶端開銷主要包括鏈路埋點攔截、鏈路數據生成與透傳、簡單的預聚合或壓縮/編碼等數據處理、數據緩存與上報等。客戶端開銷通常屬於一種隱性開銷,短期內不會直接導致資源賬單的增長,而是利用業務進程閒置部分的資源。但是,當業務持續增長或者進入峯值週期(如大促),鏈路追蹤消耗的這部分資源最終會引發實際賬單的增長。因此,這部分的開銷要嚴格控制在一個合理的水位之內,比如不超過 10%,否則會顯著影響業務的正常運轉。

鏈路追蹤的服務端機器成本是一種顯性的、即時投入的資源成本,也是在評估鏈路追蹤選型方案時(自建、託管)的重要考量因素。 鏈路追蹤的服務端通常由網關、消息緩衝、流計算、存儲與查詢端組成,最爲人們所熟知與關注的是鏈路存儲模塊,許多熱點文章討論的鏈路尾部採樣(Tail-based Sampling)主要影響的就是鏈路追蹤服務端存儲成本。但是,在短週期存儲(如 3~7 天)場景下,鏈路數據接收、緩衝與處理的資源成本佔比甚至會超過存儲,也是不容忽視的重要組成部分。

此外,還有一塊容易忽略的成本就是客戶端與服務端之間的網絡傳輸費用。 特別是在跨公網傳輸場景下,不但帶寬成本高,而且傳輸流量會受限,經常需要開啓頭部採樣(Head-based Sampling)來降低鏈路數據上報量。

近年來,主流開源社區或商業化產品陸續推出了邊緣集羣解決方案,即在用戶網絡(VPC)下,部署一套可觀測數據統一採集與處理集羣,支持多源異構數據標準化、鏈路數據無損統計、錯慢全採等特性,可以進一步降低鏈路數據上報與持久化存儲成本。整體架構如下圖所示。

圖片

鏈路追蹤機器成本優化

明晰了鏈路追蹤機器成本的組成結構,我們接下來分析如何進行鍼對性優化。在這裏,先提出三個問題:“每一條鏈路數據的價值都相等嗎?”、“對鏈路數據的加工處理是越早越好,還是越晚越好?”、“鏈路數據的存儲時長是越久越好,還是越短越好?”。

爲了解答上述疑問,我們要搞清楚鏈路數據的用法和價值到底是什麼?鏈路數據主要有三種用法,一是根據特定條件篩選並查詢單條調用鏈明細軌跡,用於具體問題的診斷與定位;二是基於固定的維度進行鏈路預聚合,提供服務接口等通用粒度的監控與告警;三是基於鏈路明細進行自定義後聚合,滿足個性化的鏈路分析需求,如 VIP 客戶大於 3S 的慢請求接口分佈。

因此,包含不同特徵的鏈路數據價值並不相等,錯慢鏈路或含有特定業務特徵的鏈路(統稱爲關鍵鏈路),往往比普通鏈路的價值更高,被查詢的概率更大。 我們應該記錄更多的關鍵鏈路,並提高其存儲時長;普通鏈路應該更少記錄,並降低存儲時長。此外,爲了保障統計數據的精確度,我們應該儘早完成鏈路數據的預聚合,這樣就可以更早的進行鏈路採樣,降低明細數據的整體上報與存儲成本。

綜上所述,我們可以從 “鏈路傾斜採樣”、“鏈路計算左移”、“冷熱存儲分離” 等方面進行探索,嘗試以最低的成本,按需記錄最有價值的鏈路數據,實現成本與體驗的動態平衡與優化,如下圖所示。

圖片

鏈路傾斜採樣,記錄更有價值的數據

鏈路數據的價值分佈是不均勻的。據不完全統計,調用鏈的實際查詢率通常小於百萬分之一,也就是說,每一百萬條調用鏈,只會有一條被實際查詢命中,其他鏈路幾乎都是無效存儲。全量存儲調用鏈不僅會造成巨大的成本浪費,也會顯著影響整條數據鏈路的性能及穩定性。

因此,鏈路採樣(Trace Samplling)的理念隨之誕生。早在 Google Dapper 論文問世的時候,就提出了基於固定比例進行鏈路採樣的方法,並在 Google 內部生產系統得到了實踐檢驗。比如每 1024 條鏈路採樣記錄其中一條,採樣比例爲 1/1024。但是,固定比例採樣僅僅解決了控制鏈路開銷的問題,而忽視了鏈路價值分佈的不均勻性,關鍵鏈路與普通鏈路被採樣的概率都是相同的,這就導致許多針對關鍵鏈路的查詢結果出現未命中,極大影響了問題排查的效率。

那麼,我們能否提前預測用戶行爲,只記錄會被查詢的鏈路呢?100% 精準預測非常困難,幾乎難以實現,但是根據歷史行爲和領域經驗進行推測,優先記錄查詢概率更大的鏈路是比較可行的一種降本方案,這就是鏈路傾斜採樣。

鏈路傾斜採樣通常是針對特定的鏈路特徵(如錯、慢、核心接口或自定義業務特徵)設置較高的採樣比例(如 100%)或流量閾值(如前 N 條/分鐘),不符合關鍵特徵的鏈路以極低的比例採樣(如 1%)甚至不採樣。如下圖所示的阿里雲鏈路追蹤自定義採樣配置頁面,用戶可以根據自身需要自由定製特徵採樣策略,在保證較高的查詢命中率(如 50%+)的前提下,鏈路數據實際存儲量可以達到原始數據量的 5% 左右,極大的節省了服務端持久化存儲的成本。 更多鏈路採樣策略將在實戰篇進行詳細介紹,比如動態採樣。

3.png

延伸一下思路,我們在做問題診斷時,除了調用鏈之外,通常還需要結合日誌、異常堆棧、本地方法耗時、內存快照等關聯信息進行綜合判斷。如果每一次請求的關聯信息全都記錄下來,大概率會造成系統的崩潰。因此,借鑑“鏈路傾斜採樣”的理念,丟棄無用或低價值數據,保留異常現場或滿足特定條件的高價值數據,精細化的按需存儲能力應該成爲衡量 Tracing 乃至可觀測產品優劣的重要標準之一。如下圖所示,阿里雲 ARMS 產品提供了慢調用場景下自動保留完整本地方法棧的能力,可以實現慢調用的行級代碼定位。

4.png

鏈路計算左移,提煉數據價值

除了篩選記錄更有價值的數據之外,還可以將數據加工計算從服務端“左移”至客戶端或邊緣集羣,提前完成數據價值提煉,如預聚合或壓縮編碼,這樣就可以在滿足用戶查詢需求的前提下,有效節省數據傳輸與存儲成本。

  • 預聚合統計:在客戶端進行預聚合的最大好處, 就是在不損失數據精度的同時大幅減少數據上報量。比如,對調用鏈進行 1% 採樣後,仍然可以提供精準的服務概覽/上下游等監控告警能力。
  • 數據壓縮:對重複出現的長文本(如異常堆棧,SQL 語句)進行壓縮編碼,也可以有效降低網絡開銷。結合非關鍵字段模糊化處理效果更佳。

冷熱存儲分離,低成本滿足個性化分析需求

鏈路採樣和計算左移的思路都是儘可能減少鏈路明細數據的上報與存儲,從而達到降成本的目的。這兩種做法可以比較好的滿足單鏈路查詢與通用場景下的預聚合監控告警,但卻無法滿足多樣化的後聚合分析需求,比如某個業務需要統計耗時大於 3 秒的接口及來源分佈,這種個性化的後聚合分析規則是無法窮舉的。而當我們無法預先定義分析規則時,貌似就只能採用成本極高的全量原始數據存儲。難道就沒有優化的空間麼?答案也是有的,接下來我們就介紹一種低成本解決後聚合分析問題的方案——冷熱存儲分離。

冷熱存儲分離的基礎在於用戶的查詢行爲滿足時間上的局部性原理。 簡單理解就是,時間越近的熱數據查詢概率越大,時間越久的冷數據查詢概率越小。例如,由於問題診斷的時效性,50% 以上的鏈路查詢分析發生在 30 分鐘內,7 天之後的鏈路查詢通常集中在錯慢調用鏈。理論基礎成立,接下來討論如何實現冷熱存儲分離。

首先,熱數據存在時效性,如果只需記錄最近一段時間內的熱數據,對於存儲空間的要求就會下降很多。另外,在公有云環境下,不同用戶的數據天然具備隔離性。因此,在用戶 VPC 內部的熱數據計算和存儲方案就具備更優的性價比。

其次,冷數據的查詢具備指向性,可以通過不同的採樣策略篩選出滿足診斷需求的冷數據進行持久化存儲。例如錯慢採樣,特定業務場景採樣等。由於冷數據存儲週期較長,對穩定性要求較高,可以考慮在共享數據中心統一管理。

綜上所述,熱數據存儲週期短,成本低,但可以滿足實時全量後聚合分析需求;而冷數據經過精準採樣後數據總量大幅下降,通常只有原始數據量的 1% ~10%,並可以滿足大多數場景的診斷訴求。兩相結合,實現了成本與體驗的平衡最優解。國內外領先的 APM 產品,如 ARMS、Datadog、Lightstep 均採用了冷熱數據分離的存儲方案。

5.png

冷熱存儲分離的具體實現方式,以及不同存儲的選型比對,我們將在實戰篇進行詳細解讀。下圖展示了阿里雲鏈路追蹤提供的 30 分鐘熱數據全量分析的示意圖。

圖片

小結

隨着雲原生與微服務架構的興起,可觀測數據量(Traces、Logs、Metrics)呈現爆發式增長態勢,越來越多的企業開始重視可觀測的成本管理,FinOps 也成爲當下流行的一種新型協同範式。全量數據上報、存儲、再分析這種傳統方案將面臨越來越大的挑戰。通過傾斜採樣記錄更有價值的數據,通過計算左移提煉數據價值,通過冷熱存儲分離實現更高性價比的數據價值探索,將逐漸成爲雲原生時代的主流方案,讓我們一起來探索實踐吧!

點擊此處,瞭解更多鏈路追蹤與可觀測產品

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章