eBPF に基づいた次世代のインテリジェントな可観測システムを構築する

この記事は KubeCon China 2023 の共有に基づいています。今日共有するトピックは、eBPF に基づく次世代のインテリジェントな可観測システムの構築です。

始める前に、自己紹介をさせてください。私の名前は Liu Kai、ニックネームは Qian Lu です。現在、Alibaba Cloud の ARMS K8s 監視サブ製品の責任者です。これは私の同僚の Dong Shandong 博士、愛称は Fanden で、Alibaba Cloud の ARMS 製品の AIOps 分野の責任者です。

K8 における可観測性の課題

この共有は主に 3 つの部分に分かれています。まず最初の部分、K8 の可観測性の課題を見てみましょう。

クラウドネイティブ、K8、マイクロサービスなどの概念の台頭により、アプリケーションはマイクロサービス、コンテナ化など多くの変化を経験しました。そうすれば、すべてが統一された標準に向けて発展し、多くのメリットがもたらされます。たとえば、極めて高い柔軟性、効率的な運用とメンテナンス、標準的なランタイム環境などです。しかし同時に、K8s は開発者に多くの問題ももたらします。

パブリッククラウド上の K8s で 1,000 件を超える作業指示を収集しましたが、インフラストラクチャを K8s に移行した後、開発者は実際にどのような問題に遭遇しましたか?

作業指示を分析することで、次の 3 つの主要な課題を分析できます。

まず、K8 のインフラストラクチャの問題は楽観視できません。統計グラフから、ネットワーク関連の問題が 56% 以上を占めていることがわかります。したがって、開発者がこれらの問題に遭遇したとき、観測可能なシステムとして、どのようなデータを収集する必要がありますか?例外の理由をお答えいただけますか?
第二に、アプリケーションの複雑さの大部分がインフラストラクチャに移されているため、アプリケーション層の指標を収集するだけでなく、コンテナ、ネットワーク、その他の観測データも収集する必要があります。収集これらのデータはどうですか?
第三に、非常に多くのデータを収集した後、開発者が問題をトラブルシューティングするのに役立つようにこのデータをどのように使用すべきでしょうか?

K8s のデータ収集ソリューション

さて、これら 3 つの質問に答えて、次の内容、K8s でのデータ収集ソリューションに進みましょう。

一般に、K8s アプリケーションは多くの層に分割できます。最上位層は、一部のフロントエンドページとアプレットを含むビジネス層です。アプリケーション層は、バックエンドアプリケーションのベンチマークです。コンテナ層には、containerd、docker など、さまざまな種類のランタイムを含めることができます。 ; インフラストラクチャ層には K8 が含まれます。それで、ここですか？あまり。K8s アプリケーションの複雑さは継続的に減少しているため、多くの場合、さらに深く掘り下げ続ける必要があります。これには、ネットワークプラグイン、Linux カーネル、または一部のハードウェアドライバーが関係する場合があります。この時点で、前述の最初の質問に答えることができます。K8s にはどのようなデータが必要ですか? 答えは私たちが見ることができるすべてのデータの中にあります。いずれかの層で障害が発生すると、システム全体に異常が発生する可能性があります。

次に、このデータをどのように収集するかという 2 番目の質問を検討します。

実際、現在、私たちの観測可能なフィールドには、各層に多くの独立したソリューションがあります。例えば、ビジネス層ではダイヤルアップテストやフロントエンド監視、ビジネスログ分析などのソリューションがあり、アプリケーション層ではOpentelemetryやJaegerなどのAPMシステム、コンテナ層やインフラ層ではソリューションが存在します。、Prometheus およびさまざまな Exporters 観察ソリューションがあります。しかし、彼がさらに深く掘り下げていくと、これらの伝統的な観察可能なシステムがカバーされることはほとんどありません。これは観察の死角の問題につながります。さらに、多くの層には独自の観測計画がありますが、それらのデータには相関関係がありません。これらは互いに比較的独立しており、各層のデータを統合できる統一された相関次元がないため、データアイランド現象が発生します。

では、これらの問題を解決する方法はあるのでしょうか?

その答えは eBPF テクノロジーです。まず、eBPF テクノロジーについて簡単に紹介します。eBPF は Linux カーネルで実行される仮想マシンで、特別な命令セットを提供し、カーネルを再コンパイルしたりアプリケーションを再起動したりせずにカスタムロジックをロードできるようにします。

この図は、eBPF を使用する基本的なフローを示しています。eBPF コードを作成し、コンパイルツールを使用してそれをバイトコードにコンパイルする必要があります。次に、bpf システムコールを通じて、このバイトコードを指定されたマウントポイントにマウントできます。マウントポイントは、システムコール、カーネルメソッド、またはユーザー空間のビジネスコードである場合もあります。たとえば、右下隅では、hello_world メソッドのエントリおよび戻り位置に eBPF バイトコードを動的にマウントし、eBPF 命令セットを通じてメソッドのランタイム情報を収集できます。

eBPF テクノロジには 3 つの大きな特徴があります: 1 つ目は、非侵入的で、動的にマウントされ、ターゲットプロセスを再起動する必要がありません。2つ目は、高性能で、 eBPF バイトコードはマシンコードに組み込まれてから実行されます。非常に効率的;第三に、より安全です,独自のサンドボックスで実行され、ターゲットプロセスがクラッシュすることはありません. また、ロード時に厳密なベリファイア検証があり、追加したコードが正常であることを確認します。無限ループや不正アクセスはなく、メモリやその他の問題もありません。

この表は、eBPF と従来の apm プローブの違いを比較しています。eBPF テクノロジーには、カバレッジ、侵入性、パフォーマンス、セキュリティの点で明らかな利点があります。

eBPF に基づいてデータを収集するにはどうすればよいですか? 私たちが構築した最初の機能は、アーキテクチャの認識でした。アーキテクチャ認識により、クラスターのアプリケーションアーキテクチャ、動作ステータス、ネットワークフローを自動的に分析できます。

K8s マイクロサービス間の通信は、カーネルレベルから見ると、Linux ネットワークプロトコルスタックのパケット送受信プロセスです。udp パケット収集を例として、パケット収集プロセスを簡単に紹介します。左上隅から開始して、データパケットがネットワークカードに到達すると、ソフト割り込みがトリガーされます。Do_softirq はソフト割り込みを処理し、net_rx_action メソッドに入ります。このメソッドは、ネットワークを通じてネットワークカード上のデータパケットをアクティブにポーリングします。カードドライバー。

データパケットを取得した後、ネットワークプロトコルスタックに送信されます。これは非常に重要なメソッド netif_receive_skb であり、多くのパケットキャプチャツールもこの場所で動作します。このメソッドは、arp または ip、tcp または udp などのパケットプロトコルに応じたさまざまなパケット処理ロジックの後に、パケットをユーザープロセスの skb 受信キューに入れます。ユーザープロセスが、recvfrom syscall を呼び出してパケット収集を開始すると、skb キュー内のパケットがユーザー空間に読み込まれます。

この理論的根拠に基づいて、アーキテクチャの認識を確認してみましょう。実際に行われるのは、ネットワークフローとネットワーク品質の検出です。したがって、これらの目的を達成するために、Linux パケットの送受信パスにあるいくつかの重要なカーネルメソッドを確認できます。

この表では、netif_receive_skb や dev_queue_xmit など、送受信されたデータパケットの回数、サイズ、ネットワークフローの方向をカウントできるいくつかの観測ポイントをリストしました。ネットワーク品質を測定できる再送信。

このページは、当社の製品におけるアーキテクチャを意識したランディングページです。この図を通して、クラスターの概要、ネットワークフロー、トポロジー情報、各ノードのステータスを明確に見ることができます。このことから、上の 2 つのノードが黄色でマークされ、オレンジ色に変わっていることがわかります。これは、これら 2 つのノードのネットワークステータスに問題があることを意味します。パケットロスが増えるとも言えるし、再送が増えるとも言える。しかし、それは最終的にどのような現象をアプリケーション層に反映するのでしょうか?

次に構築した 2 番目の機能は、アプリケーションのパフォーマンスの観察です。実際、先ほどのアーキテクチャでは、私たちのアーキテクチャの認識は、トランスポート層からこのインフラストラクチャの健全性を測定することに重点を置いています。実際、日常の開発プロセスの多くでは、アプリケーション層に関する情報を確認したいと考えています。たとえば、HTTP サービスの 4XX および 5XX エラーが増加していないか、処理遅延が増加していないかなどです。

では、アプリケーション層を観察するにはどうすればよいでしょうか? まず、K8s アプリケーション間の呼び出しプロセスを分析しましょう。通常、アプリケーションはサードパーティの RPC ライブラリを呼び出し、次にサードパーティのライブラリがシステムコールを呼び出します。次に、カーネル内で、トランスポート層、ネットワーク層を通過し、最後にネットワークカードドライバーを介して送信されます。

したがって、従来の監視可能なプローブの場合、通常は RPC ライブラリに埋め込まれており、この層はプログラミング言語と通信フレームワークの影響を受けます。

eBPF は、従来の APM と同じマウントポイントを選択し、RPC ライブラリのアッププローブを通じてデータを収集することもできます。ただし、eBPF には多数の実装ポイントがあるため、システムコール層、IP 層、ネットワークカードドライバー層などの埋め込みポイントを下げることもでき、ネットワークの送受信バイトストリームをインターセプトし、プロトコル解析を通過させることもできます。ネットワークのリクエストとレスポンスを分析してサービスパフォーマンスデータを取得します。この利点は、ネットワークバイトストリームがプログラミング言語から切り離されており、RPC プロトコルごとに異なる言語やフレームワークの実装に適応する必要がないため、開発の複雑さが大幅に軽減されることです。

この表は、さまざまな取り付け位置の長所と短所を比較しています。システムコールにポイントを埋め込む方が比較的良い解決策であることがわかります。syscall はプロセス情報を持っているため、一部のコンテナのメタデータを上位に関連付けるのに便利であり、syscall のマウントポイントは安定しており、オーバーヘッドは非常に低いです。

マウント場所が syscall であることを確認した後、サービスのパフォーマンスを分析する原理を簡単に紹介します。

Linux システムを例にとると、データの読み取りと書き込みの syscall は、read、write、sendto、recvfrom など列挙できるため、直感的に取得できるように、これらの syscall に eBPF バイトコードをマウントすることを選択します。読み取られたデータ書き込まれたアプリケーション層データたとえば、HTTP サービスを観察している場合、読み取りポイントを通じて上記の例の受信データを収集し、書き込みポイントを通じて次の例の送信データを収集しました。

次に、送信データと受信データはそれぞれプロトコルパーサーに入ります。プロトコルパーサーは、アプリケーションプロトコル標準に従ってデータを解析します。たとえば、HTTP プロトコルでは、リクエスト行の最初の行の形式が Method、Path、および Version であり、応答の最初の行の形式が Version、StatusCode、および Message であると規定されているため、これを抽出できます。この HTTP リクエストのメソッドは Get、パスは /index.html、戻りステータスコードは 200 です。さらに、読み取りと書き込みがトリガーされた時刻に基づいて、サーバーがリクエストを受信してからレスポンスが返されるまでの処理遅延を計算できます。

これらの重要な情報を抽出した後、いくつかの集約処理プロセスを経て、サービスデータを監視可能なプラットフォームにエクスポートできます。

この写真は、アプリケーションパフォーマンス観察用の製品のランディングページです。この図から、侵入なしで eBPF を介して HTTP サーバーサービスの 3 つの重要な指標、つまりリクエスト数、エラー数、平均遅延を観察できることが明確にわかります。ここでは、リクエスト数が減少しているといういくつかの問題も確認できます。なぜ衰退したのでしょうか？これは何らかの異常が原因である可能性がありますが、この写真では理由を見つける方法がありません。

したがって、3 番目に行う必要があるのは、多次元データの相関関係です。前に述べたように、実際には、K8s アプリケーションのすべてのレイヤーに対応するソリューションがあります。しかし、それらを相互に統合する方法はありません。ここで言う統合とは、統合された相関次元が欠如していることを意味します。たとえば、コンテナの観測データの一部には、通常、コンテナ ID のディメンションが含まれています。たとえば、コンテナの CPU/メモリ使用量などです。次に、K8s リソースを観察する場合、それらはすべて、どのポッドやどのデプロイメントなど、K8 エンティティのディメンションを持ちます。たとえば、アプリケーションのパフォーマンスを監視する場合、従来の APM プラットフォームの一部には通常、ServiceName やトレース ID などのディメンションが含まれています。したがって、相関するための統一された次元が存在しないため、観測データを融合する方法がありません。

これらのデータを統合するにはどうすればよいでしょうか? eBPF はカーネルモードで実行され、追加情報を収集できるため、非常に優れたハブです。いくつかの例を挙げるために、まずいくつかのプロセスクラスのマウントポイントを取り上げます。その後、eBPF はマウント時にプロセス番号、PID 名前空間、その他の情報の一部を収集できます。この情報をコンテナーのランタイムに組み込むと、そのコンテナー ID を簡単に分析できます。このようにして、コンテナデータとの統合を完了できます。

別の例としては、ネットワーク関連のマウントポイントがあります。eBPF を通じて skb のトリプレットを収集できます。これは、要求側のアドレス、ピアのアドレス、およびそのネットワーク名前空間です。このアドレス情報を使用して K8s API サーバーをチェックし、どの K8s エンティティに属しているかを判断し、K8s リソースの統合が完了します。

最後に、アプリケーションのパフォーマンスを監視するためのデータがあります。一般に、APM システムは、アプリケーション層プロトコルの特定のフィールドで、serviceName やトレース ID などのトレースコンテキストを伝送します。その後、eBPF でプロトコル解析を実行するときに、このデータをさらに解析して、この関連付け層を完了することができます。たとえば、HTTP プロトコルはヘッダーを通じてトレースコンテキスト情報を伝送します。

さて、次のデータは製品の実装です。この図では、アーキテクチャの認識とアプリケーション層のデータが融合していることがわかります。

次に、この写真は、K8s リソースとコンテナ観測データの融合を示しています。

上記の内容では、主に、先ほど述べた 2 つの大きな問題、「どのようなデータを収集する必要があるか」、「そのデータをどのように収集するか」について紹介しました。では、これらのデータを取得した後、それらを使用して障害を特定するにはどうすればよいでしょうか? 次に、私の同僚のDong Shandong博士が引き続きお話しします。

K8s での障害位置探索の実践

皆さんこんにちは、東山東です。Qianlu さん、ご紹介と共有をしていただき、誠にありがとうございます。Qian Lu 氏は、K8s の可観測性の課題について詳しく説明し、データの収集と相関付けに eBPF テクノロジーを使用する方法を紹介しました。次に、K8 での障害位置特定の実践についてご案内できることをうれしく思います。

まず、ARMS K8s 監視における手動トラブルシューティングのパスを見てみましょう。ゲートウェイと製品サービスの間で低速ネットワーク呼び出し障害が発生したとします。この時点で人間は通常どのように発見し、トラブルシューティングを行うのでしょうか? まず、アプリケーションの 3 つの黄金指標である RT (平均応答時間)、Error Rate (エラー率)、リクエスト量 (QPS) のアラームなど、入り口アプリケーションと主要アプリケーションのアラームを設定します。アラームを受信すると、ゲートウェイアプリケーションに異常があることがわかります。しかし、問題の原因はどこにあるのか、ダウンストリームノードなのかネットワークの問題なのか、どうやって知ることができるのでしょうか?

最初に注意する必要があるのは、左側のトポロジ図のゲートウェイサービスノードです。ゴールドインジケーターではRTが急激に増加しており、呼び出しが遅いインジケーターも存在することがわかります。

このトポロジ図に沿って、カートサービス、nacos、製品サービスなどのゲートウェイの下流ノードをクリックします。製品サービスのゴールデンインジケータのみが入口のゲートウェイインジケータと類似していることがわかり、ゲートウェイから製品サービスまでのリンクで障害が発生している可能性があると初期的に判断できます。次に、先ほどの操作を繰り返して、製品サービスの下流ノードの分析を続けると、下流ノードがすべて正常であることがわかります。

最後に、ゲートウェイから製品サービスへのネットワーク呼び出しに問題があるかどうかを確認できます。図の点線 (ゲートウェイから製品サービスまでのネットワークコールエッジ) をクリックすると、パケット再送信数や平均 RT などのネットワークコールインジケーターが表示されます。これら 2 つの指標も同様の急激な増加を経験していることがわかりました。

要約すると、トポロジマップの手動ウォーキングと分析に基づいて、障害がゲートウェイから製品サービスへのリンクで発生したと最初に判断できます。これは、ネットワークコールの 2 つの指標にも関連しており、おそらくネットワークの問題です。

手動による調査パスは、インテリジェントな根本原因の特定を行う上で大きな参考値となります。直感的には、上記のプロセスを直接自動化する必要があると考えられます。

まず、ゲートウェイ自体のサービス指標を確認すると、3 つのゴールデン指標のうち RT が異常に急激に増加していると同時に、CPU、メモリ、ディスク使用量などのリソース指標が正常であることがわかります。これは、サービスメトリックに問題があることを示しています。

次に、トポロジ関係を通じて、対応する下流ノードを取得できます。この考え方は、ゲートウェイをチェックするのと似ています。つまり、すべての下流ノードの 3 つのゴールデンサービスインジケーターとリソースインジケーターに異常があるかどうかをチェックします。下流ノードの製品サービスのみ異常であることがわかります。クロスサービスのエラー率にも負の相関がありますが、ビジネスの観点からはエラー率の低下は異常ではなく、ビジネスセマンティクスに基づいて除外できます。

最後に、サービスのネットワーク呼び出しに問題があるかどうかを確認できます。製品サービスを呼び出すゲートウェイのネットワークインジケーターにも同様の異常があることが判明しました。この時点で、先ほど手動分析のプロセスを実際に自動化しました。

さらに進んで、ログを分析できます。例: ログテンプレートを抽出することで、エラーサービスノードログのパターン認識を実行できます。製品サービスインターフェイスを調整するときにタイムアウトエラーログが表示され、その数は 24 回であることがわかります。主要なエラーログを集約し、自動解析のプロセスと結果、エラーログのテンプレート情報と時刻を検査レポートとして出力し、運用保守の専門家に送信します。専門家は、この情報に基づいてインテリジェントな支援型測位を実装します。

それで、話はここで終わりですか？

ここでプロセス全体を確認して、実際にはシステム全体の異常なスキャンにすぎないことを確認してください。あらゆる異常情報を集約し、運用・保守の専門家に提供します。それでは、さらに進んで根本原因の結論を直接導き出すことはできるのでしょうか? これが最初の考えです。

2 番目の考えは、メソッドシステム全体が K8s 監視シナリオに適用されるということです。これをアプリケーション監視、フロントエンド監視、ビジネス監視、さらにはインフラストラクチャ監視まで拡張することはできますか? 異なる監視シナリオで同じアルゴリズムモデルを使用して実装できますか?

要約すると、左側にある 3 つのステップ、つまりディメンションの帰属、異常の境界設定、および FTA (フォールトツリー分析) が答えになります。これら 3 つの主要なステップを詳しく見てみましょう。

1 つ目はディメンションドリルダウン分析ですが、なぜディメンションドリルダウン分析を行うのでしょうか?

ゲートウェイからは、その下流ノードが 3 つであることがわかり、その後、3 つの下流ノードを走査して表示する必要があります。次元帰属があれば、下流の製品サービスに問題があることをゲートウェイ指標から実際に直接分析できます。

業界で一般的なディメンションのドリルダウン方法を見てみましょう。インジケーター全体で異常が発生した後、ターゲットは、どのディメンションが異常部分の原因となっているかを知りたいと考えています。全体的なインジケーターは各ディメンション値のグループ化で構成されているためです。たとえば、全体的なエラー率インジケーターを考えてみましょう。ここで、ディメンションにはサービス、リージョン、ホストが含まれます。各ディメンションには複数の値があり、たとえば、地域には北京、上海、杭州があります。

指標全体に異常が見つかった場合、どの次元のどの値に異常があるのかを次元ごとにドリルダウン分析します。各ディメンションの分析中に、一部のディメンション (リージョンなど) ではすべての値が異常である一方、一部のディメンション (ホスト、サービス) では一部の値のみが異常であることが判明しました。一部の値のみが異常であるこの次元には、さらに注意を払う必要があります。単一次元のドリルダウン位置決めを通じて、各次元のどの値が異常であるかを知ることができます。

次に、異常な次元と値を組み合わせて、単一次元分析から複合次元分析までを実現できます。例えば、hostの値とserviceの値が交差している、つまりhost1とservice1の両方が異常値であることがわかります。その後、マージして根本原因の組み合わせディメンション (host1 と service1) を特定できます。

要約すると、単一次元のドリルダウン分析と組み合わせたディメンション分析を通じて、インジケーター全体の異常を引き起こす特定のディメンションと値を見つけて、障害の範囲を迅速に絞り込むことができます。

マイクロサービストポロジでは、ノードには多層の呼び出し関係があります。単一レベルのディメンション属性では、どの方向にディメンション属性を実行するかを知る必要もあります。

K8s 環境では、全体的なトポロジは比較的複雑で、アプリケーショントポロジとリソーストポロジが含まれる場合があります。次に、マイクロサービス全体のトポロジを簡素化しました。トポロジ図には 2 種類のノードしかなく、1 つはサービスノードと呼ばれ、もう 1 つはマシンノードと呼ばれると単純に考えることができます。ノードを単純化した後、対応関係は、サービス間の呼び出し側と呼び出される側の関係と、サービスとマシン間の依存関係と依存関係に分けられます。このような検討を通じて、乱雑で開始不可能に見えたマイクロサービストポロジ図を、任意のノードから開始して水平および垂直のドリルダウン分析を実行できる図に変換しました。

先ほどの障害を例に挙げると、異常サービスの対象がゲートウェイであるとします。そこから開始して、次元属性を水平方向に実行し、呼び出しのドリルダウン分析を完了できます。垂直方向では、主にリソースの依存関係です。リソース層に沿ってドリルダウン分析を実行し、異常なマシンIPが存在するかどうかを確認します。最後のステップは、依存しているネットワークエッジサービスのネットワーク通信に問題があるかどうかを確認することです。

水平方向の属性、垂直方向の属性、およびネットワーク通信の属性を通じて、根本原因分析をより階層的かつ論理的な方法で実装できます。レイヤーごとのサービストポロジ分析と組み合わせることで、チェーン全体のすべての異常なノードを分析できます。

最後のステップはフォールトツリー分析手法です。異常なノードまたは異常なネットワーク通信を特定すると、どのリンクで問題が発生したかがわかります。しかし、ネットワーク上の通話が遅い問題など、具体的にはどのような問題なのでしょうか? それともリソースCPUの問題でしょうか？

通常、ここにはいくつかの解決策があります。1 つは、教師ありモデルを構築して障害分類を実装することです。ただし、この解決策にはラベル付きデータセットに対する高い要件があり、モデルの一般化と解釈可能性が不十分です。2つ目はフォールトツリー解析手法です。詳しく見てみましょう:

まず、マイクロサービスのトラブルシューティングとガバナンスに関する経験を FTA ツリーに整理して要約する必要があります。FTA ツリーを使用すると、特定のノードとエッジを特定した後、デシジョンツリーと同様の条件判断を行って障害を分類できます。たとえば、ゲートウェイ製品サービスノードのリンクに問題があることが判明しました。ゲートウェイにダウンストリームサービスの依存関係があるかどうか、ダウンストリームでエラーや速度が低下しているかどうか、ネットワークインジケーターに問題があるかどうかを確認できます。3 つの条件がすべて満たされる場合、これはネットワークタイプの問題であることを意味します。

このようにして、より論理的で解釈可能な障害分類モデルが実現されます。

最後に、上図に示すように、根本原因特定の 3 つのコアステップモデルを根本原因分析製品 Insights に統合しました。これは、Insights によって分析された異常イベントリストと根本原因レポートを示しています。Insights には、イベント異常イベントリストページと根本原因分析レポートページの 2 つのコアページが用意されています。現在、Insights はアプリケーション監視や Kubernetes 監視などの複数のシナリオをサポートしています。

特定の製品使用プロセスに関して言えば、アプリケーションが ARMS に接続されると、Insights はリアルタイムのインテリジェントな異常検出を実行します。検出された異常イベントは異常イベント一覧ページに表示されます。イベントの詳細をクリックすると、詳細な根本原因分析レポートが表示されます。レポートには、イベントの説明、主要な指標、異常根本原因の概要、根本原因リスト、および障害伝播リンク図が含まれます。また、根本原因リスト内の特定の例外をクリックして、例外呼び出しメソッドスタック、MySQL によって実行される遅い SQL 情報、例外情報などの詳細な例外分析結果を表示することもできます。

要約する

さて、Qianlu と共有した内容はこれで終わりです。簡単に要約すると、今日は K8s 環境で目に見える 3 つの主要な課題を紹介し、次に K8s 環境でのデータ収集計画、つまり eBPF を使用してさまざまなレベルでのデータ収集を実現し、データ相関を実現する方法について説明しました。最後に、K8s 環境におけるインテリジェントな根本原因の特定の実践的な探求が共有されました。中心となるステップは、ディメンションの属性、異常の境界設定、および FTA フォールトツリー分析です。

今日の内容があなたにインスピレーションや考えをもたらすことを願っています。ご清聴ありがとうございました。

元のリンク

この記事は Alibaba Cloud のオリジナルコンテンツであり、許可なく複製することはできません。