龍蜥系統維運聯盟：Kindling-OriginX 如何整合 DeepFlow 的資料增強網路故障的解釋力

編按：2023年，龍蜥社群正式成立系統維運聯盟，由信通院、阿里雲、中興通訊、復旦大學、清華大學、浙江大學、雲觀秋毫、乘雲數字、雲杉網路、浪潮資訊、統信軟體及聯通軟體院等12 單位共同發起。本文轉自雲觀秋毫，介紹系統運作聯盟成員 Kindling-OriginX 透過結合 DeepFlow 完備的網路資料能力，自動化產生可解釋的故障根因報告。

DeepFlow是一個開源項目，利用eBPF技術為複雜的雲端基礎架構和雲端原生應用提供高度可觀測性。透過eBPF技術，DeepFlow收集精細的鏈路追蹤資料、網路和應用效能指標，具有全鏈路覆蓋和豐富的TCP效能指標。這些功能為專業用戶和網路專家提供了強大的故障診斷和問題定位支援。

Kindling-OriginX 是一款故障根因推導產品，目標是提供給用戶一個可解釋的故障根因報告，讓用戶能夠直接了解故障根因，並附有根因的推理過程以便驗證根因的準確性。網路故障是故障當中比較難以簡單解釋的，僅僅告知用戶哪段網路有問題是不夠的，用戶需要更多指標以及圖解，才能幫助用戶更好的理解網路到底發生了什麼故障，以及發生在哪個環節。

本文介紹 Kindling-OriginX 透過結合 DeepFlow 完備的網路資料能力，自動化產生可解釋的故障根因報告。

soma-chaos 模擬網路故障

• 針對 seat-service 注入 200ms 延時的網路模擬故障。

• 接下來我們先使用 DeepFlow 來識別 200ms 的網路故障，並做出對應的 action。

人工最簡化排障流程

#步驟一：利用 Trace 系統縮小範圍

在微服務環境中，當某個介面出現效能問題時，首要步驟是利用追蹤系統檢查哪個環節導致了慢速度，並了解特定的表現情況。

使用Tracing系統，使用者可以準確定位到具體的Trace。經過分析Trace後，發現seat-service的執行時間較長，同時出現了一個長長的config-service呼叫。在此情況下，連動網路指標將有助於精確定位網路問題的根源。

步驟二：利用 DeepFlow 火焰圖確定故障發生在哪段網路

將故障代表traceid 的輸入DeepFlow 在火焰圖中，找到Trace 在網路層面的表現，然後深入分析這個火焰圖，如果對火焰圖比較了解，同時有具備網路知識的專家經驗，是能夠根據火焰圖人為分析出：這個故障應該是發生在呼叫者也就是seat-service 上，而且問題是發生了syscall 到網卡的時間段，也就是容器網路時段出了問題（和故障注入是吻合的）。

（圖/DeepFlow網路火焰圖）

步驟三：確定容器網路到底什麼網路指標異常

根據故障排查經驗，使用者需要查看 seat-service 與 config-service 的 pod 的網路指標。這時候使用者需要跳轉至 DeepFlow 的 Pod 等級的網路指標頁面。透過該頁面，使用者能夠查看出建連有 200ms 的延時突變以及 RTT 指標有突變。

（圖/DeepFlow-pod等級監控指標）

（圖/DeepFlow-pod等級監控指標）

步驟四：排除可能的干擾因素

根據經驗，宿主機的CPU 被打滿和頻寬被佔滿之時，虛擬網路也會出現丟包和時延，所以要排查當時seat-service 與config-service 所在node 的CPU 以及node 級別的頻寬，確保Node 等級資源沒有飽和。

透過 k8s 指令確認了兩個 pod 所在的 node 節點，然後去 DeepFlow 的 node 指標監控頁面查看對應指標，發現 node 的 bps、pps 等指標都在合理範圍內。

（圖/透過k8s指令找出pod所在的節點）

（圖/DeepFlow-node等級監控指標（client））

（圖/DeepFlow-node等級監控指標(server)）

由於node等級的網路指標沒有出現明顯異常，最後確定是seat-service的pod等級rtt指標異常。

人工排障總結

經過一連串的檢查過程，最終使用者是能夠排查出故障的，但是對使用者有以下要求：

• 網路知識非常豐富

• 深入理解網路火焰圖

• 熟練使用相關工具

Kindling-OriginX 如何結合 DeepFlow 指標，產生可解釋的故障報告

Kindling-OriginX 針對不同的使用者需求和使用場景，Kindling-OriginX 對 DeepFlow 的資料進行了加工呈現。

類比人工最簡化排障過程，利用 Kindling-OriginX 的排障過程如下：

自動化分析每一條Trace

針對此時的故障，自動化分析每個 Trace，並依照故障節點對所列的 Trace 進行歸集。 Travel-service 是由於級聯故障導致的，本文不重點論述級聯故障，如果有興趣可以參考微服務級聯故障該如何處理。

Review 故障節點為 seat-service 的故障根報告

故障根因結論：

對於子請求10.244.1.254:50332->10.244.5.79:15679 rtt 指標出現 200ms 左右的延遲。

故障的推理驗證

由於Kindling-OriginX 已經辨識出是seat-service 呼叫config-service 的網路有問題，所以不用完全把DeepFlow 的火焰圖所有資料呈現給用戶，只需要與DeepFlow 對接，只要拿到seat-service 調用config-service 那段網路呼叫的相關資料即可。

利用 DeepFlow 的seat-service 呼叫 config-service 資料自動分析出了客戶端 pod 的容器網路出現了 201ms 的延遲。

Kindling-OriginX 會模擬專家分析經驗，進一步關聯 DeepFlow 的重傳指標與RTT指標，從而確定到底是什麼原因導致了 seat-service 呼叫 config-service 出現了延遲的現象。

Kindling-OriginX 也會整合node的CPU利用率以及頻寬指標，排除乾擾因素。

Kindling-OriginX 將整個故障推理都在一頁報告中完成，並且每個資料來源都是可信可查的。

總結

Kindling-OriginX 與 DeepFlow 都使用了 eBPF 技術，立求在不同的場景中為不同需求的用戶提供靈活高效解決方案，也期待未來能看到國內有更多能力互補產品的出現。

DeepFlow 能提供非常完整的全鏈路網路基礎數據，能夠讓雲端原生應用具有深度可觀測性，對於排查網路問題非常有用。

Kindling-OriginX 是利用 eBPF 來擷取排障北極星指標、AI 演算法和專家經驗來建構故障推理引擎，給予使用者可解釋的根因報告。

—— 完 ——

以上是龍蜥系統維運聯盟：Kindling-OriginX 如何整合 DeepFlow 的資料增強網路故障的解釋力的詳細內容。更多資訊請關注PHP中文網其他相關文章！