Docs » Splunk Observability Cloud でサポートされているインテグレーション » バックエンドアプリケーションをインストルメンテーションして、スパンを Splunk APM に送信する » Splunk Observability Cloud に Node.js アプリケーションをインストルメンテーションする » Performance reference for Splunk OTel JS agent

Performance reference for Splunk OTel JS agent 🔗

The Splunk OTel JS agent instruments your application at runtime. Like any other software agent, the JS agent requires system resources like CPU, memory, and network bandwidth. The use of resources by the agent is called agent overhead or performance overhead. The Splunk OTel JS agent has minimal impact on system performance when instrumenting Node.js applications, although the final agent overhead depends on multiple factors.

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

最近のソフトウェアは複雑で、導入シナリオも多岐にわたるため、エージェントのオーバーヘッドを一概に見積もることはできません。任意のデプロイメントにおけるインストルメンテーションエージェントのオーバーヘッドを求めるには、実験を行い、直接測定値を収集する必要があります。したがって、パフォーマンスに関するすべての記述は、特定のシステムで評価される一般的な情報およびガイドラインとして扱われなければなりません。

The following sections describe the minimum requirements of the Splunk OTel JS agent, as well as potential constraints impacting performance, and guidelines to optimize and troubleshoot the performance of the agent.

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

Splunk Distribution of OpenTelemetry JS には、Node.js 14 以上が必要です。AlwaysOn Profiling を有効にするには、Node.js 16 以上が必要です。

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

The following best practices and techniques might help in reducing overhead caused by the Splunk OTel JS agent.

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

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

次の例は、unwanted という名前のスパンをドロップするように、コード内でトレースサンプリングを設定する方法を示しています：

const { start } = require("@splunk/otel");
const { SamplingDecision } = require("@opentelemetry/sdk-trace-base");

start({
tracing: {
   tracerConfig: {
      sampler: {
        shouldSample: (context, traceId, spanName, spanKind, attributes, links) => {
           if (spanName ===  "unwanted") {
              return { decision: SamplingDecision.NOT_RECORD };
           }

           return { decision: SamplingDecision.RECORD };
        },
        toString: () => return "CustomSampler",
      }
   },
},
});

必要なインストルメンテーションだけをオンにする 🔗

エージェントのオーバーヘッドとスパン量をさらに削減するために、必要なインストルメンテーションだけをオンにすることを検討してください。デフォルトのインストルメンテーションをすべてオフにするには、OTEL_INSTRUMENTATION_COMMON_DEFAULT_ENABLED を false に設定し、OTEL_INSTRUMENTATION_<NAME>_ENABLED 環境変数を使用して特定のインストルメンテーションを有効にします。<NAME> はインストルメンテーションの名前です。

たとえば、次のオプションは、他のすべてのインストルメンテーションを非アクティブにしたまま、Bunyanインストルメンテーションをオンにします：

export OTEL_INSTRUMENTATION_COMMON_DEFAULT_ENABLED=false
export OTEL_INSTRUMENTATION_BUNYAN_ENABLED=true

これまでの設定は、デフォルトで Splunk Distribution of OpenTelemetry JS によってロードされるインストルメンテーションにのみ適用されます。プログラム API を使用してユーザー指定のインストルメンテーションのリストを提供する場合は、これらの設定は影響しません。利用可能なインストルメンテーションの完全なリストについては、要件 を参照してください。

注釈

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

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

手動インストルメンテーションは、エージェントのオーバーヘッドを増加させる非効率性をもたらす可能性があります。例えば、タイトなループでスパンを作成すると、何百万ものスパンを生成することになり、ホストに大きな負担をかけることになる可能性があります。

適切なリソースの提供 🔗

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

Constraints impacting the performance of the Splunk OTel JS agent 🔗

一般的に、アプリケーションから収集するテレメトリが多ければ多いほど、エージェントのオーバーヘッドへの影響は大きくなります。例えば、アプリケーションに関係のないメソッドをトレースしても、かなりのエージェントのオーバーヘッドが発生します。同様に、メトリクスでカーディナリティの高いタグを使用すると、メモリ使用量が増加する場合があります。デバッグロギングも、ディスクへの書き込み操作とメモリ使用量を増加させます。

例えば JDBC や Redis のようないくつかのインストルメンテーションは、エージェントのオーバーヘッドを増加させる高いスパンボリュームを生成します。不要なインストルメンテーションをオフにする方法の詳細については、必要なインストルメンテーションだけをオンにする を参照してください。

注釈

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

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

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

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

  • 互換性のある最新のNode.jsエージェントを使用してください。

  • 互換性のあるNode.jsの最新バージョンを使用します。

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

  • アプリケーションがメモリ制限に近づいている場合は、より多くのメモリを与えることを検討してください。

  • アプリケーションがすべてのCPUを使用している場合は、水平方向にスケーリングすることをお勧めします。

  • CPUまたはメモリのプロファイリングをオフにするか、チューニングしてみてください。AlwaysOn Profilingの Node.js 設定 を参照してください。

  • メトリクスをオフにするか、チューニングしてみてください。メトリクスの設定 を参照してください。

  • スパン量を減らすためにトレースサンプリング設定を調整します。サンプラーの設定 を参照してください。

  • 特定のインストルメンテーションをオフにします。必要なインストルメンテーションだけをオンにする を参照してください。

  • 不要なスパンが発生していないか、手動インストルメンテーションを見直します。

  • イベントループの遅延をチェックするために、ランタイムメトリクスをオンにします。メトリクス・コレクションを有効にする を参照してください。

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

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

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

アプリケーションやサービスのユーザーによって、エージェントのオーバーヘッドに気づく側面は異なる可能性があります。例えば、エンドユーザーはサービス遅延の悪化に気づく可能性があります。が、重いワークロードを持つパワーユーザーはCPUオーバーヘッドにもっと注意を払います。一方、弾力的なワークロードのために頻繁にデプロイするユーザーは、起動時間の方を心配します。

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

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

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

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

  • 起動時間（ミリ秒

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

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

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

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

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

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

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

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

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

テスト環境に対して実行するテストは、できるだけ典型的なワークロードに似せて設計します。たとえば、サービスの REST API エンドポイントが大量のリクエストの影響を受けやすい場合、大量のネットワークトラフィックをシミュレートするテストを作成します。

Node.jsアプリケーションでは、測定を開始する前にウォームアップフェーズを使用します。Node.js はジャストインタイムコンパイル（JIT）により、多くの最適化を実行します。ウォームアップフェーズは、アプリケーションのクラスローディングの大部分を終了させ、JITコンパイラに最適化の大部分を実行する時間を与えます。

多くのリクエストを実行し、テストパスを何度も繰り返すようにしてください。この繰り返しは、代表的なデータサンプルの確保に役立ちます。テストデータにエラーシナリオを含めます。通常の作業負荷と同様のエラー率をシミュレートします（通常2％～10％）。

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

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

例えば、インストルメンテーションの有無と設定だけが異なる3種類のインストルメンテーションを行うことができます：

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

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

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

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

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

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

また、https://opentelemetry.io/docs/instrumentation/js/benchmarks/ にある公式のOpenTelemetry JSベンチマークと結果を比較することもできます。

サポートを受ける方法 🔗

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

Splunk Observability Cloudをご利用のお客様

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

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

  • Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルの チャットグループ を参照してください。

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