中國工商銀行基於eBPF技術的雲原生可觀測圖譜探索與實踐

作者 | 中國工商銀行金融科技研究院

在網際網路金融時代，各大銀行業務量呈爆發性增長態勢，業務模式更新迭代更加頻繁，傳統的IT架構越來越無法應對新業務形態所帶來的巨大沖擊與挑戰。雲原生相關技術使業務應用呈現微服務眾多、多語言開發、多通訊協議等典型特徵，呼叫鏈路日益複雜，監控資料爆發性增長，傳統監控方式已無法適應雲原生場景。

在這個背景下，中國工商銀行積極開展雲原生可觀測圖譜的探索和實踐，針對可觀測體系中的痛難點，透過深入研究核心新技術，進一步完善雲原生技術版圖。

業界雲原生可觀測體系痛點

中國工商銀行早期基於業界對可觀測性“三大支柱”（監控指標（Metrics）、日誌（Logging）和鏈路（Tracing））的定義（如圖1所示），建設了雲監控、日誌中心和全息監控等運維支撐平臺，初步構建了可觀測體系，支撐雲上應用監控報警和分析診斷能力。隨著運維架構轉型，開發及運維部門對節點網路拓撲、監控指標、故障定位、效能調優等方面提出了更高的要求。為此，中國工商銀行對業界雲原生可觀測性相關前沿技術進行了深入探索與研究。

圖1 可觀測三大支柱

雲原生基金會的專案全景圖（CNCF Landscape）根據專案特點與價值，將提供可觀測效能力的專案分為了監控（Monitoring）、追蹤（Tracing）、日誌（Logging）三類（如圖2所示）。

圖2 CNCF Landscape

利用這些產品的組合，我們可以比較快速地搭建一個可觀測性系統。但是從業界實踐來看，這樣組裝的系統普遍存在兩大類痛點：

缺乏全域性性的系統和網路拓撲關係：雲原生分散式網路相較於傳統網路，應用節點間網路訪問過程經過多層的對映轉化後，網路拓撲關係更加複雜，傳統監控工具鏈缺乏以容器、虛機、負載均衡器等系統節點為維度的網路呼叫鏈路監控拓撲資料，並且未將抓取的網路資訊與Kubernetes資源資訊結合，無法呈現應用容器間、網路關鍵元件的網路拓撲，無法形成有效的可觀測性圖譜。

資料採集方式不具備普適性且核心態指標採集能力不足：傳統的資料採集方式通常有兩種，一是採用SDK整合的方式，隨應用版本部署；二是採用Agent的方式，採集特定埋點的資料指標。但是基於這兩種方式實現的節點拓撲關係，都依賴應用方進行適配改造，埋點的資料採集又侷限於特定語言和技術棧。而在雲原生環境中，多語言應用、不同通訊協議共存的情況下，存在適配工作量極大、應用感知明顯的問題。此外，當前指標採集方面還普遍缺失對部分核心資源的細粒度監控能力，影響對問題的深入分析和調優。

可觀測圖譜的技術選型

要解決容器場景下的系統層網路鏈路拓撲缺失和核心資源監控不完善的問題，可觀測性系統必須設法獲取到相關資源的統計資訊。但核心透過檔案系統或系統呼叫暴露出的資訊有限，單純從使用者態切入無法抓取這些資訊，只有從核心本身呼叫的過程中獲取呼叫資訊才可以補足相關能力。具體而言，即需要對應的核心Tracepoint或者函式執行hook呼叫抓取相關的資訊，並上報到使用者態監控程式中。這樣的核心技術選型很少，從調研結果來看，目前只有兩種技術能達成上述目標，一是核心模組程式設計技術，二是eBPF技術。

對於核心模組程式設計技術而言，獲取核心資料需透過在對應的跟蹤點（Tracepoint）或者系統函式呼叫時執行鉤子（Hook）操作來抓取相關資訊，並透過netlink套接字、sysfs（/sys）、sysctl（/proc/sys）或procfs（/proc）等方式與監控程序進行通訊並上傳採集的資料。對於普通開發，核心模組程式設計技術難度較大，且極易造成系統穩定性問題。

eBPF（extended Berkeley Packet Filter）是一種能夠在核心執行沙箱程式的技術，提供了一套在核心事件和使用者程式事件發生時安全注入程式碼的機制，使得非核心開發人員也可以對核心進行控制。隨著核心的發展，eBPF逐步從最初的資料包過濾擴充套件到了網路、核心、安全、跟蹤等領域，並且它的功能特性還在快速發展中。早期的BPF被稱為經典BPF（簡稱cBPF），正是這種功能擴充套件使得現在的BPF被稱為擴充套件BPF（簡稱eBPF）。相對來說，它是一種安全高效的核心技術，它的出現本質上是為了解決核心迭代速度慢和系統需求快速變化的矛盾，在對核心無侵入的前提下，往核心中動態地插入一段自己的程式碼，實現自定義監控及跟蹤能力，極大地降低了使用者獲取核心態豐富觀測指標的門檻（如圖3所示）

圖3 eBPF技術初印象

核心模組程式設計技術和eBPF技術的詳細對比（如表1所示）：

表1 核心模組程式設計技術與eBPF技術對比

由此可見，利用eBPF技術進行核心開發相比核心模組程式設計技術擁有諸多優勢，包括更嚴格的安全檢查、更穩定的API、較高的核心開發能力、更優的資料結構與通訊效能以及支援平滑升級等。同時，各大網際網路公司均採用eBPF技術在可觀測方面進行了實踐，如阿里雲提出了一種立足於容器介面和底層作業系統，向上關聯應用效能監測的可觀測性解決思路，透過 eBPF 技術無侵入地採集多語言、多網路協議的各項指標，實現了一站式可觀測性平臺；位元組跳動透過核心的eBPF採集機制獲取基於連線層面細粒度的核心網路監控指標，為多種運維場景提供支援。

綜合考慮技術優勢、發展趨勢等多個方面，最終選擇基於eBPF技術進行核心相關的可觀測功能開發，彌補當前網路拓撲和核心資源監控能力的不足，完善雲原

生場景下的可觀測圖譜。

基於eBPF技術的雲原生圖譜的實踐與應用

在容器化場景下，需要採集的核心資料種類多樣，為了更好地透過eBPF提升對系統節點間網路呼叫和核心資源的雲原生監控能力，我們引入了eBPF探針無侵入式地部署在宿主機上採集相關係統呼叫資訊及應用間互訪的網路通訊報文，透過關聯容器元資料資訊後進行資料聚合壓縮入庫，並以此構建以雲上拓撲自動發現為入口的可觀測圖譜，支援以節點系統網路效能指標分析為核心的一體化監控能力。

中國工商銀行可觀測圖譜可以分為：核心態指標採集、網路拓撲分析、雲上可觀測圖譜三部分（如圖4所示）：

圖4 eBPF可觀測圖譜架構

核心態指標採集：在宿主機部署eBPF探針實時採集雲上應用訪問資料，結合容器元資料，提供雲上應用東西向訪問關係的原始資料以及網路通訊報文。

網路拓撲分析：負責分析處理節點之間的呼叫關係，系統呼叫分析模組則負責處理應用系統呼叫的分類、聚合與資訊關聯。

雲上可觀測圖譜：提供面向業務和運維場景的視覺化分析能力，以雲上拓撲發現為入口提供面向應用和運維場景的視覺化分析能力，支援聯動全息監控、雲監控以及日誌中心進行關聯分析，形成雲原生可觀測圖譜。

1、核心態指標採集

將eBPF探針透過daemonset的形式無侵入式地部署在宿主機上，負責採集容器網路報文、系統呼叫、資源使用詳情資訊，同時從master獲取容器關聯資訊。（如圖5所示）

① 負載業務間的網路資訊採集：eBPF探針採集不同網路環境下的網路通訊報文等資料，以支援分析並展示負載間網路通訊關係鏈與通訊情況，包括頻寬、TPS、平均響應時間、建聯失敗率、錯誤率等。

②負載的系統呼叫與資源監控的採集：高資源消耗系統呼叫、異常卡死系統呼叫；使用者態與核心態資源使用情況的採集與展示，例如cpu、記憶體、磁碟io、半連線數、全連線數、頁錯誤、檔案控制代碼使用量、SWAP記憶體使用量、inodes使用量及可用量等。

③負載的容器元資料採集：eBPF探針透過叢集master獲取叢集以及容器元資料資訊，對相關資料進行過濾、填充、採集、收集。

圖 5核心態指標採集

2、網路呼叫分析

接收eBPF探針採集的指標資料，採用分類聚合演算法與Kubernetes元資料進行關聯分析、聚合儲存，形成完整的節點間呼叫網路拓撲關係資料，同時為規則匹配報警提供支撐（如圖6所示）。

圖6 網路呼叫分析

3、雲上可觀測圖譜

基於核心態指標採集和節點間呼叫網路拓撲分析的入庫資料，構建面向使用者的可觀測圖譜，具備豐富的系統呼叫指標及網路效能指標關聯查詢能力，面向一線問題支援人員和開發人員，提供了以下常見應用場景：

（1）應用拓撲感知

在當前分散式服務的架構下，發生問題後進行分析定位是一個非常複雜的過程，不僅要求問題分析人員對全域性應用有大致瞭解，還需熟知各個應用的特性、呼叫關係、部署方式。而應用拓撲感知（如圖7所示）則提供了一個非常強大的功能：透過無侵入式採集的資料建立節點間全域性的呼叫拓撲關係，在異常應用定位時，可以讓問題一線人員非常快速的感知存在網路問題的節點。

圖7 全域性應用拓撲感知

（2）鏈路追蹤分析

區別於傳統的分散式追蹤，基於eBPF的鏈路追蹤不止能跟蹤某次呼叫，還具有無入侵、語言框架無關的特性，請求如果包含了分散式追蹤TraceID，也能自動識別，方便聯動分散式監控平臺進行排查。對某次請求來說，可以精確看到接收、處理、迴應、耗時的資料，方便問題排查人員從問題節點定位到問題介面，從而進一步輔助問題的解決。（如圖8所示）。

圖8 單次請求資訊

（3）網路效能監測

透過監測HTTP請求、平均響應時間、建鏈失敗率、全連線半連線佇列等網路指標輔助定位節點及鏈路訪問連通性或效能問題。（如圖9所示）。

圖9 網路效能監測

（4）黃金指標分析

黃金指標是谷歌針對大量分散式監控實踐的經驗總結，4個黃金指標可以在服務級別幫助衡量終端使用者體驗、服務終端、業務影響層面的問題。可觀測平臺層支援請求數、響應時間、錯誤率、慢呼叫情況，整體反映應用健康狀態，快速評估故障影響，節約故障定位時間（如圖10所示）。

圖10 黃金指標-平均響應時間

（5）上下游關聯分析

在現有的雲原生環境中，應用間的拓撲非常複雜，除了提供全域性的拓撲感知，快速定位問題節點後，對於問題分析人員來說，如何在具體問題節點儘可能收集更多的資訊變成了關鍵所在。可觀測平臺不僅可以高亮顯示問題節點的上下游（如圖11所示），還關聯了告警資訊、黃金指標、Kubernetes元資訊等，在一個頁面就可以提供問題分析人員多維度的展示，有助於加速問題排查。

圖11 高亮顯示上下游

（6）規則告警與壓縮

對於一個可觀測平臺來說，及時可靠的告警是發現問題“第一現場”最重要的功能，平臺提供了預設模板的告警規則設定，支援透過選擇告警檢測物件、配置觸發條件、設定告警內容和通知人員三步設定。告警檢測方面，平臺支援Pod、節點、元件、工作負載、應用等五層豐富指標的告警，同時支援透過對指標進行邏輯運算來完成告警配置。告警規則配置方面，平臺已經預設了模板，用自然化語言的方式，方便監控人員個性化的配置。最終經過壓縮上報，精細化告警傳送，

減少一線處理人員的告警處理數量。

未來展望

中國工商銀行將繼續深入推進eBPF技術研究工作，積極探索雲原生可觀測性最佳實踐，將雲原生可觀測圖譜打造成為開發及運維人員面對系統異常時進行問題定位、分析、系統調優的首選工具。隨著eBPF技術的應用場景被不斷挖掘，業界湧現的各類開源產品已經覆蓋安全、網路、跟蹤與效能分析、觀測與監控等領域。中國工商銀行將持續關注業界eBPF技術及開源社群發展動態，進一步拓展eBPF技術在其它領域的能力並挖掘行內的落地場景。