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

DeepFlow 是基於 eBPF 的可觀測性開源項目，旨在為複雜的雲基礎設施及雲原生應用提供深度可觀測性。DeepFlow 基於 eBPF 採集了精細的鏈路追蹤數據和網絡、應用性能指標，其在網絡路徑上的全鏈路覆蓋能力和豐富的 TCP 性能指標能夠為專業用户和網絡領域專家提供充足的排障定界支撐。

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

本文介紹 Kindling-OriginX 通過結合 DeepFlow 完備的網絡數據能力，自動化生成可解釋的故障根因報告。

soma-chaos 模擬網絡故障

• 針對 seat-service 注入 200ms 延時的網絡模擬故障。
• 接下來我們先使用 DeepFlow 來識別 200ms 的網絡故障，並做出相應的 action。

人工最簡化排障過程

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

在微服務場景中，某個接口突然慢了，排障的第一步驟應該是看 Tracing 系統，找到 Trace 慢在哪個環節，以及慢的具體表現是什麼。

用户通過 Tracing 系統能夠找到具體的 Trace，通過分析 Trace 能夠發現 seat-service 執行時間很長，同時出現了一條非常長的 config-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 算法和專家經驗構建故障推理引擎，給用户提供可解釋的根因報告。

—— 完 ——