端到端調用鏈監測實施案例

IT那活兒發布于2023-01-11 13:19 / 3328人閱讀

端到端調用鏈監測實施案例

點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！

應用背景

隨著越來越多的企業將業務系統上云，實現云化部署，將后端功能沉淀和分拆成多個能力服務中心，較好地規避了煙囪式建設方式，提升了能力復用，節省了項目和新業務需求開發成本。

但同時，相比傳統架構：

一方面，大幅度增加分布式程度、調用層次、依賴復雜度，調用隨機分發，大幅度的提升了性能問題發現和排查定位難度；

另一方面，由于生產系統在高可用中快速切換隔離了故障源，導致故障源并不容易被迅速發現及定位，特別是當前的系統環境中大量的應用、主機、網絡、中間件、數據組件等交織如網，應用間網狀的調用關系導致各物理節點的故障源對于應用及業務的真實影響較難評估。

圖片來源于網絡

如何快速發現問題、排查影響范圍，快速定位問題成為新的技術挑戰。

為了能直觀的體現包含系統上下游依賴信息的系統模塊關系圖譜，并實現問題發生初期的快速故障源定位及影響分析，我們構建了端到端調用鏈監控平臺，以實現多維協同運維，具體包括：

系統監控清晰透明：構建包含各應用模塊上下游調用依賴關系（應用包括：業務應用、中間件、數據庫等）、應用模塊主機網絡之間相互部署依賴關系的多維度關系圖譜監控大屏，實現系統從黑盒狀態到透明狀態的轉變。
故障定位快速智能：基于動態基線對關系圖譜中各模塊、節點進行異常檢測，分析各系統模塊的問題情況，實現故障分鐘級實時發現。
運維分析立體多維：通過直觀可視化的方式展示應用、主機、數據庫等異常，方便運維人員多維度、立體式對故障影響面進行評估。

建設實施方案

建設端到端調用鏈監控平臺，打通各業務支撐子系統，并依托分布式調用鏈跟蹤技術打造跨電渠、CRM、BOSS多個核心子系統的分布式全程調用鏈路，構建立體式多維協同的故障智能檢測和可視化快速定位能力，解決龐大的分布式系統架構下的調用鏈路難跟蹤、發生故障或問題較難快速定位和跟蹤的難題。

端到端調用鏈監控平臺架構通過適配各應用系統的底層框架，實現端到端鏈路數據埋點、數據生成、數據采集，運維指標生成、異常檢測及告警。并融合可視化能力、實時計算能力、動態基線算法能力，在業務系統出現問題時，快速通過調用鏈，結合可視化，快速呈現系統異常、定位排查。

端到端調用鏈監控平臺架構圖

端到端調用鏈監控平臺的多維度可視化監控大屏基于采集獲取到的應用模塊之間的調用關系進行動態構建。包含上下游應用或中間件、數據組件等模塊調用關系，也包括應用模塊與主機網絡之間相互部署依賴關系。

系統監測可視化大屏展示如下：

每個圖標代表一個應用模塊集群，每個應用模塊直接的帶箭頭的連線代表調用關系，當圖標變紅色時代表該模塊出現了異常，可以通過下鉆進一步定位診斷。

系統可視化拓撲大屏

系統拓撲監控可以通過應用集群的縱向下鉆能力，體現從應用集群到應用實例再到物理節點的縱深關系，快速對發生異常的應用集群做下鉆分析，進入到應用集群的物理部署層，并將原子狀態的故障發生點予以告警展現，提示運維人員跟進處理。

圍繞上述“立體式多維協同的故障檢測和可視化快速定位能力”建設思路，一方面采用分布式調用鏈跟蹤技術；另一方面構建關系圖譜模型、多維異常指標智能生成、融合基線檢測算法，助力故障檢測和可視化快速定位能力構建。

1. 分布式調用鏈跟蹤

采用分布式調用鏈跟蹤技術方案解決跨節點事務端到端跟蹤難點，從用戶側開始的調用一直追溯到調用處理完畢回調結束，調用鏈中的每個環節都進行統計監控，實現分布式事務全生命周期調用性能管理，可視化分布式事務調用棧。

分布式事務跟蹤技術通過在遠程調用發送消息時添加應用級別的標簽作為消息之間的關聯。

例如，在HTTP請求中的HTTP header中為消息添加一個標簽信息并使用這個標簽跟蹤消息。在調用的header中添加應用級別標簽數據以便在遠程調用中跟蹤分布式事務的全鏈路。標簽數據由多個key組成，定義為TraceId。在標簽中加入主機、網絡IP字段，就能將主機、網絡IP信息進行收集上報。

消息跟蹤數據結構由Span, Trace, 和 TraceId組成。

下圖描述TraceId的行為，在4個節點之間執行了3次的RPC調用：

調用鏈跟蹤示例

在上圖中，TransactionId (TxId)作為一條調用鏈的唯一標識ID，全局唯一，體現了三次不同的RPC作為單個事務被相互關聯。通過SpanId 和 ParentSpanId (pSpanId)來標識上下游環節關系。

使用TxId，可以發現關聯到n個Span，并使用SpanId和ParentSpanId將這n個span排列為繼承樹結構，這樣就實現了調用鏈路的串聯。

在這個消息結構體中加入更多的記錄信息：比如業務編碼、主機ip、入參文本、調用請求返回文本、系統錯誤堆棧文本等，就能獲得非常豐富的調用鏈信息，能更加方便運維。

2. 鏈路數據輸出要求

為了能夠分析出端到端的調用層次關系，我們對業務系統的鏈路日志數據輸出做了以下的規范要求：

基于業務鏈做應用拓撲需求，和應用廠商側協商確定的業務鏈數據格式需求規范，每個環節可以吐出其上游的調用發起信息，以及當前環節向下游調用發起的信息，每一筆業務鏈日志中應包含的數據信息，包括但不限于以下內容：

定義單次業務辦理所對應的業務編碼
每個業務都應有業務編碼，用于識別該筆業務具體是做什么的。
定義單次業務辦理的用戶編碼
定義辦理業務的用戶，如手機號碼、用戶編碼、或其他業務的辦理對象編碼。
定義單次業務辦理的辦理員工編碼
辦理業務的員工編碼，用于業務發展統計分析。
定義單次業務辦理的辦理渠道編碼
辦理業務的渠道編碼，用于業務發展統計分析。
定義單次業務辦理中單次系統交互的開始時間戳
業務辦理的時間戳信息，用于單位時間內的業務統計分析，以及實時計算時時間窗口的判斷。
定義串聯單次業務辦理的唯一流水
每筆業務需定義唯一流水，使用這個流水號來串聯一次業務辦理的多次交互動作。
定義串聯單次業務辦理中單次系統交互的唯一流水
每筆業務中一次交互動作的唯一流水，用于串聯這次交互動作在多個不同應用之間的流轉調用。
定義每個應用的應用節點編碼
每個應用實例的唯一編碼，用于識別該應用實例，當系統發生異常時，應用節點用于判斷系統異常的發生位置。
定義每個應用的應用節點ip和port
每個應用實例的所屬主機ip和當前應用實例的端口，用于關聯主機異常信息做異常影響分析。
定義每個應用節點所屬應用集群的應用類型
應用集群的類型可用于構建拓撲圖時劃分層級結構，繪制清晰的系統架構。
定義每個進程所屬應用集群的名稱
應用集群名稱用于在構建拓撲圖時展示當前應用的名稱。
定義每次系統交互中每個環節的服務類型
系統交互中的一個環節可以是一次函數調用、可以是一次接口調用，還可以是一次數據庫訪問。該字段應定義一個環節的服務的類型。
定義每次系統交互中每個環節的名稱
系統交互中的環節名稱可以是接口名、函數名、服務名等，用于構建業務鏈時定義該動作。
定義每次系統交互中每個環節的輸入參數
接口、函數、服務的入參信息。
定義每次系統交互中每個環節的輸出
接口、函數、服務的返回信息。
定義每次系統交互中每個環節的耗時
接口、函數、服務、數據庫訪問的耗時。
定義每次系統交互中每個環節是否失敗及失敗類型
用于判斷該環節是否失敗，以及劃分失敗的類型，如系統層原因的失敗，或業務規則的失敗等。
定義每次系統交互中每個環節的失敗異常信息
用于記錄失敗時的異常信息。
定義每次系統交互中每個環節的上級環節應用名稱（跨應用調用時）
記錄調用該環節代碼的上級環節應用名稱。
定義每次系統交互中每個環節的上級環節的應用節點編碼（跨應用調用時）
記錄調用該環節代碼的上級環節應用節點編碼。
定義每次系統交互中每個環節的上級環節的ip和port（跨應用調用時）
記錄調用該環節代碼的上級環節應用節點ip和port。
定義每次系統交互中每個環節向下調用的目標應用名稱（跨應用調用時）
記錄該環節向下游發起調用時的目標應用名稱。
定義每次系統交互中每個環節向下調用的目標地址（跨應用調用時）
記錄該環節向下游發起調用時的目標應用地址。
定義每次系統交互中每個環節向下調用的目標數據庫名稱（數據庫類調用時）
記錄該環節向下游發起調用時的目標數據庫名稱。
定義每次系統交互中每個環節向下調用的目標數據庫地址（數據庫類調用時）
記錄該環節向下游發起調用時的目標數據庫地址。
定義系統交互中入口環節的url地址（前臺交互）
記錄系統交互入口環節的url地址。

3. 建立關聯圖譜模型

可視化監控大屏是基于關聯圖譜模型進行自動化繪制和每天更新。

基于每天采集到的端到端鏈路鏈路數據，構建包含各應用模塊上下游調用依賴關系（包括業務應用對數據組件的訪問）、應用模塊主機網絡之間相互部署依賴關系。

一次復雜業務的從WEB前臺受理到最后為用戶真正辦理成功，在系統的調用鏈是一個跨多系統模塊，分布式、異步開通的長流程調用。在沒有端到端跟蹤技術前，這樣一次調用鏈路中各模塊之間的交互、調用依賴是一個黑盒，對系統做健康檢測需要打開這個系統黑盒。在當前復雜的分布式系統的拓撲結構中，某次調用經過了哪個應用節點，該節點目前是調度部署在哪臺虛擬機上，遠端調用IP、端口是多少都較難關聯。而這些信息恰好是運維分析需要的信息。

使用端到端調用鏈路跟蹤技術，跟蹤這些模塊之間的每筆調用流，并使用異步跟蹤技術把異步調用還原合并到調用鏈中，得到完整的調用鏈路。

完整的調用鏈路由一個個鏈路環節日志組成，每個鏈路環節日志包含基礎的鏈路環節信息、當前環節的程序調用請求參數和返回報文，兩個鏈路環節中間捕獲的應用主動輸出的日志（包含程序錯誤堆棧）、主機、網絡數據等。日志中很多數據為長文本、半結構化數據，所以需要先做分詞處理來提取。

在這個實施案例中，我們基于flink實時計算來作為分詞及鏈路上下游依賴關系發現模塊的承載平臺，執行以下的挖掘處理步驟，來構建上下游依賴信息的關系圖譜自發現模型。

STEP1-明確可用的調用鏈環節數據：首先梳理、定義鏈路環節中和上下游依賴關系相關的信息關鍵字，通過流式處理篩選出滿足關鍵字預選規則的鏈路環節日志，認為此日志為一個可用的調用鏈環節數據，將其提取出來。
STEP2-挖掘可調用鏈上下游依賴關系：從第一步得到的調用鏈環節數據中挖掘出此次調用鏈環節屬于哪個調用鏈，歸屬哪個業務調用，該調用鏈環節目前在哪個應用模塊節點（應用模塊節點包括：業務應用、redis、memcache、數據庫等）上、上級應用節點的信息、下級應用節點信息、執行動作信息（接口或函數，或sql語句），做去重后生成為一個該環節的上下游依賴關系鍵。上下游依賴關系鍵包含了該鏈路環節在整個調用流程的上下游關系。
STEP3-分析其立體式主機網絡部署關系：繼續分析調用鏈環節數據，挖掘出發生此次調用鏈環節的應用節點、該應用節點在調用發生當時部署在哪臺主機、哪個網絡IP的立體式部署關系鍵，此關系鍵命名為應用主機網絡的立體式部署關系鍵。
STEP4-生成上下游依賴運維知識圖譜：以每半天為統計周期，通過分析關聯上下游依賴關系鍵，去重，以每個業務編碼為根節點，自動生成一個完整的基于業務的調用關系鏈路，得出上下游依賴運維知識圖譜，通過分析關聯應用主機網絡的立體式部署關系鍵，生成出縱向的立體式的運維知識圖譜，構建出哪些應用模塊部署在哪些物理中心的哪些主機上，相互之間的網絡調用IP關系，以及每臺主機上部署了多少個應用實例等信息。
模型更新頻度：每半天做一次動態更新。

我們在端到端調用鏈監控平臺中還納管了數據庫集群的內部端到端鏈路管理，實現了數據庫的異常監測和問題快速診斷能力。對于數據庫模塊，多帶帶建立了專門的端到端數據庫監控大屏，用來呈現其內部的數據流向及關鍵組件運行狀態。

大屏包含數據庫節點、ADG節點、心跳延時節點、ADG延時節點四類節點、對性能異常、數據庫健康度進行異常檢測，大屏展示健康節點數及異常節點數、展示每套庫對應的數據量、總節點數、健康節點數及異常節點數。

基于上述大屏及下鉆后的副屏展現，能實現對運維知識圖譜的立體化、可視化展現，結合了業務、應用、網絡、主機、中間件、數據庫等各維度的信息集成展現，再結合異常檢測、健康度模型評分，提供運維人員快速發現異常，并定位診斷故障的能力。

4. 構建檢測指標體系

在完成系統架構的大屏展現和數據庫、物理部署視圖、業務流程視圖等各類專題副屏的基礎上，為了第一時間獲得系統運行的實際狀態，需要通過業務鏈日志數據實時提取各業務、應用、實例、主機、網絡等系統組成部分的各類細項指標，也需從其他系統進行數據采集，用于構建算法分析系統運行狀態的自動異常檢測能力。

因此一套靈活、準確、高效的數據采集、指標生成體系是必不可少的。

同樣基于flume、flink開源計算框架搭建了實時指標庫。由生產系統生成的調用鏈數據通過分詞處理形成半結構化數據，再對其中的關鍵字段做規則統計、數值計算等處理形成指標數據，指標還可配置告警，并將告警再做復合指標計算，完整處理過程如下圖如所示：

業務鏈日志生成指標、處理流程示意圖

其中在指標生成邏輯上，融合了數值計算和邏輯判斷兩類規則體系，如下所示：

通過以上的數值計算及邏輯計算規則，對業務鏈日志數據做處理自由配置生成不同的關鍵指標。

這些指標數據集成在端到端可視化監控大屏中，也被各系統健康度模型所使用。系統出現告警后，運維人員往往需要各類細項指標幫助其進行分析，幫助快速做一些問題診斷，靈活高效的數據指標生成體系能幫助運維人員快速采集、展現他們關注的指標，運維人員可通過這些指標快速了解當前系統的運行負載情況，以及各業務、應用集群、網絡、數據庫等組件的運行狀態。

應用效果

通過以上模型構建出關聯圖譜后，并基于該圖譜和指標體系實現了對系統各維度（包含應用、主機、數據庫、中間件、網絡IP等信息）的異常監測和問題快速診斷，并結合異常檢測、健康度模型評分，提供運維人員快速發現異常，并定位診斷故障的能力。

同時，通過自動化繪制可視化系統拓撲監控大屏直觀展現系統運行時的各模塊的狀態。

END

本文作者：李秋霖

本文來源：IT那活兒（上海新炬王翦團隊）

云服務器 GPU云服務器端到端端到端測試 webrtc端到端通信 webrtc端到端延時

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129493.html

何勉：第一性原理和精益敏捷的規模化實施

摘要：摘要什么是第一性原理第一性原理如何指導我們的精益敏捷開發阿里資深解決方案架構師暢銷書精益產品開發原則方法與實施作者何勉，結合實踐案例，詳述第一性原理和精益敏捷的規模化實施。前言今天分享的題目是第一性原理和精益敏捷的規模化實施。摘要：什么是第一性原理？第一性原理如何指導我們的精益敏捷開發？阿里資深解決方案架構師、暢銷書《精益產品開發：原則、方法與實施》作者何勉，結合實踐案例，詳述第一...

233jl 2019-05-29 17:02 評論0 收藏0
云計算時代的網絡進階

摘要：李耀宗強調，要從根本上支持企業數字化轉型，需要從基礎設施和應用兩個方面提高對復雜網絡環境的管理監測能力，增強企業使用網絡的安全性復雜性，從而才能真正消除企業云優先戰略當中的盲點和障礙。互聯網改變了傳統PC時代IT架構的技術邏輯，帶來了無限的存儲空間和無窮的計算能力，同時，又借助云計算徹底顛覆了以往商業模式上的所有鐵律。有89％的企業計劃采用數字優先的戰略；超過85％的人認為，云是數字化轉型的...

gecko23 2019-04-29 15:40 評論0 收藏0
TOP100summit：【分享實錄-封宇】58到家多端消息整合之路

摘要：封宇到家架構師。主要負責到家消息系統以及門戶等公司戰略級產品研發。消息服務器收到拉取離線消息請求，表明端已經收到之前的數據。統一消息推送通道，整合個推米推微信短信等消息推送方式，盡最大可能確保消息送達用戶。本篇文章內容來自2016年TOP100summit 58到家架構師封宇的案例分享。編輯：Cynthia2017年11月9-12日北京國家會議中心第六屆TOP100summit，留言...

googollee 2019-06-24 17:53 評論0 收藏0
創新賦能，筑基未來 ——“2021中國IPv6創新發展大會”在京召開

摘要：為貫徹落實關于加快推進互聯網協議第六版規模部署和應用工作的通知部署要求，促進技術產業網絡應用安全協同發展，搭建行業交流合作平臺，年月日日，以創新賦能，筑基未來為主題的中國創新發展大會在北京舉行。為貫徹落實《關于加快推進互聯網協議第六版（IPv6）規模部署和應用工作的通知》部署要求，促進I...

wuyangchun 2021-10-14 09:42 評論0 收藏0
前端進階之路: 前端架構設計(3) - 測試核心

摘要：而測試驅動開發技術并不只是單純的測試工作。需求向來就是軟件開發過程中感覺最不好明確描述易變的東西。這里說的需求不只是指用戶的需求，還包括對代碼可能很多人和我一樣, 首次聽到前端架構這個詞, 第一反應是: 前端還有架構這一說呢? 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備受重視, 早在開發工作啟動之前, 他們就被邀請加入到項目中, 而且他們會跟客戶討論即將建成的平臺的...

Karuru 2019-08-01 18:16 評論0 收藏0
前端進階之路: 前端架構設計(3) - 測試核心

摘要：而測試驅動開發技術并不只是單純的測試工作。需求向來就是軟件開發過程中感覺最不好明確描述易變的東西。這里說的需求不只是指用戶的需求，還包括對代碼可能很多人和我一樣, 首次聽到前端架構這個詞, 第一反應是: 前端還有架構這一說呢? 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備受重視, 早在開發工作啟動之前, 他們就被邀請加入到項目中, 而且他們會跟客戶討論即將建成的平臺的...

宋華 2019-08-22 11:22 評論0 收藏0