Docs » Splunk Observability Cloud でサポートされているインテグレーション » バックエンドアプリケーションをインストルメンテーションして、スパンを Splunk APM に送信する » Splunk Observability Cloud 用 Java アプリケーションのインストルメンテーション » 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 のトレースアナライザを使用して、アプリケーションからのスパンを探索し、不要なインストルメンテーションを特定します。詳細は 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 によるインストルメンテーション

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

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

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

サポートを受ける方法 🔗

Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。

Splunk Observability Cloudをご利用のお客様

見込み客および無料トライアルユーザー様

  • Splunk Answers のコミュニティサポートで質問し、回答を得る

  • Join the Splunk #observability user group Slack channel to communicate with customers, partners, and Splunk employees worldwide. To join, see Chat groups in the Get Started with Splunk Community manual.

このページは 2025年02月11日 に最終更新されました。