編集者注: 2023 年、Dragon Lizard コミュニティは、情報通信技術アカデミー、Alibaba Cloud、ZTE、復旦大学、清華大学、浙江大学、雲関秋豪、 Chengyun Digital、Yunshan ネットワーク、Inspur Information、Tongxin Software、China Unicom Software Institute を含む 12 団体が共催しました。この記事は Yun Guan Qiu Hao からの転載であり、DeepFlow の完全なネットワーク データ機能を組み合わせることにより、説明可能な障害根本原因レポートを自動的に生成する System Operation and Maintenance Alliance のメンバーである Kindling-OriginX を紹介します。
DeepFlow は、eBPF テクノロジーを活用して、複雑なクラウド インフラストラクチャとクラウド ネイティブ アプリケーションに高い可観測性を提供するオープン ソース プロジェクトです。 eBPF テクノロジーを通じて、DeepFlow は、完全なリンク カバレッジと豊富な TCP パフォーマンス インジケーターを使用して、詳細なリンク トラッキング データ、ネットワークおよびアプリケーションのパフォーマンス インジケーターを収集します。これらの機能は、専門ユーザーやネットワーク専門家に強力なトラブルシューティングと問題位置のサポートを提供します。
Kindling-OriginX は、障害の根本原因を導出する製品です。目的は、ユーザーが障害の根本原因を直接理解できるようにする、解釈可能な障害の根本原因レポートと、根本原因を検証するための根本原因推論プロセスを提供することです。 。 正確さ。ネットワーク障害を簡単に説明するのは困難です。どのネットワーク セグメントに問題があるかをユーザーに伝えるだけでは十分ではありません。ネットワーク上でどのような障害が発生し、どこで発生したかをユーザーがよりよく理解できるように、より多くのインジケーターや図が必要です。
この記事では、DeepFlow の完全なネットワーク データ機能を組み合わせて、解釈可能な障害根本原因レポートを自動的に生成する Kindling-OriginX を紹介します。
200ms 遅延ネットワーク シミュレーション障害を座席サービスに挿入します。
次に、まず DeepFlow を使用して 200 ミリ秒のネットワーク障害を特定し、対応するアクションを実行します。
#ステップ 1: トレース システムを使用して範囲を絞り込む
マイクロサービス環境では、インターフェイスでパフォーマンスの問題が発生した場合、最初のステップは追跡システムを使用して、どのリンクが速度低下の原因となっているかを確認し、特定のパフォーマンスを理解することです。
トレース システムを使用すると、ユーザーは特定のトレースを正確に見つけることができます。トレースを分析した結果、seat-service の実行時間が長く、同時に長時間の config-service 呼び出しが発生していることが判明しました。この場合、リンクされたネットワーク インジケーターは、ネットワークの問題の原因を特定するのに役立ちます。
ステップ 2: DeepFlow フレーム グラフを使用して、障害が発生したネットワーク セグメントを特定します
フレーム グラフの DeepFlow に障害代表のトレース ID を入力し、ネットワーク レベルでのトレースのパフォーマンスを確認し、フレーム グラフを詳細に分析します。フレーム グラフをよく理解し、ネットワークの知識に関する専門的な経験がある場合フレーム グラフは次のことを手動で分析できます。この障害は呼び出し側 (シート サービス) で発生するはずであり、問題はシステムコールがネットワーク カードに送信された期間中に発生しました。つまり、コンテナネットワーク期間の問題 (これはフォールトインジェクションと一致します)。
(写真/DeepFlowネットワークフレームグラフ)
ステップ 3: コンテナ ネットワークで異常なネットワーク インジケーターを特定する
トラブルシューティングの経験に基づいて、ユーザーは Seat-Service と Config-Service のポッドのネットワーク インジケーターを確認する必要があります。現時点では、ユーザーは DeepFlow のポッドレベルのネットワーク インジケーター ページにジャンプする必要があります。このページを通じて、ユーザーは接続確立における 200 ミリ秒の遅延の突然変異と RTT インジケーターの突然変異を確認できます。
(図/DeepFlow ポッド レベル監視インジケーター)
(図/DeepFlow ポッド レベル監視インジケーター)
ステップ 4: 考えられる干渉要因を排除する
経験によれば、ホストの CPU と帯域幅がいっぱいの場合、仮想ネットワークでもパケット損失と遅延が発生するため、seat-service と config-service が配置されているノードの CPU とノード レベルを確認する必要があります。ノードレベルのリソースが飽和しないようにするために、その時点で帯域幅が特定されます。
k8s コマンドを使用して 2 つのポッドが配置されているノードを確認し、DeepFlow のノード インジケーター監視ページに移動して対応するインジケーターを確認すると、ノードの bps、pps およびその他のインジケーターが範囲内にあることがわかります。妥当な範囲。
(画像/k8s コマンドを使用してポッドが配置されているノードを検索)
(図/DeepFlowノードレベルの監視指標(クライアント))
(図/DeepFlowノードレベルの監視指標(サーバー))
ノード レベルのネットワーク インジケーターに明らかな異常がなかったため、最終的にはシート サービスのポッド レベルの rtt インジケーターが異常であると判断されました。
手動トラブルシューティングの概要
一連のトラブルシューティング プロセスの後、エンド ユーザーは障害のトラブルシューティングを行うことができますが、ユーザーには次の要件が課せられます。
手動による最も簡素化されたトラブルシューティング プロセスと同様に、Kindling-OriginX を使用したトラブルシューティング プロセスは次のとおりです。
各トレースの自動分析
現時点での障害を考慮して、各トレースが自動的に分析され、リストされたトレースが障害ノードに従ってグループ化されます。 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 演算法和專家經驗來建構故障推理引擎，給予使用者可解釋的根因報告。
—— 完 ——
以上がDragon Lizard System Operation and Maintenance Alliance: Kindleing-OriginX が DeepFlow のデータを統合してネットワーク障害の説明を強化する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
