この記事は、2024 年 QCon Global Software Development Conference (北京)で、Yunshan Network の DeepFlow 製品リーダーである Xiang Yang が「eBPF + LLM: オブザーバブル エージェントを実現するためのインフラストラクチャ」をテーマに共有した講演を編集したものです。リンクを確認してPPT をダウンロードします。
2日目登録までカウントダウン！ Observability Open Source Developer Meetup Nanjing Station に参加してください。
今日は、DeepFlow が可観測性エージェントに対して行った作業の一部を皆さんと共有できることを嬉しく思います。今日のトピックには主に 2 つの側面が含まれます。1 つは eBPF を使用してデータ品質の問題を解決する方法、もう 1 つは LLM を使用してこれに基づいて効率的なエージェントを構築する方法です。これら 2 つの側面から、 eBPF と LLM が可観測性エージェントを実現するための重要なインフラストラクチャである理由がわかります。
上記の最初の質問は、実際にはデータ ガバナンスの問題です。組織仕様の使用や研究開発エンジニアリングの効率の向上など、高品質のデータを取得する方法は数多くあります。今日私が共有するのは主に後者、特に革新的なテクノロジーである eBPF を使用して、侵入ゼロでフルスタックの可観測性データを取得する方法です。高品質のデータを取得したら、LLM をプロンプト ワード エンジニアリング、RAG、微調整などの方法と組み合わせて使用し、効率的な監視可能なエージェントを構築できます。今日共有されるプラクティスは、可観測性製品である DeepFlow から生まれており、これも人気が高まっているオープンソース プロジェクトです。最後に、観察可能なエージェントの進化についての私の考えも共有します。
01
eBPF を使用して高品質の可観測性信号ソースを構築する
最初の問題の本質は、高品質の可観測性データの取得を目的としたデータ ガバナンスです。たとえば、現時点でデータの整合性と関連性を確保するために APM を使用する方法を見てみましょう。特にクラウドネイティブ環境では、クライアントがサーバーにアクセスするときに、複雑な K8s ネットワーク、さまざまなゲートウェイ、さまざまなミドルウェア、データベース、DNS およびその他の基本サービスを経由する可能性があります。これらの中間リンクは APM ではカバーされません。 、観測された APM の場所とプロセスの実際のネットワーク リクエストも異なります。これに基づいてデータ ガバナンスとデータ分析を行うと、通常、データの整合性と一貫性に問題があることがわかります。ビジネス側のインストルメンテーション カバレッジの推進と改善には多くの時間と労力がかかります。パケット キャプチャを使用する必要があり、多数の基本サービスの異種データを連結するには、ログやその他の方法が使用されます。下の図は、APM を使用するときによく発生する問題であると考えられています。クライアントで観察される遅延は 500 ミリ秒ですが、サーバーで観察される遅延はわずか 10 ミリ秒です。さらに悪いことに、サーバーがインストルメンテーションを送信していない可能性があります。まだ。
もっと身近なところで、eBPF が高品質の可観測性信号源のインフラストラクチャであると言えるのはなぜでしょうか? eBPF テクノロジは、カーネルでプログラム可能なテクノロジです。下の図にある小さな蜂はそれぞれ、eBPF がフックできる関数の位置です。 eBPF を使用すると、フック ビジネス関数、システム コール、カーネル関数、ネットワークおよびディスク ドライバー関数を通じて、クラウド ホスト上のあらゆるプロセスのすべての内部状態を認識できます。さらに重要なのは、eBPF Verifier の存在により、このアクションは完全に安全であり、JIT コンパイル メカニズムにより、そのパフォーマンスはカーネルのネイティブ コードと同等であるということです。
eBPF テクノロジーには 2 つの独自の利点があり、APM が直面するデータ品質の問題を十分に解決できます。 1 つ目の利点は、侵入がゼロ (ゼロ コード)であることです。eBPF プログラムの操作には、コードの変更、再コンパイル、またはアプリケーション プロセスの再起動が必要ありません。これは、いつでもプロダクションにアップロードできるプラグ アンド プレイ テクノロジです。時間。 2 番目の利点は、ビジネス プロセス、ゲートウェイ、メッセージ キュー、データベース、オペレーティング システムのいずれであっても、eBPF を使用して観測データを収集できることです。したがって、プロセスの実行中、ビジネス ロジックから言語ランタイム、共有ライブラリからカーネル、ハードウェア ドライバーに至るまで、ソフトウェア スタック全体との対話はすべて、eBPF を使用してカバーできます。以下の図から、eBPF が収集できる生データは、プロセス イベント、ファイル イベント、パフォーマンス イベント、ソケット イベント、カーネル イベント、ハードウェア イベントなど、非常に豊富であることがわかります。今日の QCon セッションのテーマは、ビジネスの可観測性です。このトピックでは、まず最初の 4 種類のデータに焦点を当てます。
ただし、上の図に表示されているデータは単なる生データであり、日常的に使用できるビジネス可観測性データを取得するには、識別、抽出、変換、関連付け、集計などの操作が必要です。下の図は、DeepFlow での eBPF 生データ処理の一部をまとめたものです。ソケット イベントに基づいて API のリクエスト/エラー/遅延のゴールデン インジケーターを抽出できることがわかります。これらのインジケーターを関連付けることで、サービス マップを構築できます。 、すべての呼び出しを相関させることによって、分散トレーシング呼び出しチェーンを形成でき、これらの呼び出しチェーンを集約することによって、より詳細な API マップを構築できます。その中で、eBPF に基づくゼロ侵入分散トレーシングは、インストルメンテーションや TraceID インジェクションなしで実現できる分散トレーシングです。興味のあるパートナーは、GitHub リポジトリからダウンロードして試してみてください。さらに、プロセスイベントからプロセスの開始および停止ログを抽出でき、ファイルイベントからファイルアクセスログを抽出でき、パフォーマンスイベントからCPU、メモリ、GPU、ビデオメモリ、ロックイベントを抽出し、パフォーマンス分析フレームグラフを作成できます。描かれた。
観測信号を取得することに加えて、実行する必要がある重要なタスクは、統一されたラベルをデータに挿入することです。たとえば、K8s、クラウド、CMDB から取得したリソース タグとビジネス タグを挿入すると、フルスタック データを水平に関連付けることができます。また、プロセス、スレッド、コルーチンなどのシステム レベルのタグだけでなく、サブネットなどのネットワーク レベルのタグも挿入できます。 IP および TCP SEQ は、分散呼び出しチェーンを垂直に関連付けるのに役立ちます。
分散トレーシングを例に、eBPF を使用した DeepFlow の効果を見てみましょう。次の図は、APM と eBPF の追跡結果の違いを比較したものです。APM を使用すると、一般に Java プロセスをカバーできますが、API ゲートウェイ、マイクロサービス ゲートウェイ、サービス グリッド、DNS、Redis、MySQL などを全体的にカバーすることは通常困難です。 Java 言語のアプリケーション カバレッジ コストも比較的高くなります。 eBPF を使用すると、ゼロ侵入およびフルスタック データに基づいて、コール スタック全体がすべてのビジネス プロセスとインフラストラクチャ プロセスに加え、K8s ネットワーク送信、ファイルの読み取りと書き込み、その他のイベントをカバーできます。この機能は非常に最先端のイノベーションであり、私たちはこの成果を 20 ページ近くの学術論文として発表し、昨年、米国コンピュータ協会の最高学術会議である ACM SIGCOMM に採択されました。
今日のセッションのトピック「ビジネスの可観測性」に戻りますが、eBPF によってカーネルから取得されたデータはどのようにビジネスに関連付けられるのでしょうか? eBPF はコア テクノロジであり、エコロジカルな議論全体はシステム、パフォーマンス、セキュリティなどに焦点を当てていますが、アプリケーションはビジネス セマンティクスに焦点を当てており、開発者はビジネスおよび効率に関する情報を取得したいと考えています。 eBPF の可観測性をシステムからビジネスまでの次元の壁をどのように突破するか、DeepFlow のアプローチについてお話します。ソケット データを例に挙げると、eBPF によって取得されたデータに対してプロトコル解析を実行する場合、通常は標準プロトコル (HTTP、MySQL など) のヘッダー フィールドのみを解析します。 DeepFlow は現在、HTTP1/2/S、RPC、MQ、DB、およびネットワーク カテゴリをカバーする 20 を超えるプロトコル解析をサポートしています。 DeepFlow に組み込まれた解析機能は、これらのプロトコルのヘッダーから標準フィールドを抽出したり、URL、SQL ステートメント、エラー コードなどのペイロードさえも抽出できます。ただし、HTTP ペイロードに含まれるビジネス エラー コード、トランザクション シリアル番号、注文 ID、車両フレーム番号などの情報は、統一されたロジックに従って抽出することはできません。また、企業がシリアル化に Protobuf、Thrift、その他のメソッドを使用する場合もあり、ペイロードを解析するために対応するスキーマと組み合わせる必要があります。
ここでは、別のテクノロジであるWebAssemblyを使用して、この問題を解決します。実際、eBPF がカーネルでプログラム可能なテクノロジであると考えると、WebAssembly はユーザー モードでプログラム可能なテクノロジになります。 DeepFlow を使用して、一連の安全で高性能なホットロード プラグイン メカニズムを実装し、ユーザーは Golang、Rust、C/C++ およびその他の言語を使用してプラグインを作成し、ビジネス ペイロードのオンデマンド解析を実現できます。これにより、リクエスト ログとファイル アクセス ログが分析され、eBPF 観測データが強化されるまで待ちます。たとえば、DeepFlow が提供するプラグイン SDK に基づいて Golang プログラムを作成し、HTTP Protobuf ペイロードを解析し、ビジネスに関係するフィールドを抽出できます。ペイロード内のエラー コード、エラー メッセージ、その他の情報を使用して、元の HTTP リクエスト ログの対応するフィールドを書き換えることもできます。
最後に、このセクションのタイトルは「eBPF を使用した高品質可観測性信号源の構築」です。したがって、eBPF はインフラストラクチャであり、可観測性構築全体の最初のステップであると私たちは考えています。ゼロ侵入可観測性機能の強固な基盤に基づいて、従来の侵入型データをオンデマンドで組み込み、統合ラベルを注入して、より強力な可観測性プラットフォームを構築できます。 eBPF の機能は、スター ウォーズの冒頭でセクションを入力してWhos your daddy地図を完全に開くようなものですが、従来の侵入型データは、ビジネス側がサイエンス ボールを使用してオンデマンドでローカル エリアの定点探索を行うようなものです。
02
LLM を使用して効率的な可観測性エージェントを構築する
本日共有される 2 番目のポイントは、LLM の機能を使用して、高品質のデータに基づいて観察可能なインテリジェンスを構築する方法です。これまで、AIOps の最大の問題点はデータ品質の悪さ (カバレッジが低く、フォーマットが乱雑) でした。 AIOps を開始しようとすると、データ ガバナンスの推進には通常半年以上かかります。現在、eBPF の高品質なデータは基盤が強固であることを意味し、同時に AGI の時代と重なり、LLM は以前の小型モデルよりもはるかに強力な機能を実証しました。したがって、eBPF + LLM は可観測性エージェントを実現するための基盤であると考えられます。この分野における DeepFlow の実践例をいくつか紹介しましょう。
現段階では、DeepFlow はすべての問題に対応するエージェントを構築しているわけではありません。開発、テスト、運用保守のプロセス全体で問題を調査し、可観測性とエージェントを組み合わせて最も解決が困難な問題を 2 つまたは 3 つ選択したいと考えています。問題点を理解するには、まず次の 2 つまたは 3 つの点に焦点を当てます。私たちが発見した最初のシナリオは作業指示、特に作業指示グループ作成の初期段階における混沌としたプロセスです。2 番目のシナリオは変更、特に変更後のパフォーマンスの急激な低下の境界線であり、現在も調査中です。今日は、このシナリオについての予備的な考えをいくつか共有します。
作業指示の非効率性: まず、社内のアラームが Feishu グループなどのグループ チャットの作成をトリガーすると仮定します。顧客のオフィスで見られる典型的なシナリオを考えてみましょう。最初の担当者が作業指示グループに引き込まれた後、コール チェーンの追跡データを調べ、分析を行って、それが自分の問題ではないことがわかり、その後、指示を取り下げます。作業指示グループに 2 人目の人が加わり、この人はいくつかの指標データを調べ、分析を行った後、それが自分の問題ではないことがわかり、3 人目をグループに加えました。イベント データを分析した後、それが自分の問題ではないことがわかり、部門内で最も有力な人物であるラオが登場するまでは問題が解決しなかったのかもしれません。ワンさんはグループに引き込まれ、より深く詳細な分析と要約が行われ、棺が完成し、正しい責任者であるシャオ・リーに命令を転送する作業が完了することができました。作業指示が Xiao Li に照合されるまでのプロセスは非常に複雑で非効率的で、1 時間以上かかる場合もあります。たとえ最初に連れてこられた人々がプロセス全体に参加していないとしても、この作業指示グループの存在により、通常の作業が時折中断され、作業指示に参加している全員の効率に重大な影響を及ぼします。グループ。
可観測性エージェントはこの問題をどのように解決できるでしょうか?作業指示が作成されると、AI エージェント駆動のロボットが自動的に作業指示グループに引き込まれます。 AI エージェントは、まず DeepFlow API を呼び出して追跡、インジケーター、イベント、ログ、その他のデータ タイプを表示し、一連の統計アルゴリズムを使用してデータの特徴を要約します (これにより、トークンの数が効果的に削減されます)。これらの機能情報は、LLM を呼び出すためのプロンプトとして使用されます (現在、分析には主に GPT4 が使用されています)。 1 つのタイプのデータを分析した後、AI エージェントは LLM の関数呼び出し機能または JSON モード機能を使用して、他のどのタイプのデータを分析する必要があるかを決定します。最後に、AI エージェントは LLM にすべての分析結果に基づいたサマリーの作成を要求します。
このプロセスでは、DeepFlow の eBPF は完全なフルスタックの可観測性データを提供し、自動タグ付けは統合された意味論的に豊富なラベルをすべてのデータに挿入します。 AIエージェントは分析結果に基づいて、label.ownerなどのラベルを利用して、該当する担当者を作業指示グループに正確に引き込むことができます。現段階では、AI エージェントの作業指示境界の精度は 100% に達することはできませんが、作業指示グループの非常に混沌とした初期期間を、ほとんどの場合 1 時間以上から 1 分に圧縮することに成功しています。作業指示グループの効率が大幅に向上し、作業指示グループの人数が減り、チーム全体の作業効率が大幅に向上しました。
変更の非効率性: クラウド ネイティブ環境では、サービス リリース後のパフォーマンス低下の理由は多面的である可能性があり、コール チェーンとソフトウェア コード スタックの複雑さにより、オンコールを担当するパートナーにとっては困難な場合があることがわかりました。根本的な原因は、自分の知識の範囲を超えた内容についての無知により、簡単に判断を誤る可能性も非常に高いということです。このような問題が発生した場合は、一時的に容量を拡張するかロールバックして業務を復旧し、問題の修正を待って再度バージョンをリリースするしかありません。ただし、テスト環境では実稼働環境の問題を再現できない場合があるため、問題の根本原因の分析を支援する一連のトラフィック再生メカニズムを導入する必要があります。このシナリオでは、AI エージェントが開発者がパフォーマンス低下の根本原因を迅速に特定し、バージョンをより早くオンラインに戻すのに役立つことを期待しています。
複雑なコール チェーンを含むシナリオについては、作業指示エージェントの例ですでに優れたソリューションが用意されています。複雑な関数呼び出しスタックを含むシナリオの場合、これは eBPF の専門分野であり、プロセスの実行中に侵入することなくビジネス関数、ライブラリ関数、ランタイム関数、およびカーネル関数呼び出しスタックを取得できます。 eBPF のセキュリティと低いオーバーヘッドにより、プロファイリングは継続的にオンにすることができるため、通常、変更後にパフォーマンスが許容できないレベルに低下する前に、プロファイリング データが蓄積されます。データを活用して根本原因の特定を迅速に完了します。
eBPF プロファイリング データは非常に広範囲のテクノロジ スタックをカバーしており、ビジネス開発者がすべての情報を理解することは困難です。このシナリオは、AI エージェントが得意とするものです。以下の図に示すように、LLM は通常、カーネル関数、ランタイム関数、および基本ライブラリ関数の知識を理解できるため、これらの関数の解析結果を直接与えることができます。 LLMが苦手な部分があったとしても、その機能が配置されているソフトウェアプロジェクトは頻繁に更新されず、常識に属するものであるため、LLMが使いこなせていない部分を微調整することで強化することも考えられます。 Python のリクエストなど、一般的に使用されるアプリケーション ライブラリ関数をいくつか見てみましょう。これらのライブラリは、多数、高速な反復、および豊富なインターフェイス ドキュメントを特徴としています。そのような関数のドキュメントをベクトル化し、RAG メカニズムを使用して、 LLM 分析を強化します。さらに、企業の内部ビジネス コードは一般的な知識ではなく、量が多く、変化が速いため、たとえば、対応する Git に直接フィードするためにプロンプト ワードを最適化することを選択します。 DeepFlow の自動タグ付け機能を使用すると、AI エージェントが commit_id を通じて最近のコード変更レコードを見つけて LLM に通知することが簡単にできます。LLM、ファインチューニング、RAG、およびプロンプト エンジニアリング テクノロジを組み合わせて使用することで、eBPF フルスタック プロファイリング データに関わるすべての専門分野を完全にカバーでき、開発者が根本原因を迅速に特定できるようになります。
脆弱性の非効率性: あるレポートでは、「脆弱性の修正は 76% 無駄である可能性があり、優先的に注意すべき脆弱性は 3% のみである」と述べられています。 DeepFlow は、AI エージェントを使用してこのリンクの効率を向上させる方法をまだ模索しています。確かなことは、eBPF がクラウド ワークロード セキュリティのための優れたデータ収集テクノロジであるということです。 Isovalent は、プロセス実行、ネットワーク ソケット、ファイル アクセス、レイヤー 7 ネットワーク ID というセキュリティの 4 つの重要な観察信号を要約しています。 DeepFlow は現在、これら 4 つの信号を部分的にカバーしていますが、今後も強化を続けていきます。これらのデータが完成し、LLM と組み合わせることで、非常に目を引くセキュリティ シーンの AI エージェントを作成できると思います。
このパートの最後では、AI エージェントを継続的に改善する方法について説明します。作業指示のシナリオを例に挙げると、テスト環境でカオス エンジニアリングを使用して大量の異常データを構築します。これらの異常の正しい根本原因がわかっているため、それらを AI Agenl の評価に使用できます。そしてそれを継続的に改善します。実稼働環境 (注: PPT の右側が実稼働環境である必要があります) では、ユーザーがスコアを付けるメカニズムを追加し、エージェント開発者はスコアに基づいて改善を行います。
03
DeepFlow ユーザー向けの可観測性エージェントの実践例
では、DeepFlow の AI エージェントは現在どのようになっているのでしょうか?この部分について簡単に紹介しましょう。現在、DeepFlow Enterprise Editionのページでは、トポロジマップ、コールチェーン追跡、継続分析ページからAIエージェントを呼び出すことができると同時に、Feishu ChatBotからエージェントのAPIを呼び出して機能を実装することもできます。作業指示の専門家のもの。 AI エージェントが最初の概要を説明した後、さらに 3 つまたは 4 つの質問が表示されます。これらの質問を直接クリックして会話を続けることができます。もちろん、ユーザーが直接質問を入力して対話することも可能です。
さらに、本日、DeepFlow Community EditionでもAI Agent機能がリリースされ、現在のGrafanaパネルデータを分析できるようになりました。現在、Topo と Tracing の 2 つのパネルがサポートされており、GPT、Tongyi Qianwen、Wenxinyiyan、ChatGLM の 4 つの大きなモデルに適合しています。ぜひダウンロードして試してみてください。
04
今後の進化の方向性について考える
最後に、DeepFlow AI Agent の今後の進化の方向性についてお話しします。
eBPF はクラウド アプリケーションを完全にカバーできるようになりました。次に、自動運転やスマート カーでのスマート スペース ドメイン制御、権限が許可されている一部のスマートフォン シナリオなど、その機能をエンドサイドに拡張します。
その一方で、RAG には最適化の余地がたくさんあることもわかりました。「RAG: Retrieval-Augmented Generation for Large Language Models: A Survey」のレビューをご覧ください。
05
ディープフローとは
DeepFlow は、複雑なクラウド インフラストラクチャとクラウド ネイティブ アプリケーションに深い可観測性を提供することを目的として、Yunshan Network によって開発された可観測性製品です。 DeepFlow は、eBPF に基づいて、アプリケーションのパフォーマンス指標、分散トレース、継続的パフォーマンス分析などの観測信号のゼロ侵入( ) 収集を実現し、スマート ラベル( ) テクノロジーと組み合わせて、フルスタック( ) の相関とすべてのデータへの効率的なアクセスを実現します。観測信号。 DeepFlow を使用すると、クラウド ネイティブ アプリケーションは自動的に深い可観測性を実現できるため、開発者に対する継続的なインストゥルメンテーションの大きな負担が軽減され、コードからインフラストラクチャに至るまでの監視および診断機能が DevOps/SRE チームに提供されます。Zero CodeSmartEncodingFull Stack
GitHub アドレス: https://github.com/deepflowio/deepflow
DeepFlow デモにアクセスして、ゼロ インストルメンテーション、完全なカバレッジ、および完全に関連する可観測性を体験してください。
イベント プレビュー | 可観測性オープンソース開発者ミートアップ「インテリジェントな可観測性: 大規模モデルによる可観測性の進化」