天天看點

BOS分布式鍊路追蹤産品揭秘

作者:支付寶技術

背景

為了快速适應業務變化,聚焦業務疊代,各大廠商都進行了分布式架構的更新改造。特别是近幾年,随着微服務與雲原生的流行,分布式系統的規模愈發龐大,内部服務之間的調用也越來越複雜。

然而,引入分布式架構的同時,也帶來相應的穩定性問題。各項服務的開發人員、開發語言和部署節點等情況很可能各不相同,當分布式系統整體出現異常或者性能瓶頸的時候,依靠傳統的名額監控和日志排查已經很難快速定位到出問題的地方。是以當下分布式系統對可觀測性提出了更高的要求,需要能夠解決以下痛點:

  • 如何動态的展示各服務之間的調用鍊路?
  • 如何快速定位故障?
  • 如何分析性能瓶頸并加以調優?

分布式鍊路追蹤系統

基于上述痛點,分布式鍊路追蹤系統應運而生,其目的在于通過洞察分布式服務之間的互相調用,自動發現系統存在的穩定性隐患,進而為 SRE & 研發 定位風險提供有效的資料支撐。分布式鍊路追蹤可以通過以下兩塊内容完整還原一整條調用鍊路:

  • Trace ID: 代表唯一一次請求的 ID,此 ID 一般由叢集中第一個處理請求的系統産生,并在分布式調用下通過網絡傳遞到下一個被請求系統。
  • Span: 代表了本次請求的完整資訊,包括調用是否成功,調用類型,調用耗時等等。其中最核心是Span ID,代表了本次請求在整個調用鍊路中的位置或者說層次。

同時,基于鍊路聚合可以産生站點内部流量的全局視角,形成網絡拓撲。

分布式鍊路追蹤系統近年來發展迅速,業内也湧現出了一些開源項目和架構,并且為了實作各項目和架構的接口的統一,發展出了 OpenTracing 與 OpenTelemetry 等标準。通過鍊路标準的制定和推廣,有利于使用者通過一套資料采集、處理、導出流程,輕松對接多種雲廠商,避免vendor鎖定,有效的降低了對接和使用的成本。

BOS一直以來緻力于為使用者提供無縫的可觀測能力,持續擁抱可觀測性标準,作為OpenTelemetry項目的重要貢獻者,率先在業内提供了完整的異構應用 OpenTelemetry 鍊路接入方案,并已經在衆多機構中成功落地。

産品能力

業務智能可觀測服務 BOS(Business-Intelligent Observability Service)是基于螞蟻大規模技術風險防控實踐自研的一套運維平台,具有業務數字化運維、全息可觀測定位、智能場景化防控、一體化資料分析和大規模實踐等産品特性,将業務場景可視化和資料業務語義化,賦能雲上/雲下的異構應用開箱即用的智能可觀測能力,為業務提供全方位的穩定性保障,建設業務觀測新範式,讓穩定更有力量。

BOS的分布式鍊路追蹤系統提供了以下豐富的産品功能,緻力于幫助使用者定位和解決微服務架構下的性能問題:

●應用調用拓撲及詳細性能名額

○根據鍊路資料動态生成,幫助使用者梳理微服務架構下各應用之間的調用關系。

○根據調用耗時,調用錯誤率等性能名額,自動定位和标注異常應用和異常調用關系,幫助使用者快速定位故障。

●鍊路資料查詢

○支援多元度的查詢條件,例如超過多少耗時,調用是否失敗,具體的調用接口和方法等等,準确定位到感興趣的調用關系,進而跳轉到具體而詳細的鍊路詳情展示。

●鍊路詳情展示

○通過多種展現方式,例如樹狀圖,拓撲圖、時序圖等,幫助使用者觀測到單條鍊路的完整調用關系。

○根據每次調用的成功與否以及耗時,自動标注出整條鍊路中異常或者潛在性能瓶頸的調用,幫助使用者快速定位具體的單次調用,通過詳盡的單次調用詳情,助力使用者進行應用調優。

○在鍊路詳情中同時打通了與監控和日志資料的關聯,使用者可以非常容易的檢視到相關聯的全量可觀測性資料,幫助定位問題的根本原因。

為了友善使用者完成接入,BOS提供了業内所有常用的鍊路資料格式的對接能力,涵蓋了OpenTelemetry,SofaTracer,Skywalking,Zipkin以及Jaeger等等,使用者應用無論之前是否已經接入了鍊路架構,都可以快速的接入并體驗BOS分布式鍊路追蹤系統的完整能力。

通過上述BOS分布式鍊路追蹤産品提供的豐富功能,将賦予使用者以下的宏觀能力:

風險定位

在分布式場景下,服務調用錯綜複雜,并且涉及到衆多中間件的調用,出現問題的時候如何排查和定位具體的問題應用和服務,如果依靠傳統的單應用監控名額或者日志,必然要涉及整條調用鍊路所有相關應用名額的來回切換,費時費力非常困難。

通過BOS分布式鍊路跟蹤産品能夠幫助使用者迅速定位到有問題的應用和服務,協助快速解決風險。

  • 完整的應用調用拓撲關系:自動發現該服務的曆史調用,以及對所有中間件的調用,繪制整個系統調用關系的拓撲圖。
  • 快速定位不健康應用:在調用關系拓撲中,對不健康應用進行顯式辨別,便于快速發現有問題應用并進行分析。
  • 服務性能詳情:調用拓撲中的應用都可以單獨進行下鑽分析,可以從吞吐量、錯誤率、響應時間等名額出發,對應用性能進行詳細分析。
BOS分布式鍊路追蹤産品揭秘

問題分析與快速定位示意圖

應用性能優化

BOS分布式鍊路産品通過應用調用拓撲和鍊路詳情等分析能力,全方位的展示應用以及具體接口方法層面的性能資料,可以幫助使用者快速定位到具體的單個造成性能瓶頸的調用所在或者是否存在不合理的調用關系,進而幫助使用者進行應用的性能優化。

  • 調用鍊路聚合彙總:對所有的調用資訊進行聚合彙總,對各個應用的調用情況以及響應情況進行分析。
  • 關鍵路徑:快速發現整個系統調用拓撲中,關鍵應用的路徑。
  • 優化不合理調用:及時發現某些不合理的調用并進行處理,如頻繁進行資料庫操作等。
BOS分布式鍊路追蹤産品揭秘

性能優化示意圖

使用場景

洞察微服務調用拓撲

在大規模的微服務系統中,完整的鍊路調用拓撲可以提供一個全局的視角,幫助發現不同應用之間的依賴關系,實時的以端到端的方式展示微服務應用架構。

此外針對應用開發者,也可以實時展示單個應用上下遊調用關系的拓撲圖。

通過如下的服務調用拓撲圖,使用者可以獲得:

  • 全鍊路資訊展示:展示應用程式及其關聯内部、外部服務系統的響應時間、吞吐量和狀态,同時顯示了各個服務之間的互相影響。如果一項服務中斷,您可以立即看到其他服務所受到的影響。
  • 後端服務性能管理:快速、持續地監控應用性能,第一時間發現定位應用問題。
  • 實時運作狀态:通過監控黃金名額(吞吐量,響應時間, 錯誤率)、可視化的應用的性能監控描述,快速了解每個應用的運作狀态。
BOS分布式鍊路追蹤産品揭秘

服務調用拓撲圖

更進一步,對于感興趣的應用,可以檢視具體的應用性能詳情,了解應用在指定時間範圍内的性能名額資料。具體的資料涵蓋了HTTP調用、RPC調用、SQL調用、NoSQL調用、消息調用的黃金名額統計(比如吞吐量、平均響應耗時、錯誤率、滿意度等)趨勢和名額明細。

同時應用性能詳情支援基于應用 > 上下遊應用 > 接口等逐層下鑽分析,建立從底層至上層間的資料關聯資訊,進而深度分析分布式場景下影響應用性能的問題根因。若發現某個接口調用異常,可跳轉鍊路查詢界面,按照相關參數查詢鍊路。

BOS分布式鍊路追蹤産品揭秘

服務調用拓撲-應用性能詳情圖

定位異常調用與應用

服務調用的最關鍵的名額是 錯誤率 和 平均耗時,通過實時計算這兩項名額,配合上可自定義的評判标準,可以生成上述服務調用拓撲圖中部分呈現為黃色異常與紅色錯誤狀态的服務調用和應用自身。

應用評價标準

異常應用的評價是通過實時計算應用的平均接口耗時以及錯誤率實作的,使用者可以配置門檻值,一旦超過門檻值,将分别呈現為黃色異常與紅色錯誤狀态。

調用評價标準

異常調用的評判采用的是Apdex标準,Apdex全稱是Application Performance Index,是用于評估應用性能的開放标準,從使用者的角度出發,将響應時間的表現轉化為對應用性能的可量化滿意度評價。

Apdex根據響應時間以及代表使用者滿意的響應時間界限T,定義了三種性能表現:

  • 滿意:響應時間小于 T。
  • 可接受:響應時間介于 T 到 4T 之間。
  • 不可接受: 響應時間大于 4T。

将一段時間的響應時間統計出來後,便可根據下述計算公式得出Apdex指數:

Apdex指數 = (滿意數 + 0.5 * 可接受數)/ 總樣本數 。

Apdex指數大于0.7的被認為擁有較為良好的性能,低于0.7将會被标紅,提醒可能存在的性能問題。

應用性能調優

當排查到異常調用或者異常應用存在的時候,研發人員可以借助分布式鍊路追蹤服務進行性能調優。

在應用性能分析過程中,對于技術研發來說,最為關鍵的名額是吞吐量、平均響應耗時、錯誤率。是以,分布式鍊路産品設計過程中,BOS 通過聚合鍊路資料,輕松展示服務調用明細,提供分鐘級資料統計。如上述 服務調用拓撲-應用性能詳情圖 所示。

當發現平均響應耗時較高或者錯誤率較高請求時,通過點選明細最右邊一欄的實時鍊路查詢按鈕,可以跳轉到包含相關調用資訊的鍊路查詢頁面,通過對耗時的排序,可以定位到耗時較高的單條鍊路。

BOS分布式鍊路追蹤産品揭秘

鍊路查詢頁面圖

進而通過點選感興趣的調用鍊路,可以看到更為詳細的調用樹狀圖,單鍊路拓撲圖以及時序圖:

BOS分布式鍊路追蹤産品揭秘

鍊路詳情-樹狀圖

BOS分布式鍊路追蹤産品揭秘

鍊路詳情-拓撲圖

BOS分布式鍊路追蹤産品揭秘

鍊路詳情-時序圖

通過以上三種鍊路詳情展示圖,可以很友善的找到在整條鍊路中,哪些調用出現了失敗的情況,哪些調用的耗時過長需要優化。

更進一步:

  • 點選鍊路詳情:可以看到更多鍊路的細節資訊,并且可以查到相關聯的業務日志和錯誤日志。
  • 點選監控詳情:可以跳轉至BOS的應用監控頁面,查到更為詳細的應用監控名額,比如系統名額和JVM名額等。

通過鍊路、日志和監控的全方位資訊,應用的研發人員可以很友善的發現問題和瓶頸所在,并加以優化,進入 性能優化->鍊路分析->性能優化 的正循環中,最終達到滿意的性能結果。

應用接入

看到前面的鍊路分析使用場景,是不是已經很迫不及待要把應用接入到分布式鍊路追蹤系統了?

别着急,接入的方法很多樣,也很友善。

接入的核心就是如何為應用生成鍊路資料,并讓分布式鍊路追蹤系統采集到。

我們可以利用業内優秀的鍊路架構幫助應用進行鍊路改造,目前業内常用的鍊路架構有OpenTelemetry,SofaTracer,Skywalking,Zipkin與Jaeger等等,其中一些架構針對部分開發語言和部分中間件可以做到無侵入式的鍊路改造,還有一些場景需要通過相應的SDK進行鍊路能力的引入增強。

随後,BOS分布式鍊路追蹤系統可以接收應用架構主動上報上來的鍊路資料,或者通過采集應用架構列印落盤的鍊路日志檔案來收集鍊路資料。

以OpenTelemetry為例,Java應用隻要接入一個探針,無需修改任何應用代碼,即可自動生成鍊路資料,并通過RPC接口上報至BOS。

BOS分布式鍊路追蹤産品揭秘

技術内幕

BOS分布式鍊路追蹤産品揭秘

資料收集與解析

通過應用接入,BOS分布式鍊路追蹤系統會根據接入方式的不同,分别用不同的方法來接受架構生成的原始鍊路資料,比如日志采集、RPC接收或者是HTTP協定接收等等。

然後不同原始鍊路資料的格式也各不相同,是以首先需要對這些原始資料按照不同的規則進行解析,解析後将建構出與架構無關的鍊路Span資料,這些資料将被儲存至鍊路資料庫中。

資料修複

接下來,需要對鍊路資料進行修複操作,這塊修複的原因是,分布式鍊路資料是一種很特殊的資料類型,兩個應用之間的一次調用實際上會産生兩條鍊路資料,分别為用戶端Span和服務端Span,而從單個應用的角度出發,應用的視角裡不會很清楚的知道調用對端的詳細資訊,是以這兩條鍊路資料通常情況下都會缺少部分對端的資訊。

是以,分布式鍊路追蹤系統會收集鍊路調用兩端各自的Span,然後進行資料修複,借助雙方各自的資料修複出調用的完整資訊,為後續的名額和拓撲資料計算做準備。

名額計算

下一步,根據鍊路資料的不同調用類型(HTTP,RPC,SQL,NoSQL,消息等),分别進行相應的性能名額計算和聚合,并将相關名額資訊存入時序性資料庫中。

拓撲計算

接下來,由于之前已經經過了資料修複,從一個Span裡可以同時擷取到兩端的應用資訊,是以可以從應用拓撲的角度分别計算和儲存兩端的拓撲節點,以及這次調用代表的拓撲邊的相關資料。

為了從更多的角度觀測拓撲節點和拓撲邊的細節:

  • 在拓撲節點的服務名額計算過程中,會根據拓撲節點處在調用方還是服務方分别進行彙總統計。
  • 在拓撲邊的服務名額計算過程中,會根據調用類型的不同而分别進行彙總統計。

    當拓撲節點和拓撲邊的相關資料計算以後,會經過序列化最終存入相關的資料庫之中。

産品展示

至此,鍊路分析所需要的所有資料都已經被解析落盤,當使用者進行應用拓撲查詢或者單條鍊路查詢的時候,BOS分布式鍊路追蹤系統會針對不同場景查詢不同類型的資料,進行拓撲或者調用鍊的還原。其中:

  • 應用拓撲:需要先将拓撲關系繪制出來,并根據拓撲查詢時間範圍,将拓撲節點、拓撲邊的相關聯名額資料進行一定程度的降采樣,并為調用明細資訊進行名額的合并計算。
  • 鍊路詳情:需要将一條鍊路所有的Span資訊全部擷取到,緊接着根據父子關系,兄弟關系等等進行調用鍊的精确還原。在實際應用過程中,經常還會遇到某些應用因為一些原因無法接傳入連結路系統的情況,進而導緻調用出現Span部分缺失的情況,這種時候 BOS 也會根據相關Span接入方式的不同,從鍊路架構的資料生成原理出發,盡可能的排除掉這些幹擾,還原出完整的鍊路調用關系。

總結

最後,總結一下BOS分布式鍊路追蹤産品的核心特性:

  • 完全相容業内常用的各種鍊路架構,友善業務以各種形式進行接入。
  • 提供完整的應用調用拓撲關系,可以從全局的角度快速定位不健康的應用以及應用間調用。
  • 從吞吐量、錯誤率、響應時間等名額出發,提供詳細的應用性能分析。
  • 提供豐富的鍊路查詢功能,準确定位到感興趣的鍊路。
  • 對于單條鍊路,提供豐富的分析能力,通過樹狀圖,拓撲圖以及時序圖幫助發現關鍵路徑以及不合理和異常的調用。
  • 通過鍊路、監控與日志的三位一體能力,提供完整的應用可觀測能力,可以細化觀察到某一次調用相關的所有可觀測資料。

目前,BOS分布式鍊路追蹤産品已經廣泛應用在包括交通銀行,中華财險,甯波銀行,四川農信在内的多家機構,持續幫助使用者發現和解決應用故障以及性能問題。

後續我們會持續分享分布式鍊路追蹤能力持續演進過程中的落地與思考,歡迎大家提出任何意見與建議。

繼續閱讀