オブザーバビリティのチートコードが登場

開発者は、現代の分散システムで包括的なオブザーバビリティを追求する際、困難な「計測税」に直面します。従来のアプローチでは、初日から「困難な道」が求められ、すべてのアプリケーション内で手動によるコード調整が必要です。この多大な開発者の労力は、機能開発から重要なリソースを奪い、サービスポートフォリオ全体にわたる反復的で定型的なテレメトリー統合でチームを停滞させます。これは費用がかかり、時間のかかる作業です。

アプリケーションレベルのSDKは、詳細な洞察を得るために不可欠ですが、かなりのパフォーマンスとリソースのオーバーヘッドを招きます。OpenTelemetry SDKのようなライブラリを統合することは、新しい依存関係を追加することを意味し、無数のマイクロサービスにわたるバージョン管理と依存関係管理を複雑にします。各SDKインスタンスは貴重なCPUサイクルとメモリを消費し、通常1〜5%のCPU使用率を占め、アプリケーションのパフォーマンスに直接影響を与え、運用コストを増加させます。

この手動計測のパラダイムは、必然的に重要なオブザーバビリティの死角を生み出します。安定しているものの保守されていないレガシーアプリケーションは、コード変更に抵抗することが多く、その内部動作は不透明なままです。現代のスタックで遍在する重要なサードパーティライブラリは、内部の計測ポイントをほとんど公開せず、事実上それらをブラックボックスに変えてしまいます。これらの未対応の領域は、未発見の「unknown unknowns」によってさらに複雑になり、包括的な可視性を妨げ、システムを目に見えない問題に対して脆弱なままにします。

この課題の規模を想像してみてください。数百のサービスを運用する組織です。「持っているすべてのアプリケーション」を手動で計測するという考えは、すぐに非現実的になります。最近のBetter Stackのビデオで講演者が述べているように、「なぜ初日から困難な道を選び、持っているすべてのアプリケーションのコードを調整するのでしょうか？」この規模では、均一で深いオブザーバビリティはとらえどころのない目標となり、パフォーマンスの低下、セキュリティの脆弱性、または微妙な運用上の障害を隠す可能性のある重大なギャップを残します。

さらに、これらの組み込みSDKを常に更新および保守する必要があるため、継続的かつ増大する負担が加わります。アプリケーションが進化し、ビジネス要件が変化するにつれて、計測もそれに追随する必要があり、保守のバックログが絶えず増えていきます。このサイクルは計測税を永続させ、開発チームを反応的なモードに閉じ込め、常に革新するのではなく、追いつくことに追われます。これは多くの組織が単に負担できないリソースの浪費であり、複雑な環境を効果的に監視および管理する能力を妨げます。

eBPF（Extended Berkeley Packet Filter）は、Linux kernelの奥深くに存在する革新的な技術です。この強力なフレームワークにより、開発者はサンドボックス化されたプログラムをカーネル内で直接実行でき、オペレーティングシステムを根本的なレベルで安全かつ効率的に監視および操作する方法を提供します。これはユニバーサルなデータソースとして機能し、アプリケーションコードを変更することなく重要な洞察を捕捉します。

eBPFプログラムは、ネットワークパケット処理やファイルシステムアクセスから、プロセス実行や重要なsystem callsに至るまで、幅広いカーネルイベントにアタッチします。これらのフックは、システム上で発生するすべてのインタラクションに対して比類のない可視性を提供します。従来の方法とは異なり、eBPFはアプリケーションコードの変更や再コンパイルを一行も必要とせずに、このきめ細かいデータを捕捉します。

コンピューティングインフラ全体に対する非侵襲的なMRIを想像してみてください。eBPFはまさにその機能を提供し、外科的介入や侵襲的な計測を必要とせずに、すべてのインタラクション、すべてのパケット、すべてのシステムコールを可視化します。これにより、システムの健全性とパフォーマンスに関する完全なリアルタイム診断画像が得られます。

この革新的なアプローチは、「計測税」を完全に回避し、手動計測に以前必要だった肥大化したコードと多大な開発者の労力を排除します。すべてのアプリケーションでコードを調整する代わりに、eBPFはサービス群全体にわたって広範で労力の少ない可視性を提供します。これは非常に安価な実験であり、実装も非常に迅速です。

多くの組織が発見しているように、eBPFを迅速にデプロイすることで、100サービスのうち95サービスに即座に深い可観測性を獲得できます。この基盤となるデータ収集層は、真に必要とされる場所でのみ、ターゲットを絞ったきめ細かなOpenTelemetry SDK計測を可能にし、カバレッジとオーバーヘッドの両方を最適化します。CodeRedの全エピソードはApple Podcastsで視聴できます: https://podcasts.apple.com/gb/podcast/40-breaking-the-observability-model-pricing-ai-sre/id1754360359?i=1000756128255。

OpenTelemetryは、テレメトリーデータのための決定的なベンダーニュートラルな業界標準として登場します。これは、traces、metrics、logsを含む重要な可観測性シグナルの収集とエクスポートを統合し、開発者をプロプライエタリなソリューションやベンダーロックインから解放します。この標準化されたアプローチは、データパイプラインを合理化し、「計測税」を削減し、多様な環境にわたるすべてのサービスに一貫したフレームワークを提供します。

その強力なSDKは、開発者がコード内で直接、深いアプリケーション固有のコンテキストをキャプチャすることを可能にします。これは、eBPFがアプリケーション層で完全に再現できない機能です。このきめ細かな計測は、基本的なシステムメトリクスを超え、チームがカスタムビジネス取引にタグを付けたり、特定のユーザーIDを追跡したり、カスタムメタデータでスパンを強化したりすることを可能にします。このようなオーダーメイドの洞察は、複雑なアプリケーションロジックのデバッグやユーザーエクスペリエンスの理解に不可欠です。

OpenTelemetryは、分散トレーシングとコンテキスト伝播において真に優れています。複数のマイクロサービスを横断する単一のリクエストを綿密に追跡し、サービス境界を越えてトレースコンテキストをシームレスに伝播します。このエンドツーエンドの可視性は、レイテンシーの問題の診断、障害ドメインの特定、または広範で相互接続されたアーキテクチャ内のパフォーマンスボトルネックの理解に不可欠であり、現代のマイクロサービス可観測性の礎石となっています。

OpenTelemetryのアプリケーションレベルの詳細とeBPFのカーネルレベルの洞察との相乗効果は、強力な可観測性モデルを生み出します。eBPFが「100サービスのうち95サービス」にわたって広範で低オーバーヘッドのカバレッジを提供する一方で、OTel SDKはクリティカルパスに必要な外科的精度を提供し、ある講演者が指摘したように、残りの5つについてはチームが「よりきめ細かなOpenTelemetry SDK計測を使用する」ことを可能にします。この組み合わせたアプローチのさらなる探求については、OpenTelemetry eBPF Instrumentationを参照してください。

一般的な誤解では、eBPFとOpenTelemetryは競合する可観測性ソリューションとして対立させられます。実際には、それらは強力で共生的なパートナーシップを形成し、互いに相手が限界を持つ領域で優れています。対立ではなく、比類のないシステム可視性を提供する補完的な戦略を想像してください。

eBPFをオブザーバビリティの基盤となるフロアと考えると良いでしょう。Linuxカーネルとその相互作用に対する普遍的で低レベルの可視性を提供し、コード変更を一切必要とせずにシステムコール、ネットワークイベント、プロセス実行を自動的に捕捉します。この本質的な広範さと自動検出機能は、インフラ全体にわたる「未知の未知」を理解するために非常に貴重です。

対照的に、OpenTelemetry SDKsは、アプリケーション固有の詳細なシーリングを提供します。これらのSDKはコードを直接計測し、開発者が豊富なビジネスコンテキストをトレース、メトリクス、ログに埋め込むことを可能にします。これにより、ユーザーリクエスト、データベースクエリ、内部関数呼び出しを正確に追跡し、アプリケーションロジックとパフォーマンスに直接結びついたインサイトを提供します。

eBPFは、広範でコード不要なオブザーバビリティにおいて真価を発揮し、専門家が提唱するように、ワークロードの95%でサービスを自動的に検出し、ベースラインテレメトリを捕捉します。最小限のオーバーヘッド（通常CPU使用率1%未満）で、迅速かつ広範囲な可視性を実現する「安価な実験」を提供します。このアプローチは、開発者の介入なしに、ネットワークフロー、ファイルI/O、CPU使用率に関するシステムレベルのコンテキストを提供します。

残りの5%のサービス、またはきめ細かなビジネスコンテキストを必要とするサービスには、OpenTelemetry SDKsが不可欠になります。これらは開発者がクリティカルパスを計測し、カスタムメトリクスを定義し、マイクロサービス全体にわたってトレースコンテキストを伝播することを可能にします。この詳細なアプリケーションレベルのデータは、複雑なビジネストランザクション内の特定のパフォーマンスボトルネックを診断するのに役立ちます。

これら2つのデータストリームを相関させることで、真の力が発揮されます。eBPFによって捕捉された過剰なディスクI/Oやネットワーク遅延などの低レベルのカーネルイベントは、OpenTelemetryによって生成された特定のアプリケーションスパンに直接リンクできます。この統合されたビューは、インフラストラクチャのパフォーマンス問題が上位レベルのアプリケーション動作に与える影響を結びつけ、どちらか一方のテクノロジーだけでは達成できない包括的な診断像を提供します。このハイブリッドアプローチは、カーネルからアプリケーション層まで完全な可視性を提供します。

オブザーバビリティに対する「オール・オア・ナッシング」のアプローチは忘れましょう。95/5ルールと称されることが多い実用的なハイブリッド戦略が、最も効率的な進路として浮上しています。この哲学は、最小限の労力で最大の価値を達成するための「安価な実験」を提唱し、組織がテレメトリに取り組む方法を根本的に再構築します。

eBPFベースの計測は、インフラストラクチャ全体の95%のサービスを自動的にカバーする主力となります。これにより、アプリケーションコードを一行も変更することなく、即座にサービスマップ、重要なREDメトリクス（Rate、Errors、Duration）、および包括的な依存関係グラフが提供されます。これは、広大な資産全体にわたる広範な可視性を得るための、信じられないほど高速で低オーバーヘッドな方法です。

残りの5%のアーキテクチャには、手動のOpenTelemetry SDK計測を予約します。これらは、中核となるビジネスロジック、決済ゲートウェイ、または詳細なカスタムトレースが不可欠な高度に専門化されたサービスなど、ミッションクリティカルなアプリケーションです。OpenTelemetry SDKsは、これらの重要なコンポーネント内の複雑なトランザクションをデバッグするために不可欠な、きめ細かなアプリケーションレベルのインサイトを提供します。

このインテリジェントな労力配分は、従来の100%手動アプローチを悩ませる「計測税」を劇的に削減します。組織は、初日からすべてのサービスを計測するために必要な多大な開発者労力を回避できます。その代わりに、時間とコストのごく一部で、ほぼすべての資産にわたって堅牢なオブザーバビリティを獲得します。

Better StackのeBPFベースのOpenTelemetryトレーシングソリューションは、コード変更なしでクラスター全体を計測することで、この戦略を具体的に示しています。彼らのコレクターは、内部でOpenTelemetryを使用してログ、メトリクス、トレースを収集し、サービスマップやネットワークフローなどの機能をすぐに提供します。この迅速なデプロイメントにより、チームはボトルネックを迅速に特定し、サービスの大部分にわたるシステム動作を理解できるようになり、かつて数ヶ月かかっていた作業が数日で完了するようになります。

重要な5%については、OpenTelemetry SDKsへの投資が的確にターゲットされています。開発者は、カスタムスパンを作成し、豊富な属性を付加し、特定のビジネスワークフローを手術のような精度でトレースする能力を獲得し、最も機密性の高い領域で詳細が漏れることがないようにします。この手作業の集中的な適用は、最も重要な場所で影響を最大化します。

カーネルレベルのeBPFとアプリケーションレベルのOpenTelemetry SDKsとの強力な連携は、最も深いシステムコールから最も複雑なユーザートランザクションまで、包括的な可視性を提供します。これにより、カバレッジと深度の両方が最適化され、以前は莫大なオーバーヘッドなしには達成できなかった全体的なビューが提供されます。95/5ルールは単なるガイドラインではなく、現代のオブザーバビリティにとって戦略的な必須事項です。

eBPFは、複雑なシステム内の未知の未知を発見するためのパラダイムを根本的に変革します。Linux kernelの内部に直接位置するというその独自の視点は、アプリケーションレベルの計測に関係なく、すべてのシステムコール、ネットワークインタラクション、プロセス実行に対して比類のない可視性をもたらします。この深く、低オーバーヘッドの内省は、チームがその存在すら知らなかった問題を明らかにし、従来の監視が見落としていた潜在的な問題や予期せぬパフォーマンスボトルネックに対するプロアクティブな防御を提供します。

eBPFの具体的な力を考えてみましょう。それは、一見無害なサービスから発信される不正なネットワークコールを即座に表面化させ、ファイアウォールルールを迂回する可能性のある侵害や設定ミスを示唆します。アプリケーションログや標準メトリクスで説明されていない特定のプロセスからの予期せぬディスクI/Oパターンは、非効率なキャッシング、データ破損、あるいは過剰なリソースを消費する不正なプロセスを示している可能性があります。さらに、eBPFは微妙なTLS設定ミスやハンドシェイクの失敗を容易に検出し、重要なセキュリティ脆弱性を防ぎ、ユーザーに影響を与えたり停止につながる前に安全な通信を保証します。このカーネルレベルのオブザーバビリティは、これまで見えなかった詳細を捉える真実の基礎層を提供します。

現代の開発パラダイムは、これらの隠れた問題を発見する課題を悪化させます。microservicesの爆発的な普及は、すべてのインタラクションを手動でトレースすることが非現実的でリソースを大量に消費する、広大で相互接続されたウェブを作り出します。AI-generated codeの急速な採用は、さらに問題を複雑にし、従来の明示的なアプリケーション計測では見落とされがちな潜在的な盲点や予測不可能な動作を導入します。これらの非常に動的で複雑な環境では、最低レベルで異常を捕捉できる、より広範で侵入の少ない監視ソリューションが求められます。

eBPFは、重要なシステムテレメトリーを捕捉するための包括的なゼロコードソリューションを提供することで、この増大する複雑さに直接対処します。システムコールインターセプトを実行し、ワイヤースピードでネットワークトラフィックを分析するその能力は、従来の方法では見過ごされがちだった可観測性のギャップを埋め、重要なイベントが見過ごされることがないようにします。このカーネルネイティブなアプローチは、OpenTelemetryが提供するきめ細かなアプリケーションレベルの詳細を補完する普遍的なベースラインを提供します。進化する統合に興味がある方は、OpenTelemetryプロジェクトがこの相乗効果を推進し続けています。OpenTelemetry eBPF Instrumentation Marks the First Releaseで最新の開発についてお読みください。この強力なパートナーシップは、比類のない洞察を提供し、組織がインフラストラクチャ全体のシステムヘルスとセキュリティに取り組む方法を変革します。

eBPFのエコシステムは急速に成熟し、初期の複雑さを解消し、重要なポータビリティの課題に対処してきました。libbpfやCO-RE（Compile Once, Run Everywhere）イニシアチブのようなプロジェクトは、この進化に貢献し、eBPFプログラムが再コンパイルなしで多様なLinuxカーネルバージョンで確実に動作することを保証しています。この安定性は、広範な採用の基盤となります。

安定性の向上は、野心的な新しいプロジェクトを直接可能にします。OpenTelemetry eBPF Instrumentation (OBI)プロジェクトは最近、パブリックアルファ版をリリースし、重要なマイルストーンを達成しました。OBIは、eBPFがHTTPやデータベースのインタラクションなどのプロトコルレベルのテレメトリーをカーネルから直接捕捉する方法を標準化することを目的としています。これにより、既存のOpenTelemetryワークフローとシームレスに統合される豊富なテレメトリーデータを生成するための、ベンダーニュートラルなゼロコードメソッドが提供されます。

OBIは、カーネルレベルプログラミングの複雑さを抽象化し、真に普遍的な可観測性への重要な一歩を表しています。これにより、開発チームは専門的なカーネルの専門知識を必要とせずにeBPFの深い洞察を活用でき、包括的なシステム可視化への道を合理化します。この標準化は、相互運用性を確保し、開発者の負担を軽減します。

業界はこの強力なハイブリッドアプローチを迅速に採用しました。商用およびオープンソースのソリューションは現在、eBPFとOpenTelemetryをユーザーフレンドリーな可観測性プラットフォームにパッケージ化しています。Better Stack、Splunk、Grafana Labsのような企業は、eBPFのデプロイメントを自動化し、そのカーネルレベルのデータをアプリケーションレベルのOpenTelemetryのトレース、メトリクス、ログと関連付ける高度なツールを提供しています。

これらのソリューションは、サービスの大部分において「ゼロコード」の可観測性という約束を実現します。手動でのコード変更なしに、インフラストラクチャ、ネットワーク、アプリケーションの動作に対する即座かつ広範な可視性を提供します。これにより、チームはパフォーマンスのボトルネックを迅速に特定し、以前議論されたとらえどころのない「未知の未知」を発見することができます。

これらの統合プラットフォームにより、実用的な95/5ルールが容易に達成可能になります。チームは、サービスの大部分に対して広範なeBPFベースのインスツルメンテーションを展開し、深く、非常に具体的なアプリケーションの洞察を必要とする重要な5%に対しては、よりきめ細かなOpenTelemetry SDKインスツルメンテーションを予約することができます。これにより、包括的なカバレッジとターゲットを絞った詳細がバランスされ、労力と結果の両方が最適化されます。

オブザーバビリティツールのパフォーマンスへの影響を理解することは、あらゆる本番環境にとって極めて重要です。eBPF と OpenTelemetry SDKs はどちらも強力なテレメトリー機能を提供しますが、オーバーヘッドへのアプローチが異なり、それぞれに最適なユースケースを決定します。それらのリソースフットプリントを比較することで、影響を最小限に抑えながら価値を最大化するための明確な戦略が明らかになります。

eBPF は Linux カーネル内で直接動作し、サンドボックス化されたプログラムを驚くべき効率で実行します。このカーネルレベルの実行は、コンテキストスイッチとユーザー空間のデータコピーを最小限に抑え、一貫して最小限かつ安定したパフォーマンスオーバーヘッドをもたらします。その設計により、包括的なシステム全体の監視であっても、無視できる程度のリソース消費しか発生せず、多くの場合、CPU 使用率の数パーセント未満で測定されます。

対照的に、OpenTelemetry SDKs はより変動性の高いオーバーヘッドを導入します。これらのアプリケーションレベルのエージェントはコードを直接計測し、アプリケーションプロセス自体から詳細なトレース、メトリクス、ログをキャプチャします。開発者は通常、1～5% の CPU オーバーヘッドを観測しますが、この数値は、計測の絶対量、処理されるデータの複雑さ、および選択されたサンプリングレートによって大幅に上昇する可能性があります。きめ細かな洞察は、その深さに比例したコストを伴います。

この根本的な違いは、ハイブリッドオブザーバビリティ戦略の力を強調しています。チームは、eBPF を利用して、ほとんどのサービスにわたる広範で影響の少ないカバレッジを実現し、不可欠なシステムレベルのテレメトリーをキャプチャし、「未知の未知」を最小限の手間で明らかにすることができます。深いアプリケーション固有の洞察を必要とする重要な5～10%のサービス（おそらくパフォーマンスのボトルネックや高価値のトランザクションとして特定されたもの）については、OpenTelemetry SDKs の高いオーバーヘッドは正当なトレードオフとなります。

最終的に、この実用的なアプローチはリソース割り当てを最適化します。広範囲の可視性のために最もオーバーヘッドの低い方法を展開し、OpenTelemetry SDKs によって提供されるきめ細かな詳細がデバッグやパフォーマンスチューニングに絶対不可欠な場合にのみ、より高いオーバーヘッドを受け入れます。この賢明な分業により、スタック内のすべてのアプリケーションに不必要な負担をかけることなく、包括的なオブザーバビリティが保証されます。

実用的で労力の少ないアプローチで、包括的なオブザーバビリティを解き放ちましょう。このブループリントは、eBPF と OpenTelemetry の組み合わせた力を活用し、迅速な価値実現のために設計された「安価な実験」の概要を示しています。「Try it out」という実践的なアドバイスと、「100のサービスのうち95」で迅速に結果を確認するという戦略は、Apple Podcasts の id1754360359 で利用可能な Better Stack のビデオ「eBPF with OpenTelemetry」で議論されている内容と共鳴します。

まず、非本番環境内の単一の Kubernetes ネームスペースに eBPFベースのコレクター をデプロイします。この最初のステップでは、アプリケーションへのコード変更は一切不要であり、摩擦とセットアップ時間を最小限に抑えます。ベンダーソリューションの成長するエコシステムまたは堅牢なオープンソースプロジェクトから選択してください。

数分以内に、そのネームスペースの自動生成されたサービスマップと RED metrics (Rate, Errors, Duration) を分析します。これにより、サービス間の相互作用、依存関係、および全体的な健全性について即座に高レベルのベースライン理解が得られ、計測していなかった潜在的なボトルネックが明らかになります。

次に、同じネームスペース内の単一の重要なサービスを特定します。1つの主要なビジネストランザクションをトレースするために、ターゲットを絞った OpenTelemetry SDK 計測を追加します。この集中的な取り組みにより、すべてのコード行を計測する負担なしに、重要なワークフローに対する深いアプリケーション固有のコンテキストが提供されます。

最後に、既存のオブザーバビリティプラットフォーム内で両方のソースからのデータを関連付けます。eBPFの広範なカーネルレベルの洞察が、OpenTelemetryのきめ細かなアプリケーション固有のトレースとシームレスに統合され、システム動作の完全な多次元的全体像を提示する様子をご覧ください。この相乗効果に関する詳細情報については、OpenTelemetry and eBPF: Everything You Need to Know - Groundcoverをご覧ください。

オブザーバビリティの未来は、あるツールを別のツールに置き換えるゼロサムゲームではありません。それはインテリジェントで戦略的な組み合わせを要求します。すべてのマイクロサービスに対して手動でコードを計測する従来の「困難な道」は、肥大化と開発者の多大な労力を生み出します。eBPFの広範なカーネルレベルの可視性とOpenTelemetryの正確なアプリケーション層の洞察をシームレスに統合するハイブリッドアプローチが、この新しい時代を定義します。

この強力なパートナーシップは、現代の分散システムにとって最も包括的で効率的かつスケーラブルなパスを提供します。eBPFは、比類のないゼロコードデータ収集を提供し、システムコール、ネットワークフロー、プロセス実行をほぼゼロのオーバーヘッドでキャプチャし、チームが探すべきだと知らなかった問題さえも明らかにします。残りの重要な5%のサービスについては、OpenTelemetry SDKsがきめ細かな詳細トレース機能を提供し、最も重要な場所でターゲットを絞った高忠実度データを保証します。この実用的な95/5ルールは、計測の負担を最小限に抑えながら、オブザーバビリティの価値を最大化します。

CO-RE (Compile Once, Run Everywhere)のようなイニシアチブやlibbpfのようなプロジェクトによって強化されたeBPFエコシステムは、重要なポータビリティ問題を解決し、大幅に成熟しました。この成熟度と、OpenTelemetry SDKsの可変オーバーヘッドと比較してeBPFのパフォーマンスへの影響が最小限であるという点が組み合わさることで、ハイブリッドモデルは技術的に堅牢になります。これは、広大なフリート全体で迅速かつ実用的な洞察を提供する「安価な実験」であり、「100のサービスのうち95で」効果的であることが証明されています。

エンジニアリングリーダーは、根本的に考え方を変える必要があります。デフォルトで重いSDKsを使ってすべてを計測するのをやめましょう。代わりに、すべてをインテリジェントに監視しましょう。この実用的なハイブリッド戦略を採用して、最小限の労力で最大の価値を達成し、開発者のサイクルを反復的な計測から解放しましょう。カーネルの秘密兵器と業界の共通言語を活用して、比類のない可視性を実現し、回復力のあるシステムを構築しましょう。

オブザーバビリティにeBPFを使用する主な利点は何ですか？

アプリケーションコードを変更または再デプロイすることなく、深いシステム可視性を提供し、運用オーバーヘッドを削減し、レガシーサービスやサードパーティサービスを含むすべてのサービスからデータをキャプチャします。

eBPFとOpenTelemetryは競合しますか？

いいえ、それらは補完的です。eBPFは広範なカーネルレベルの可視性（「フロア」）を提供し、OpenTelemetry SDKsは深いアプリケーション固有のコンテキストとビジネスロジックのトレース（「シーリング」）を提供します。

ハイブリッド計測戦略とは何ですか？

ほとんどのサービスで広範かつ低労力なカバレッジのためにeBPFを使用し、きめ細かなカスタムトレースを必要とする重要または複雑なサービスにのみOpenTelemetry SDKsを選択的に適用することを含みます。

eBPFはパフォーマンスに大きな影響を与えますか？

いいえ、eBPFはLinuxカーネル内のサンドボックス環境で実行され、高い効率のために設計されています。そのパフォーマンスオーバーヘッドは、アプリケーションレベルのエージェントや広範なSDK計測と比較して最小限です。