New Relic eBPF オブザーバビリティ

/* New Relic eBPF オブザーバビリティは、新しい可視性レイヤーを提供することで、最新の複雑なネットワークと環境を監視するのに役立ちます。 ## eBPF エージェントはどのような価値を提供しますか?[#value] New Relic eBPF オブザーバビリティは、 Kubernetesおよび Linux ホスト環境全体で統合されたゼロコードの可視性を提供します。 Linux カーネルの拡張 Berkeley Packet Filter (eBPF) テクノロジを使用して、自動化された言語に依存しないインサイトを提供します。 このアプローチにより、手動での計画やコードの変更が不要になり、運用上のオーバーヘッドが削減されます。 <img style={{ align: 'left' }} title="eBPF ダッシュボード" alt="eBPF ダッシュボード" src="/images/ebpf-ダッシュボード.webp" /> ## 影響 [#impact] 最小限のリソース オーバーヘッドでより深い監視を実現し、より迅速に問題を解決できるため、監視がアプリケーションのパフォーマンスに影響を与えません。 エージェントは、システムのダイナミクスを包括的に理解するために、独自のカーネルレベルおよびネットワークの詳細を提供します。*/ /* 監視 最新のアプリケーションは、 Kubernetesクラスタから仮想マシンやクラウド インスタンスなどの従来の Linux ホストに至るまで、複雑で混合されたインフラストラクチャ上で実行されるcloudが多いため、困難です。 これらの環境を拡張すると、大幅な手動設定を行わずにパフォーマンスを可視化することがより困難になります。 エンジニアは、クラスター内でどのようなアプリケーションが実行されているか、またどのアプリケーションがパフォーマンスの低下を引き起こしているかを把握する必要があります。場合によっては、アプリケーションの所有者がアプリケーション レベルのツールだけでは解決できない、基盤となるインフラストラクチャの問題により、アプリケーションのパフォーマンスが低下することがあります。 あなたのチームがさまざまな資産を管理していると想像してください。 * トラブルシューティングを迅速に行う必要がありますが、アプリケーション テレメトリーとインフラストラクチャ インサイトを関連付けることは簡単ではありません。 * 新しいワークロードはデプロイですが、インストゥルメントを実行するのは困難です。コードを所有していないか、開発チームが外部にいるか、単にサービスの存在に気づいていないだけであるためです。 どちらのシナリオでも、すべてのアプリケーションの言語やアーキテクチャに関する事前の知識を必要とせずに、資産全体にわたる幅広い可視性を提供するソリューションが必要です。 New Relic eBPF エージェントはこれらの課題に対処します。これは、これらの課題に対処するために設計された、強力で非侵入的なツールです。これは、Linux カーネルから直接情報を安全かつ効率的に取得する方法を提供する業界最先端のテクノロジーである、拡張 Berkeley Packet Filter (eBPF) を活用しています。 この eBPF エージェントを使用すると、豊富なサービスレベルのテレメトリーをカーネルから直接収集することで、Linux 資産全体にわたる統合された自動ビューを取得できます。 このアプローチにより、コードを変更することなく、すべてのアプリケーションを詳細に可視化できます。*/ /* ## Key 機能 [#key-features] New Relic eBPF エージェントは、Linux ホストとKubernetesクラスタに包括的な監視機能を提供するように設計されています。 システム全体の健全性を効果的に監視するのに役立つさまざまな機能を提供します。 * アプリケーション コードやデプロイ言語固有のエージェントを変更することなく、アプリケーションのパフォーマンスを詳細に可視化するためのゼロコード計装。 このアプローチにより、運用上のオーバーヘッドが削減され、インフラストラクチャ全体の価値実現までの時間が短縮されます。* サービスを自動的に検出し、実行中のすべてのサービスとその依存関係を継続的に識別してマッピングします。これにより、アプリケーションのアーキテクチャーの短期ビューが提供されます。 * Kubernetesでは、エージェントはクラスタのサービスレベル情報を使用して、アプリケーションにネイティブ コンテキストを提供します。 * Linux ホストでは、環境変数または基礎となるプロセス情報からサービス名が取得されるため、アプリケーションの動作を明確に把握できます。* Kubernetesでアプリケーションを実行しているか、従来の Linux ホストでアプリケーションを実行しているかに関係なく、環境全体で一貫した可視性を提供する統合テレメトリー。 ※サービスレベル インサイトのサービスインタラクション、リクエスト率、レイテンシ、エラーなどを把握するためのパフォーマンス分析。 これにより、実際のシナリオでアプリケーションがどのように動作するかを理解するのに役立ちます。* 最新のマイクロサービスであろうとレガシー アプリケーションであろうと、あらゆる言語で書かれたモニター アプリケーションに対する言語に依存しない可視性。 これにより、すべての監視ニーズに単一のツールを使用できるようになります。* 詳細なテレメトリーデータを収集しながら、システムのパフォーマンスへの影響を最小限に抑えるための低リソースのオーバーヘッド。 これにより、監視がアプリケーションのパフォーマンスに干渉しないことが保証されます。 * カーネルとユーザー スペースの詳細な可視性 インタラクションにより、アプリケーションが基礎となるシステムとどのように対話するかをインサイトに提供します。 これは、イベントのキャプチャとトレースに役立ちます。 * システム操作に関する詳細なレベルを収集するための豊富なメタデータにより、トラブルシューティングやパフォーマンス分析に役立ちます。*/ /* `IMAGE Needed` */ /* ## eBPF エージェントの仕組み [#how-it-works] New Relic eBPF エージェントは、Kubernetes の helm チャートと Linux ホストの Debian/RPM パッケージを使用してデプロイされます。これは、Kubernetes では `daemonset` として、または Linux ホストではシステム サービスとして実行されます。エージェントがインストールされると、環境内で実行中のすべてのサービスとアプリケーションが自動的に検出されます。これらのアプリケーションは、eBPF エンティティの下で New Relic の APM およびサービス UI に統合されます。New Relic eBPF エージェントには次の 2 つのモードがあります: * **検出モード:** アクティブな監視なしで環境内のアプリケーションを自動的に検出します。このモードは、初期セットアップや、あまり邪魔にならない監視に適しています。* eAPM モード:** アプリケーションを積極的に監視し、システムダイナミクスを包括的に理解するために低レベルのメトリクスを収集することにより、より深いレベルの観察可能性を解放します。 ## eBPF がAPMを補完する方法 [#ebpf-apm] */

最新のアプリケーションスタックは、 Kubernetesクラスタから従来のLinuxホストに至るまで、混合インフラストラクチャ環境全体で実行される異種の相互接続されたサービスで構成されています。 この複雑さにより、次のようなトラブルシューティングを遅らせる根本的な課題が生じます。

• アプリケーションとインフラストラクチャの間のギャップの監視:アプリケーション監視はコード パフォーマンスへの深いインサイトを提供し、インフラストラクチャ監視はシステムの健全性を追跡します。 ただし、これらのコンポーネント間のネットワーク層は、多くの場合、目に見えないままです。インシデント発生時に、根本原因がアプリケーション ロジックにあるか、ネットワーク関連の問題にあるかを判断するには、追加の調査が必要です。

• 異種エージェント:マイクロサービス環境による運用上のオーバーヘッドにより、多くの場合、複数の異なる監視エージェントのデプロイが必要になります。 これにより、運用が複雑になり、エージェントの競合が発生する可能性があり、アプリケーションの変更と再起動が必要になります。これは、DevOps チームにとって大きな問題点です。

• サイロ化されたテレメトリーデータ:データ収集後、アプリケーション ログとネットワーク スパンおよびインフラストラクチャ メトリクスを関連付けるためには多大な手作業が必要となり、不完全な監視とインシデント解決の遅れにつながります。

• 限られたプラットフォーム チームの管理: プラットフォーム エンジニアは、多くの場合、資産全体にわたってアプリケーションを簡単に計装する能力や権限を欠いていますが、それでもサイト全体の信頼性とパフォーマンスに対して責任を負い続けます。

New Relic eBPF オブザーバビリティ ソリューションは、統合と簡素化を通じてこれらの課題に対処します。 当社の単一の軽量で言語に依存しないエージェントは、eBPF テクノロジーを活用して、Linux カーネルから直接、深い「アウトサイドイン」インサイトを取得します。

主な特徴

• 侵入のない完全な可視性:プログラミング言語に関係なく、 Kubernetesクラスタおよび Linux ホスト/コンテナにわたる新しい、レガシー、またはサードパーティのワークロードを完全に監視できます。

• 統合されたデータ収集:カーネル レベルで動作する当社の単一エージェントは、アプリケーション スパン、ログ、ネットワーク トラフィック、インフラストラクチャ メトリクスなどの監視データを同時に収集し、データ サイロの問題を解決します。

• デプロイメントの簡素化:オブザーバビリティをカーネルに移行することで、アプリケーションを変更する必要がなくなり、アプリケーションの再起動やコードの変更を必要とせずに、マイクロサービスの多い環境でのロールアウトが簡素化されます。

統合 eBPF エージェントは、2 つの強力で補完的な機能を提供します。

• eBPF を活用した APM
• eBPFネットワークメトリクス

使用事例

このソリューションは、プラットフォーム エンジニアにとって重要な課題に対処します。

• より迅速なトラブルシューティング:アプリケーション テレメトリーをインフラストラクチャおよびネットワーク インサイトと関連付けます。 これにより、パフォーマンスの問題、特に基盤となるシステムで発生した問題を迅速に診断できるようになります。

• 自動検出:計装ゼロで自動監視を実現します。 eBPF エージェントは、実行中のすべてのサービスとその依存関係を継続的に識別してマッピングし、アプリケーションの言語に関する事前の知識を必要とせずに、新しいワークロードまたは未知のワークロードのリアルタイムのアーキテクチャ ビューを提供します。

• さまざまな環境で任意の言語で記述された統合監視:モニター アプリケーション。 これにより、一貫した可視性とサービスレベルのパフォーマンス分析をNew Relicユーザー インターフェース内で直接行うことができます。

eBPF 搭載 APM (eAPM)

eBPF を利用した APM (eAPM) は、コード不要で言語に依存しないアプリケーション監視の標準です。ホストまたは Kubernetes ノードで実行されているすべてのサービスを自動的に検出し、New Relic APM UI にパフォーマンス データを入力します。この機能は、未知のワークロードやサードパーティ アプリケーションなど、手動で計測できないサービスも含め、すべてのサービスの完全なインベントリを取得するのに最適です。

主な特徴

• 継続的なサービス検出:実行中のすべてのアプリケーション サービスを自動的に検出してマッピングし、アーキテクチャの継続的なビューを提供します。
• ゼロコード計装:アプリケーション コードやデプロイ言語固有のエージェントを変更することなく、アプリケーションのパフォーマンス (MELT データを含む) を詳細に可視化します。
• 幅広い環境のサポート: x86 と ARM64アーキテクチャの両方にわたる Linux ホスト (さまざまなディストリビューション) とKubernetesクラスタの包括的なサポートを提供します。
• 高度な現場トレース: Javaアプリケーションの詳細なセグメント リンクをサポートし、トランザクションを個々のコンポーネント (アプリケーション コード、データベース呼び出し、外部サービス呼び出し) に分割して、パフォーマンス ボトルネックを正確に特定します。 このレベルの可視性は、以前は従来のAPMエージェントを通じてのみ利用可能でした。

使用事例

• プラットフォーム エンジニアの場合:プラットフォーム上で実行されているすべてのサービス (所有していないサービスや知らないうちにデプロイされていたサービスも含む) の完全なインベントリを即座に取得できます。
• 不透明なワークロードを使用するチームの場合: コードを変更できない (または変更したくない) 言語で書かれたレガシー アプリケーション、サードパーティのバイナリ、またはサービスを即座に監視します。
• 環境全体をカバーするには: eAPMを使用して既存のAPM計装を補完し、手動で計測されないすべてのサービスをカバーし、100% の可視性を確保します。

eBPFネットワークメトリクス

eBPF ネットワーク メトリクスは、アプリケーションのネットワーク通信を詳細に可視化します。 これは、詳細な TCP、IP、および DNS テレメトリーをカーネルから直接キャプチャし、アプリケーションのパフォーマンス問題の主な原因を解決します。 この機能は APM (eAPM と従来の APM の両方) を補完するものであり、独立して動作してアプリケーションの通信の健全性の全体像を提供し、「問題はアプリケーションか、それともネットワークか」という質問に明確に答えるのに役立ちます。

デプロイメントの柔軟性

• 既存のNew Relic APM顧客の場合:既存のAPMエージェントと一緒に eBPF ネットワーク メトリクスを有効にして、現在の計装を中断することなくネットワーク層の可視性を得ることができます。 eBPF エージェントはネットワーク専用モードで動作し、 APMデータをカーネル レベルのネットワーク インサイトで補完します。

• 包括的な監視の場合: eAPMとネットワーク メトリクス機能の両方を備えた完全な eBPF エージェントをデプロイして、アプリケーション、インフラストラクチャ、およびネットワーク層全体にわたる完全なオブザーバビリティを実現します。

ネットワーク メトリクスを表示するには、ネットワーク メトリクスのドキュメントを参照してください。

主な特徴

• アプリケーション コンテキスト ネットワーク データ:すべてのネットワーク メトリクスは、それらを開始した特定のアプリケーション、サービス、およびプロセスと自動的に関連付けられるため、トラブルシューティングが容易になります。

• きめ細かな DNS 監視: DNS 解決の失敗を追跡し、関連する完全修飾ドメイン名 (FQDN) を報告します。

• 詳細な TCP 接続分析:以下を含む接続の健全性とレイテンシを測定します。

  • ハンドシェイク: 3-Way ハンドシェイクのレイテンシと成功/失敗のカウント。
  • 接続状態:接続期間、データ転送期間、SYN、ACK、FIN、RST パケットの数。
  • エラー:異常な接続の終了を追跡します。

• パケットレベルの IP インサイト:次のものを監視して、パケット損失とネットワーク最適化の機会を特定します。

  • 送受信バイト数
  • パケットが再送/ドロップされました
  • パケット配送レイテンシ

使用事例

• トラブルシューティング 外部APIコールが遅い:アプリケーションが外部サービスに対する応答タイムの低下を示した場合、ネットワーク メトリクスは、問題の原因がアプリケーションのロジックではなく、TCP ハンドシェイクの遅延、パケット損失、または再送信の問題であるかどうかを特定するのに役立ちます。
• パフォーマンス低下の根本原因分析: TCP 接続の正常性、パケット配信レイテンシ、および接続状態の変化を調査することにより、アプリケーションのパフォーマンスの問題とネットワーク層の問題を関連付けます。
• サービス間通信監視:クラスタ全体にわたるマイクロサービス間の通信の健全性を監視し、ネットワークの輻輳やサービス間のルーティングの問題を特定します。
• 外部依存関係トラブルシューティング:アウトバウンド ネットワーク パターンと接続品質を分析することで、外部APIエンドポイントまたはサードパーティ サービスに起因するパフォーマンスの問題を迅速に特定します。

eBPFエージェントの設定方法

Linux ホストまたはKubernetesクラスタ上にNew Relic eBPF エージェントをセットアップできます。

関連記事