Splunk OTel Java エージェントのパフォーマンスリファレンス

Splunk OTel Java エージェントの最小要件、パフォーマンスに影響を与える潜在的な制約、エージェントのパフォーマンスを最適化しトラブルシューティングするためのガイドライン。

Splunk OTel Java エージェントは、同じ Java 仮想マシン（JVM）内で実行することでアプリケーションをインスツルメントします。他のソフトウェアエージェントと同様に、 Java エージェントには CPU、メモリ、ネットワーク帯域幅などのシステムリソースが必要です。エージェントがリソースを使用することを、エージェントのオーバーヘッドまたはパフォーマンスのオーバーヘッドといいます。Splunk OTel Java エージェントは、JVM アプリケーションをインストルメントするときのシステムパフォーマンスへの影響を最小限に抑えますが、最終的なエージェントのオーバーヘッドは複数の要因に依存します。

エージェントのオーバーヘッドを増加させる可能性のある要因は、物理マシンのアーキテクチャ、 CPU の周波数、メモリの量と速度、システムの温度、リソースの競合、環境などです。その他の要因には、仮想化とコンテナ化、オペレーティングシステムとそのライブラリ、JVM バージョンとベンダー、JVM 設定、モニター対象のソフトウェアのアルゴリズム設計、ソフトウェアの依存関係などがあります。

最新のソフトウェアの複雑さとデプロイメントシナリオの幅広い多様性により、単一のエージェントのオーバーヘッドの見積もりを提示することは不可能です。特定のデプロイメントでのインストルメンテーション エージェントのオーバーヘッドを見つけるには、実験を実施して測定値を直接収集する必要があります。したがって、パフォーマンスに関するステートメントはすべて、特定のシステムでの評価に依存する一般的な情報およびガイドラインとして扱う必要があります。

以下のセクションでは、Splunk OTel Java エージェントの最小要件、パフォーマンスに影響を与える潜在的な制約、エージェントのパフォーマンスを最適化しトラブルシューティングするためのガイドラインについて説明します。

本番導入のための最低要件

Splunk Distribution of OpenTelemetry Javaのエージェントは、以下のJavaバージョンとの互換性があります：

  • Java 8u40以降、またはAlwaysOn Profilingの場合は8u262以降

  • Java LTS版のバージョン11以降

以下のJava仮想マシン（JVM）は、JDKまたはJREとして互換性があります：

  • AdoptOpenJDK

  • Amazon Corretto

  • Azul Zulu

  • BellSoft Liberica JDK

  • Eclipse AdoptiumおよびTemurin

  • IBM J9

  • Microsoft build of OpenJDK

  • OpenJDK

  • Oracle JDK

  • SAP SapMachine

注: AlwaysOn Profilingは、Oracle JDK 8およびIBM J9ではサポートされていません。

エージェントのオーバーヘッドを削減するためのガイドライン

以下のベストプラクティスとテクニックは、Javaエージェントによるオーバーヘッドを削減するのに役立つ可能性があります。

トレースサンプリングの設定

インストルメンテーションによって処理されるスパンの量は、エージェントのオーバーヘッドに影響を与える可能性があります。トレースサンプリングを構成して、スパンボリュームを調整し、リソース使用量を削減できます。サンプリング設定の詳細については 、「Splunk Observability Cloud 用の Java エージェントを設定する」を参照してください。

特定のインストルメンテーションをオフにする

エージェントのオーバーヘッドとスパン量をさらに削減するために、不要なインストルメンテーションや、多すぎるスパンを生成しているインストルメンテーションをオフにすることを検討してください。インストルメンテーションをオフにするには、-Dotel.instrumentation.<name>.enabled=false または OTEL_INSTRUMENTATION_<NAME>_ENABLED 環境変数を使用します。ここで、<name> はインストルメンテーションの名前です。

例えば、以下のオプションはJDBCインストルメンテーションをオフにします： -Dotel.instrumentation.jdbc.enabled=false

注: Splunk APM の Trace Analyzer を使用して、アプリケーションからのスパンを探索し、不要なインストルメンテーションを特定します。「Splunk APM の Trace Analyzer を使用してトレースを調査する」を参照してください。

アプリケーションにより多くのメモリを割り当てる

--Xmx<size> オプションを使用してJVMの最大ヒープ・サイズを大きくすると、インストルメンテーションがメモリ内に大量の短命オブジェクトを生成する可能性があるため、エージェントのオーバーヘッド問題を軽減するのに役立つ可能性があります。

手作業によるインストルメンテーションを最小限に抑える

手動インストルメンテーションでは、非効率的になることでエージェントのオーバーヘッドが増加する可能性があります。たとえば、すべてのメソッドで @WithSpan を使用すると、スパン量が多くなり、次にデータのノイズが増加して、システムリソースの消費が増加します。

適切なリソースの提供

インストルメンテーションと Collector に十分なリソースをプロビジョニングしてください。メモリやディスクなどのリソースの量は、アプリケーションのアーキテクチャとニーズによって異なります。たとえば、一般的なセットアップでは、Splunk Distribution of OpenTelemetry Collector と同じホストでインストルメンテーションされたアプリケーションを実行します。その場合は、Collector のリソースの適切なサイズ設定とその設定の最適化を検討してください。「サイジングとスケーリング」を参照してください。

Javaエージェントのパフォーマンスに影響を与える制約

一般に、アプリケーションから収集されるテレメトリが多くなるほど、エージェントのオーバーヘッドへの影響が大きくなります。たとえば、アプリケーションと関連しないメソッドをトレースする場合などは、メソッド自体を実行するよりも計算コストがかかるため、エージェントに大きなオーバーヘッドが発生する可能性があります。同様に、メトリクスの基数が高いと、メモリ使用率が高くなる可能性があります。デバッグロギングを有効にすると、ディスクおよびメモリの使用量への書き込み操作も増加します。

Java フライトレコーダー（JFR）の記録にはヒープ領域が必要であり、メモリプロファイリングは大量作成時にエージェントオーバーヘッドが著しく増加する可能性がある TLAB イベントに依存するため、AlwaysOn Profiling のような Java エージェントのいくつかの機能は、リソースの消費を増加させます。たとえば JDBC や Redis のようないくつかのインストルメンテーションは、エージェントのオーバーヘッドを増加させる高いスパンボリュームを生成します。不要なインストルメンテーションをオフにする方法の詳細については、「特定のインストルメンテーションをオフにする」を参照してください。

注: Java エージェントの実験的な機能は、パフォーマンスよりも機能に重点を置いた実験的なものであるため、エージェントのオーバーヘッドを増加させる可能性があります。エージェントのオーバーヘッドに関しては、安定した機能の方が安全です。

エージェントのオーバーヘッド問題のトラブルシューティング

エージェントのオーバーヘッドの問題をトラブルシューティングする場合は、次のようにしてください：

  • 最低条件を確認してください。「本番導入のための最低要件」を参照してください。

  • Javaエージェントの最新の互換バージョンを使用してください。

  • お使いのJVMの最新の互換バージョンを使用してください。

エージェントのオーバーヘッドを減少させるために、以下の措置を講じることを検討します：

エージェントのオーバーヘッドを測定するためのガイドライン

独自の環境とデプロイメントでエージェントのオーバーヘッドを測定することで、アプリケーションやサービスのパフォーマンスに対するインストルメンテーションの影響に関する正確なデータが得られます。次のガイドラインでは、信頼性の高いエージェントオーバーヘッドの測定値を収集して比較するための一般的な手順について説明します。

何を測定したいかを決める

さまざまなユーザーがアプリケーションやサービスを使用することで、エージェントのオーバーヘッドのさまざまな側面が明らかになる場合があります。たとえば、エンドユーザーはサービス遅延の低下に気付く可能性がある一方で、高負荷のワークロードを持つパワーユーザーは CPU オーバーヘッドに注意を払います。一方で、柔軟性のあるワークロードなどのために、頻繁にデプロイするユーザーは、スタートアップ時間により多くの注意を払う必要があります。

無関係な情報を含むデータセットを生成しないように、測定はアプリケーションのユーザーエクスペリエンスに確実に影響する要素に絞ります。測定の例には、次のものがあります。

  • ユーザー平均、ユーザーピーク、マシン平均CPU使用率

  • 総割り当てメモリと最大ヒープ使用量

  • ガベージコレクション休止時間

  • 起動時間（ミリ秒

  • 平均およびパーセンタイル95（p95）のサービス遅延

  • ネットワークの読み取りと書き込みの平均スループット

適切なテスト環境を準備する

コントロールされたテスト環境でエージェントのオーバーヘッドを測定することで、パフォーマンスに影響する要因をよりよくコントロールし、特定することができます。テスト環境を準備する場合は、次のことを行います。

  1. テスト環境の構成が本番環境に似ていることを確認します。

  2. テスト対象のアプリケーションを、干渉する可能性のある他のサービスから隔離します。

  3. アプリケーションホスト上の不要なシステムサービスをすべてオフにするか、削除します。

  4. アプリケーションに、テスト作業負荷を処理するのに十分なシステムリソースがあることを確認します。

現実的なテストのバッテリーを作る

可能な限り一般的なワークロードと類似するように、テスト環境に対して実行するテストを設計します。たとえば、サービスの REST API エンドポイントが大量のリクエストの影響を受けやすい場合、大量のネットワークトラフィックをシミュレートするテストを作成します。

Java アプリケーションの場合は、測定を開始する前にウォームアップフェーズを使用します。JVM は高度にダイナミックマシンで、アプリケーションを即時コンパイル（JIT）することで数多くの最適化を実行します。ウォームアップフェーズは、アプリケーションがそのクラスのロードの大部分を完了するのに役立ち、JIT コンパイラが最適化の大部分を実行するために必要な時間を与えます。

大量の要求を実行し、テストの成功を何回も繰り返してください。この繰り返しにより、代表的なデータサンプルを確保できます。テストデータにエラーシナリオを含めます。通常のワークロードの場合と同様のエラー率をシミュレートします（通常は 2% ～ 10%）。

比較可能な測定値を集める

どの要因がパフォーマンスに影響を与え、エージェントのオーバーヘッドを引き起こしているかを特定するために、1つの要因や条件を変更した後に、同じ環境で測定を収集します。

例えば、インストルメンテーションの有無と設定だけが異なる3つの異なる測定セットを取ることができます：

  • 条件A：インストルメンテーションまたはベースラインなし

  • 条件 B：AlwaysOn Profilingを使用しないインストルメンテーション

  • 条件 C: AlwaysOn Profiling によるインストルメンテーション

エージェントのオーバーヘッドデータを分析する

複数のパスからデータを収集した後、単純な統計検定を使って平均値を比較し、有意差をチェックしたり、結果をグラフにプロットしたりすることができます。

スタック、アプリケーション、環境が異なれば、運用特性もエージェントオーバーヘッドの測定結果も異なる可能性があることを考慮してください。

サポートを受ける方法

__ ___ ___ _ ______ _____________ _____ ________ ___ ___ ___ ____ __ ___ ____ ____ __ ______ _____________ ______ ___ ___ ___ ____ __ ___ _________ _____

_________ __ ______ _____________ _____ _________

_________ __ ___________ _________ ___ ____ _____ _____

  • ___ _ ________ ___ ___ _______ _______ _________ _______ __ ______ ________

  • ____ ___ ______ ______________ ____ _____ _____ _______ __ ___________ ____ __________ _________ ___ ______ _________ __________ __ _____ ___ ____ _______